There are 3 types of questions.

Type 1 is a question that can easily be answered and mostly appears as the first result in Google.

Type 2 is a question that can be answered by stitching together various type 1 answers.

Type 3 is a question that has not been answered. It may be a bug you’ll have to find out about by reading an email chain 12 years ago or maybe a reason why epoll() doesn’t work on Linux VMs. There is no solid yes or no. You’ve most likely encountered this when reaching page 3 of your Google results and every link is purple (visited).

This is where depression and isolation hits. This is where you realize that if you can’t help yourself, no one else can (or has the experience and time to do so). This is where you must rely on your knowledge and infer an answer to your question pushing your concepts and theories to the extreme. If you solve this question, you’re solving it for someone else who may trek the same path later in the future. You’re solving it for the world!

If you’re willing to solve, attempting to solve, or even giving a reasonable inference about a type 3, you have a true engineering mindset.

Definitely Rust, and a bit Haskell.

Rust has made me much more conscious of data ownership through a program, to the point that any C/C++ function I wrote that takes a pointer nowadays gets a comment on ownership.

I wish it was a bit less pedantic about generics sometimes, which is why I've started working on a "less pedantic rust", where generics are done through multiple dispatch à la Julia, but still monomorphising everything I can. I've only started this week, but I already have a tokenizer and most of the type inference system (an SLD tree) ready. Next up is the borrow checker and parsing the tokenized input to whatever the type inference and borrow checker need to work with, and of course actual code generation...

Haskell is my first FP language, and introduced me to some FP patterns which, turns out, are super useful even with less FP languages.

Rust does type inference based on stuff I do later down in the code. Like wtf? That's cool

Java was made to be easy, but leaks features even c++ has.

Type inference

Java: was is that.

C++: auto, easy

Was recently asked if our team wanted to change from Java to Kotlin so I looked over the feature lists but don't see much that's impressive.

One argument was less boilerplate code but I think they're are libraries like Lomboq that can write that stuff for you.

The other was smart type casting and type inference and to that I'm like this sounds like giving monkeys a hammer.

Our JS codebase looks like shit... And our Java app just crashed in prod.

Getting a ton of text messages this morning and thankfully I'm on vacation still...

The error is not caused by NPE... but how some or logic spammed the db..

A new language isn't going to fix this.... And a team that writes this sort of shit logic clearly shows they are incapable of learning a new one probably...

They are already script kiddies... Don't need them to become babies...

Turns out that one can use the ‘var’ keyword to declare a variable in Java 10. Finally Java’s being more like JavaScript 😊

I'm a C++/Obj-C programmer finding it ludicrously hard to switch to Swift.

I find that the constant ability (leading to very poor programmer code) to reduce syntax and add tokens reduces readability and nowhere is this more apparent that with closures.

I'm working through (to my shame) Ray Wenderlich's Swift course and the closure chapter has this:

PS I loathe K&R as much as I do Swift so it's all in Allman formatting for clarity.

let multiply: (Int, Int) -> Int =
{
(a: Int, b: Int) -> Int in

// do Something else

return a * b
}
Why oh why isn't this more simply and elegantly written as:

let multiply = (a: Int, b: Int) -> Int
{
// do Something else

return a * b
}
The equals sign shows clearly that it's a closure definition assignment, as does the starting 'let'. But this way all of the stupid excesses, like the 'in' keyword, the repetition of the params / return type only this time with useful labels and additional tokens are removed and it looks and reads much more like a regular function and certainly a lot more clearly.

Now I know that with the stupid ability of Swift you can reduce all this down to return $0 * $1, but the point I'm making is that a) that's not as clear and more importantly b) if this closure does something more than just one line of code, then all that complicated stuff - hinted to by the comment '// do Something else' means you can't reduce it to stupid tokens.

So, when you have a clousure that has a lot of stuff going on and you can't reduce it to stupid minimalism, then why isn't is formatted and syntactically better like the suggestion above?

I've mentioned this on the Swift.org (and got banned for criticising Swift) but the suggestions they came up with were 'use type inference' to remove the first set of params / return type and token.

But that still means the param list and return type are NOT on the same line as the declaration and you still need the stupid 'in' keyword!

The next step for improving large language models (if not diffusion) is hot-encoding.

The idea is pretty straightforward:
Generate many prompts, or take many prompts as a training and validation set. Do partial inference, and find the intersection of best overall performance with least computation.

Then save the state of the network during partial inference, and use that for all subsequent inferences. Sort of like LoRa, but for inference, instead of fine-tuning.

Inference, after-all, is what matters. And there has to be some subset of prompt-based initializations of a network, that perform, regardless of the prompt, (generally) as well as a full inference step.

Likewise with diffusion, there likely exists some priors (based on the training data) that speed up reconstruction or lower the network loss, allowing us to substitute a 'snapshot' that has the correct distribution, without necessarily performing a full generation.

