111–120 of 174 posts
The comparison with Closure is really interesting. They make the point that they do less reinvention of Lua than Closure does with Java - functions, standard library, tooling. I'd love to know why. Is it just that Lua has less problems than old-Java
I do not understand the appeal of LISPy languages. I get that the parser is simple and elegant, but I believe the developer (of the compiler in this case) should serve the convenience of the user, not the other way around. Writing code like this is cumbersome and unnecessarily symbol heavy, and reading it isn't really nice as well. I'd rather have the language add that extra complexity into the parser than have me st…
I do not understand the appeal of non-LISPy languages. I get that most people are used to reading it and that they are efficent, but I believe the developer (of the compiler in this case) should serve the convenience of the user, not the other way around. Writing code like this is combersome and unnecessarily symbol heavy, and reading it isn't really nice as well. I'd rather have the language add those extra parens i…
Why the exact repeat of the earlier post under a different name or some bots at play here?
Earlier quoted context omitted.
I do not understand the appeal of non-LISPy languages. I get that most people are used to reading it and that they are efficent, but I believe the developer (of the compiler in this case) should serve the convenience of the user, not the other way around. Writing code like this is combersome and unnecessarily symbol heavy, and reading it isn't really nice as well. I'd rather have the language add those extra parens i…
Are n4ture and torginus the same person? Why the exact repeat of the earlier post under a different name or some bots at play here?
Earlier quoted context omitted.
This doesn't really resonate with people though, as most people are more familiar with C-style notation. Also: >Writing code like this is combersome and unnecessarily symbol heavy Does not make sense in this context, as it mainly applies to Lisp-like languages that uses parentheses heavily.
>> as it mainly applies to Lisp-like languages that uses parentheses heavily. This is so wrong. Lisp does not use parentheses heavily. It doesent even use more parens than any C like language. I just dont understand the fixation with parentheses. The power of lisps comes from the fact that everything is an expression. Someone can correct me if I am wrong, since I only have experience with functional lisp Clojure, but…
I do not understand the appeal of LISPy languages. I get that the parser is simple and elegant, but I believe the developer (of the compiler in this case) should serve the convenience of the user, not the other way around. Writing code like this is cumbersome and unnecessarily symbol heavy, and reading it isn't really nice as well. I'd rather have the language add that extra complexity into the parser than have me st…
Earlier quoted context omitted.
It's obvious to anyone who is familiar with both. (f x y) vs f(x, y); Note the extra comma and semicolon. The only place this breaks down is for simple arithmetic expressions like (+ a b) vs a + b, which is trivial enough to ignore (and also goes back in favor of Lisp when you start having more operands).
It is only function calling that needs (,); in C and () in Lisp. Which is half as many characters, but much much much noisy since: - it is used everywhere - carries very little information Look at the example on the Janet page transcribed to Python syntax [0]. Several differences: - in Janet nearly every line starts and ends with ( and ), which is just noise - in Janet there are several )))) - in Janet there is no sp…
for (int i = 0; i (loop for i from 0 below 5
do (format t "~A~%" i))
The comparison really isn't even close. If you really want, you can always put the trailing )) on new lines like people do with the trailing }}}} for their nested if in a for in a method in a class in C-like languages. The Lisp community has just decided that putting single characters on new lines like that is needlessly noisy and emphasizes characters that are easily ignored by humans and instead manipulated using structural editing.
Earlier quoted context omitted.
Focusing on the runtime's parser is a red herring and I think a common error in lisp advocacy. Even if I didn't the full power of a lisp macro system, it is an absolute joy to manipulate programs written in s-expressions. Being able to cut/copy/paste/jump-[forward/back] by sexpr is really convenient, and often done nowhere near as well in other languages. I think this is because until the invention of tree-sitter and…
It does sound interesting, and I'll look into Lisp, can you give me some advice on what's the best way to learn it? On your other point, I've programmed in many languages in many years, and mostly I did some in an environment with an IDE, or powerful language-specific tooling (not tree-sitter) that had a proper good understanding of the syntax and semantics of the language used.
Earlier quoted context omitted.
I’m having trouble understanding what you mean, if you could provide or link to an example I’d appreciate it.
If you parse things with structure, and the structure is unknown in advance. In C(++) you have to generate all dynamically, and is very complex. In other systems, you can just read the object, and the structure comes with it.
Earlier quoted context omitted.
>> as it mainly applies to Lisp-like languages that uses parentheses heavily. This is so wrong. Lisp does not use parentheses heavily. It doesent even use more parens than any C like language. I just dont understand the fixation with parentheses. The power of lisps comes from the fact that everything is an expression. Someone can correct me if I am wrong, since I only have experience with functional lisp Clojure, but…
I just don't understand the fixation with REPL. How do you use it? It sounds like you write code as black box then run it in REPL to see what it does because you don't understand it by yourself.
That doesn't even make any remote sense. "I don't get the fixation with the JVM. It sounds like you write code as a black box, then compile and run it to see what it does because you don't understand it by yourself."