Ah yeah I forgot about namespaces. I don't think they're a popular feature.

The other two only generate code for backwards compatibility. When targeting the latest JavaScript versions they don't generate anything.

Ok decorators are technically still only a proposal so they're slightly jumping the gun there, but the point remains.

Hmm I'm not sure if this is solid parametric CAD. It let me draw a rectangle and then extrude that giving a zero-width tube... There doesn't seem to be any way to add dimensions either.

Definitely loads quickly though and feels snappy. But for actually getting stuff done FreeCAD is definitely the best FOSS option at the moment.

No they don't. Enums are actually unique in being the only Typescript feature that requires code gen, and they consider that to have been a mistake.

In any case that's not the cause of the difference here.

Private or obscure ones I guess.

Real-world (macro) benchmarks are at least harder to game, e.g. how long does it take to launch chrome and open Gmail? That's actually a useful task so if you speed it up, great!

Also these benchmarks are particularly easy to game because it's the actual benchmark itself that gets gamed (i.e. the code for each language); not the thing you are trying to measure with the benchmark (the compilers). Usually the benchmark is fixed and it's the targets that contort themselves to it, which is at least a little harder.

For example some of the benchmarks for language X literally just call into C libraries to do the work.

Their measurements include invocation of the interpreter. And parsing TS involves bigger overhead than parsing JS.

But TS is compiled to JS so it's the same interpreter in both cases. If they're including the time for tsc in their benchmark then that's an even bigger WTF.

It has no memory, for one.

It has very short term memory in the form of it's token context. Especially with something like Meta's Coconut.

What makes you think that it does know its in a conversation?

I don't really. Yet. But I also don't think that it is fundamentally impossible for LLMs to think, like you seem to. I also don't think the definition of the word "think" is so narrow that it requires that level of self-awareness. Do you think a mouse is really aware it is a mouse? What about a spider?

Ah this ancient nonsense. Typescript and JavaScript get different results!

It's all based on

https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game

Microbenchmarks which are heavily gamed. Though in fairness the overall results are fairly reasonable.

Still I don't think this "energy efficiency" result is worth talking about. Faster languages are more energy efficient. Who new?

Edit: this also has some hilarious visualisation WTFs - using dendograms for performance figures (figures 4-6)! Why on earth do figures 7-12 include line graphs?

Your comment doesn't account for the fact that LLMs can generalise. Often not very well but they can produce outputs for inputs not seen in their training sets. Otherwise what would be the point?

You would not ask a piece of cardboard so solve a math problem, would you?

Uhhh you know LLMs can solve quite complex maths problems? Including novel ones.

This argument makes no more sense than trying to say that a plant is thinking because brains are made of cells and so are plants.

By that logic we also conclude that the human brain doesn't "think" about what it is saying.

It's really amazing the number of people trying to argue that LLMs are useless, while simultaneously so many people are using them successfully. Makes me wonder if they've even tried them.

Ah yes the old pointless vague anecdote.

If your argument is "LLMs can't do useful work", and then I say "no, I've used them to do useful work many times" how is that a pointless vague anecdote? It's a direct proof that you're wrong.

Promoting pseudo-science.

Sorry what? This is bizarre.