> Sort of how Common Lisp calls threads ‘processes’.
Can you point to any documentation on that? It's not in the hyperspec and it doesn't seem to be in Common Lisp the Language, 2nd Edition (using the index)
The scroll trigger was something I’ve seen and wanted to play around with, but I know it’s controversial so I added the toggle as well (upper left corner).
The examples are fine for an early-stage poc project like this one. `minutes` with evaluation trace and `[Fold]<-` are illustrative, and if you work them out with pen and paper, you can get a good grasp on the main ideas of the language. That you have to search for them on a page that looks like a slightly-formatted README instead of having a nice scrollable with syntax-highlighted snippets at the top is because this IS a slightly-formatted README - and that's also completely fine at this stage. What's important is that there are a few interesting concepts there and that it was published. Even if this one fizzles, as 99.999% of languages do, that doesn't matter if some other language down the line gets inspired by those concepts.
He had enough proof, his own students, who assumingly agreed. And in case the company still pretends there is no problem you could still crawl their entire user base...
It looks like there’s a download link that contains the source code. Presumably you untar it, follow any necessary build instructions, and then run it.
You said it before I did; wasn't this the basic point of COBOL? TO make something that more naturally read like English but could be executed.
It's a cute idea, though I think the consensus is that once you actually learn a programming language, it generally doesn't help to have it look like prose.
I wouldn't be so sure of that consensus, given that C# and Python exist and are generally well-regarded by their users. Clearly there are varying degrees to it, and taking the idea to its logical extreme is not by necessity going to produce the best result, but there's certainly merit to the idea of code that can be read more naturally.
And I think that is really the point of syntax sugar: reading code, not writing code. It seems like a misconception about syntax sugar is that its primary purpose is to make code easier for beginners to learn to write. But I would contend that the real purpose is to make code easier for even experienced programmers to read at a glance, because reading code is actually far more important than writing it.
...granted a certain subsection of the population has determined that reading code is for chumps and boast about how quickly they can use a tool to write lines of code they haven't even read, and that this is the future of software development. Despite their boasts I have yet to see any software I would actually want to use that was written in this manner, though.
I don't think C# and Python are particularly close to natural language. I also don't think making a language read more like English really makes it more readable. If that was true people wouldn't struggle with reading legalese.
You can absolutely write C# that reads close to natural language. I do so on a daily basis.
Legalese is a bit of a non-sequitur. Despite English legalese ostenisbly being written in English, it is specifically obfuscated, using terminology that is not encountered in everyday English so as to be more difficult for laymen to understand. In fact it is common for legalese to use English that is not English, that is, words that look like English words but have completely different definitions that are not in accord with how those words are used in regular communication.
And the original submission billed as "Compile English to Rust" uses a lot more ## and quotation marks than natural language. Perhaps we could establish an understanding that we are still talking about programming languages, not natural language, and that there is a scale of "further from natural language" and "closer to natural language", wherein decisions made about and within the programming language can move it along the scale while still being a programming language.
This very much depends on your definition of ‘best’. While your criticisms of the environment are valid, smalltalk is flexible in tangible ways that Java couldn’t match. Java took the OO model of smalltalk and make a bunch compromises that had big negative impacts on the language that are still there today.
Smalltalk was (and still is in some places) successful because of its portability, flexibility, etc. while it hasn’t enjoyed the degree of success as Java, ruby, perl, python, C++, and friends it would be a mistake to call it just a you.
Best is often a tradeoff among many things, including (but not limited to): usability/ergonomics, productivity, effectiveness, licensing costs and many other things.
When you factor in all these things, no wonder that Java won.
I can’t be alone in this, but this seems like a supremely terrible idea. I reject whole heartedly the idea that any sizeable portion of one’s code base should specifically /not/ be human interpretable as a design choice.
There’s a chance this is a joke, but even if it is I don’t wanna give the AI tech bros more terrible ideas, they have enough. ;)