Comment by BoppreH | Hacker News Reader

Comment by BoppreH | Hacker News Reader

Parent Full thread

Lots of good ideas here.

Flow-sensitive type inference with static type checks is, IMHO, a massively underrated niche. Doubly so for being in a compiled language. I find it crazy how Python managed to get so popular when even variable name typos are a runtime error, and how dreadful the performance is.

All the anonymous blocks lend themselves to a very clean and simple syntax. The rule that 'return' refers to the closest named function is a cute solution for a problem that I've been struggling with for a long time.

The stdlib has several gems:

- `compile_run_code`: "compiles and runs lobster source, sandboxed from the current program (in its own VM)."

- `parse_data`: "parses a string containing a data structure in lobster syntax (what you get if you convert an arbitrary data structure to a string) back into a data structure."

- All the graphics, sound, VR (!), and physics (!!) stuff.

- imgui and Steamworks.

I'll definitely be watching it, and most likely stealing an idea or two.

> I find it crazy how Python managed to get so popular when even variable name typos are a runtime error

Tangential point, but I think this might be one of the reasons python did catch on. Compile checks etc are great for production systems, but a minor downside is that they introduce friction for learners. You can have huge errors in python code, and it'll still happily try to run it, which is helpful if you're just starting out.

What about when you have a long-running program. You can't both brag about NumPy, Django, and the machine learning library ecosystem while also promoting "It's great for when you just want to get the first 100 lines out as soon as possible!"

I am guessing that Python, like Ruby, is dynamic enough that it's impossible to detect all typos with a trivial double-pass interpreter, but still.

Wonder if there was ever a language that made the distinction between library code (meant to be used by others; mandates type checking [or other ways of ensuring API robustness]), and executables: go nuts, you're the leaf node on this compilation/evaluation graph; the only one you can hurt is you.

i don't think typing was the issue. at the time there didn't exist any typed languages that were as easy to use as python or ruby. (ok, not true, there did exist at least one: pike (and LPC which it is based on). pike failed for other reasons. otherwise if you wanted typed your options were C, C++ and then java. none of which were as easy and convenient to use as python or ruby. java was in the middle, much easier than C/C++, and that did catch on.

Is it though?

As long as warnings are clear I’d rather find out early about mistakes.

People learn by example. They want to start with something concrete and specific and then move to the abstraction. There's nothing worse than a teacher who starts in the middle of the abstraction. Whereas if a teacher describes some good concrete examples the student will start to invent the abstraction themselves.

It looks like it.

Based on what I observe as an occasional tutor, it looks like compiler warnings & errors are scary for newcomers. Maybe it's because it shares the same thing that made math unpopular for most people: a cold, non-negotiable set of logical rules. Which in turn some people treat warnings & errors like a "you just made a dumb mistake, you're stupid" sign rather than a helpful guide.

Weirdly enough, runtime errors don't seem to trigger the same response in newcomers.

Interesting angle: Compiler errors brings back math teacher trauma. I noticed Rust tries to be a bit more helpful, explaining the error and even trying to suggest improvements. Perhaps "empathic errors" is the next milestone each language needs to incorporate.

I suddenly understand part of why experienced programmers seem to find Rust so much more difficult than those who are just beginning to learn. Years of C++ trauma taught them to ignore the content of the error messages. It doesn't matter how well they're written if the programmer refuses to read.

Interesting. I think over the long term many people come to realise it's better to know at compile time (when they mistype something and end up with a program that runs but is incorrect it's worse than not running and just telling you your mistake). But perhaps for beginners it can be too intimidating having the compiler shout at you all the time!

Perhaps nicer messages explaining what to do to fix things would help?

That's surprising because runtime debugging depends on the state of the call stack, all the variables, etc. Syntax errors happen independent of any of that state.

I think languages with strong support for IDE type hints as well as tooling that takes advantage of it are a fairly recent phenomenon, except for maybe Java and C# which I think are regarded by the wider hacker community as uncool.

C++/C IDE support is famously horrible owning to macros/templates. I think the expectation that you could fire up VS Code and get reliable typescript type hints has been a thing only for a decade or so - for most of modern history, a lot of people had to make do without.

this is the “types make me slow” argument that everyone self debunks after they program that way for a handful of years

> that everyone self debunks

Speak for yourself.

Reply on news.ycombinator.com