Another idea I had was 'semantic centering' instead of regional image labelling. The idea is to find some patch of an object within an image, and ask, for all such patches that belong to an object, what best describes the object? if it were a dog, what patch of the image is "most dog-like" etc. I could see it as being much closer to how the human brain quickly identifies objects by short-cuts. The size of such patches could be adjusted to minimize the cross-entropy of classification relative to the tested size of each patch (pixel-sized patches for example might lead to too high a training loss). Of course it might allow us to do a scattershot 'at a glance' type lookup of potential image contents, even if you get multiple categories for a single pixel, it greatly narrows the total span of categories you need to do subsequent searches for.

In other news I'm starting a new ML blackbook for various ideas. Old one is mostly outdated now, and I think I scanned it (and since buried it somewhere amongst my ten thousand other files like a digital hoarder) and lost it.

I have some other 'low-hanging fruit' type ideas for improving existing and emerging models but I'll save those for another time.

What do you guys think about the new "type inference" (var type) feature that will be introduced with Java SE 10? I know that C# already has that construct. It's pretty controversial among my peers... 😅

My preprocessor is just generalized kerning, the macros are variations on the single well-known proof for the Turing-completeness of GK, the type system will probably be a Prolog reskin so simple the translator can be a FSM, the type inference algo is the original HM algorithm which I don't even need to change, the core language is Lambda calculus and no more, and the backend might just be Erlang itself if my research confirms that extending LLVM until it consistently beats Erlang is unrealistic.

I invented nothing, I create nothing. All I do is plug circles into square holes and fill the gaps with play dough.

How do you feel about using TypeScript with React? I appreciate the benefits, but, as every snippet of React code everywhere on the web is vanilla JS,I just don't want the cognitive overhead.

Yes, I know TS is JS, but, if I'm not going to use the features, why bother? I'd want to strongly type props, state, etc.

What's the status of TypeScript support in the React ecosystem (eg Router, MUI, etc.)?

I'm kinda hoping Reason will get some traction as the type inference is much better, but, will that happen? Or is that going to fizzle so it's a choice between TS and JS?

Appreciate any thoughts on this---including those from anyone who's in the same boat.

Looking for views on TS in React ecosystem---no need to sell me on TS in general.

It's a shame that people don't want to use F# but prise C# for how cool it became and continue becoming. At the same time, little do they know that many of the features were simply drawn from F#.

It's just rediculous how far this OO and C-Style syntax crap has progressed. They keep copying things from functional langugages, making the initial language to be a monstrocity like C++ is now, insted of just using languages like C#. I mean, it was right there before C#: async/task, immutablility, records, indexes, lambdas, non-null by default, who the hell knows what else.
Besides, many people (in my company at least) are just blindly overengineering with patterns and shit, where a simple function would be just enogh.

Watch some some NDC talks about F#, in particular those of Scott Wlaschin. It's just better in so many ways: less noice (I'm looking at you, brackets, commas and semicolons), the whole LOT of type inference and less duplication (just look at the C# signatures of linq methods - it's difficult to read them), immutability by default, non-nullable by default, ADTs and pattern matching, some neat features like type providers (how many times have used "paste special" or an online tool to create C# classes from a JSON/XML file, and how many times have your regenrated it because of schema changes?) and units of measure.

Of course, in some cases it's not optimal, in some cases mutable datastructures of C# are better for performance. But dude, how many performance critical systems have you wrote in C#? I mean, if it comes to performance you should use Rust or C++ or C after all.

*sighs*

Useless language feature #1: specify kind in explicit expression type annotations that you insert to guide the type inference engine.

How did I work on this for 6 months without realizing that the kind of a value's type is always the kind of types because that's literally what the kind of types means?

Rust's Fn traits feel weird. The argument tuple is a generic parameter, but the return type is an associated type, even though Rust is supposed to use Hindley-Milner type inference, so inferring through return type should always fail if this were a regular trait.

Then, this would mean that blanket implementations for Fn(T) and Fn(T, U) should conflict because AnyTrait<(T)> and AnyTrait<(T, U)> aren't mutually exclusive. I tried, they work just fine.

There's some weird and I suspect unnecessary special case magic here, and I'd like to uncover it.

IT WORKS! IT WORKS! I CAN TRAIN AM AI DIRECTLY ON MY PHONE!!!

I'm opening my thesis with the quote

"Ok. Now if you don't mind, I need to concentrate. What I'm about the attempt next is on the tricky side of damn near impossible"

Now for building am inference mechanism and theny Bachelor's Thesis is SAVED!

Suck on THAT every master of AI who claimed it wasn't possible due to computational constraints.

"Just" have to type it up now

Some senior just pushed some half assed typescript code generator that generates stupid types that make everyone's life difficult.
Who need transparent type inference? Just use type guard everywhere.

Can't reason with the particular individual.

Please release me from my misery.

In house built == shitty version of original open source library.