Comment by IshKebab
6 hours ago
Pretty compelling, especially "Janet does not adhere to the ancient customs. CAR is called first. PROGN is called do. LAMBDA is fn, and SETQ is def." - a sign of good sense for sure!
How fast is it?
Also my main objection to Lisps is still the horrible bracket syntax. Yes it's unambiguous and easy to parse, but it's HORRIBLE to read and edit. I wish this project had been a success (or something similar to it): https://readable.sourceforge.io/
Also I don't think static typing is really optional for me at this point.
Actually not all those are ancient customs, and not all that Janet uses is newer.
In the first description of the language LISP, from March 1959 (AIM-008), John McCarthy had used the names "first" and "rest", instead of what later will be called "CAR" and "CDR".
The names of "CAR" and "CDR" appear to have come from the students who worked at the practical implementation of the LISP interpreter on an IBM 704, and unfortunately we have remained stuck with them, like also with other features that were intended only for a temporary use, until being replaced in the "final version" (which was abandoned).
All programming languages have horrible syntax (except maybe Forth). Some examples:
Statements are terminated by either a dedicated graphical character, in which case it's easy to forget the character and have a problem, or by a newline (or maybe a different white space character, but I haven't encountered that yet) in which case decent formatting of code may require a dedicated graphical character to indicate that the newline DOESN'T terminate the statement, in which case we have the same problem. Having newline-terminated statements without continuation character would be consistent, but would hamper readability because identifiers would need to be strictly limited in length to keep certain lines from exceeding available screen space (or alternatively readability would suffer from lines only being partially readable).
And that's before getting into the weeds of how mathematical notation is tricky (most people have learned infix notation at maths class in school, so they mightn't appreciate how horrible it is), how different types of brackets (round, square, curly) can have inconsistent semantics, the downsides to the various ways of indicating lexical blocks (brackets, white space, keywords,...), et cetera.
The ideal programming language would probably be one which allows switching between different syntaxes based on what works best for the user (for example, someone could write code in S-expressions, another person could have that code automatically translated into SRFI-119 Wisp expressions and work with it like that, a third person could then have it rendered into something more Lua-like,...). Which is something I think the Racket people are working on, but I may be mistaken.
> Pretty compelling, especially "Janet does not adhere to the ancient customs. CAR is called first. PROGN is called do. LAMBDA is fn, and SETQ is def." - a sign of good sense for sure!
Just FYI, many of these are also done in Scheme and its derivative Racket. They kept lambda (but even Python did that), but progn -> begin, setq -> set!, car -> first, and so on.
> Also my main objection to Lisps is still the horrible bracket syntax. Yes it's unambiguous and easy to parse, but it's HORRIBLE to read and edit.
I have pretty mixed feelings at this point. I don’t mind it for normal programming, but when I do numerical programming (physics models, etc.) you often get extremely long and verbose expressions that are IMO difficult to parse compared to the math-like infix operator notation used in other languages.
I'm starting to prefer the s expression syntax when dealing with tree structures like json.
I wonder if we were raised on tree based algebra if math would be easier to do, or harder.
Like, solve for x.
Though this isn't too bad.
I think also a lot of my objections could be worked around if one simply had a "math" macro that evaluates infix math notation as a DSL, similarly to how the CL "loop" macro does a DSL for iteration.
Perhaps this exists already somewhere?
I definitely prefer s-exps over both xml and json myself too!
Interesting question. Much of the difficulty does stem from mentally translating back and forth between conventional notation and s-exps too, since you can’t really avoid the standard notation when reading and writing math and physics papers. And current-day math and physics notation has been optimized to some extent for the infix notation; perhaps one would have invented more expressive higher-order functions or macros to denote s-exp math if that was what everyone used for centuries.
If you ever used an RPN calculator then this is very familiar
It's a scripting language, so it's not going to compete with anything compiled or JITed, but it has a pretty efficient threaded bytecode interpreter (that is almost more interesting than the language itself!). It's certainly good enough for most situations where you would reach for a scripting language.
Syntax is not that important to me. I prefer Python style indentation, but its really not that important - its just something to get used to for me.
Is static typing that important for a scripting language? From the intro to the book:
> And to be clear, I’m not going to try to convince you to bet your next startup on Janet, or even to use it in any sort of production setting. But I think it’s an excellent language for exploratory programming, scripting, and fun side projects.
> Also my main objection to Lisps is still the horrible bracket syntax. Yes it's unambiguous and easy to parse, but it's HORRIBLE to read and edit.
I use Parinfer, which allows me to edit Janet as if it was an indentation-based language.
Yeah I mean I guess if you have to use that syntax, it's nice to have a better editor for it. But IMO the existence of that tool clearly demonstrates that the syntax is pretty bad.
All C-derived languages (e.g. Java and Rust) have a bad syntax, with tons of superfluous parentheses and many other superfluous tokens, like semicolons or commas.
This normally matters very little, because a good editor will always insert a complete template whenever you type something like "if", "for", "while" etc.
Most programmers are blind to the syntax defects with which they are accustomed and they notice only the syntax defects with which they are unfamiliar.
I would prefer a language with a good syntax, but unfortunately which programming languages have survived in widespread use has a poor correlation with the technical qualities of a language and especially a really negligible correlation with how good its syntax was.
Most editors manage your indentation, parentheses and braces for you. Not sure how that is a unique marker for lisp style languages.
> How fast is it?
Roughly as fast as puc-rio Lua. It won't blow your socks off, but it's more than respectable.
Out of those renames, I agree with car->first and progn->do. setq is ugly, but I think using def is maybe questionable. lambda I would have just kept the same.
Are you aware of:
https://docs.racket-lang.org/sweet/index.html