251–260 of 292 posts
DSLs. Creating a language that only you know that will double the learning curve for the folks coming after you. It's fine for personal projects, but almost always an anti-pattern.
Earlier quoted context omitted.
You don’t program in Lisp, do you? I used to be confused by the smug Lisp weenies. Now I am one. And the difficult thing I’ve found over the years is that Lisp is sort of unexplainable. You either “get it” or you don’t. Yes, it has macros, but macros are a bit overrated. I’ve been programming in Lisp for decades and I rarely write macros. I think the thing that is difficult to convey is how powerful Lisp’s core execu…
Is the magic a property of the broader language-family (and could be experienced with Janet, Racket, whatever), or Common Lisp specifically? When people praise the core execution environment they're typically praising Common Lisp specifically. What's the quintessential "now I get it" experience, in your mind?
If I could explain the moment, I would. But I really can’t. That said, one aha moment for me was reading McCarthy’s original Lisp paper and realizing the whole core of the language was a single page (17).
https://www.informatik.uni-bremen.de/agbkb/lehre/pi3/folien/...
Earlier quoted context omitted.
If there's one thing that I sometimes wish Lisp had, it's types. Most of the time, I don't need or even want them. But when you're doing a big refactor or changing the shape of your primary data structure, it would be nice to have the compiler be able to assist you in detecting locations where you've cross-wired something. But other than that, I don't care. And yes, Clojure's error messages could be better, but they…
> If there's one thing that I sometimes wish Lisp had, it's types. Let's write some very silly code to turn an integer into a list of digits in Common Lisp: (deftype Digit () "A non-negative integer smaller than 10." '(Mod 10)) (defun integer->digits (integer) "Turns a given INTEGER into a list of digits." (declare (type Integer integer)) (labels ((digit-loop (integer digits) (declare (type Integer integer) (type Lis…
Earlier quoted context omitted.
You don’t program in Lisp, do you? I used to be confused by the smug Lisp weenies. Now I am one. And the difficult thing I’ve found over the years is that Lisp is sort of unexplainable. You either “get it” or you don’t. Yes, it has macros, but macros are a bit overrated. I’ve been programming in Lisp for decades and I rarely write macros. I think the thing that is difficult to convey is how powerful Lisp’s core execu…
Is the magic a property of the broader language-family (and could be experienced with Janet, Racket, whatever), or Common Lisp specifically? When people praise the core execution environment they're typically praising Common Lisp specifically. What's the quintessential "now I get it" experience, in your mind?
Learning that https://calva.io/paredit/ exists and moving your cursor along the AST or moving expressions around with nice hotkeys. Then making simple macros for infix notation and SQL and so on, which operate on the AST too. Realizing that there is no "architecture" because any repeated code or pattern can be easily abstracted away with a macro. Realizing that you can just describe your problem on paper, making up the perfect notation, then implement that notation in a few hours.
Earlier quoted context omitted.
I suspect real ways to keep AI out of a community, or really to have an online community at all, are going to be structurally incompatible with making anyone rich. The possibility of getting rich poisons the incentives.
It can't just be money. It also has to remove any notion of score or ranking. There should be NO incentive to artificially increase anything. Look at Advent of Code. Free site, fun community, but it had a leaderboard. The moment AI was advanced enough, it began dominating the leaderboard. The solution: kill the leaderboard. Sure, you can still solve all the problems with AI and get yourself full points, but you're no…
Earlier quoted context omitted.
Fennel really is great, and a great way to get into the clojure family. My biggest gripe with it is that debugging is the typical transpilation bed of needles. The bridge between Fennel and the Lua VM is super fragile, and it just doesn't have half the quality of the Janet debugger and REPL. It's a real shame, because Fennel is way more portable, and thanks to LuaJIT is capable of breaking SBCL's jaw, which is absolu…
Relevant issue #1457 VM instrumentation for third-party tools https://github.com/LuaJIT/LuaJIT/issues/1457 was opened by Mike Pall as recently as three weeks ago. I gather that some features will be added to 2.1 but others only to 3.0.
Earlier quoted context omitted.
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.
AoT/JIT compilation is a property of the implementation, not the language. It would be good to know order of magnitude anyway. Like, are we talking Ruby/Python level, etc.
It’s faster than Python and Ruby, about as fast as non-JIT Lua.
Earlier quoted context omitted.
While I do not like the excess of parentheses of LISP and similar languages, their syntax is very consistent and predictable. Moreover, while LISP has an excess of parentheses, it omits a greater number of commas that are required in many other programming languages. I am much more annoyed by the random syntax inconsistencies of most popular programming languages, which are either caused by original language design m…
Now do for (i = 1; i with by. Now do if (x with fewer “syntactic tokens”.
It has forced all programmers to write everyday a lot of superfluous boilerplate for the most frequently used kinds of loops as the price for being able to write some very rarely used kinds of loops.
A much better solution would have been to keep the kind of "for" loop used in PL/I and ALGOL 68, 2 languages from which C has taken many other features, and to add an extra kind of "for", for the rarely used loops.
An even better solution had been found quasi-simultaneously with C in the programming languages Alphard and CLU, where instead of inventing this kind of complex "for", they invented iterators, which allow the writing of "forall" loops having the same form as that for arrays or for arithmetic progressions, but for arbitrary data structures.
Iterators solve in a more ergonomic way the problem for which the C "for" was invented, i.e. to write loops that visit all the members of a linked list or similar data structures.
Your example is also solved trivially in a language with iterators, you just define a geometric progression as a generic type and then you can write a "forall" loop that iterates over all its elements.
The fact that the language C permits to omit the curly braces around a single statement helps to reduce its excessive verbosity, but not enough.
In your "if" example, you have 4 syntactic tokens: "if", "(", ")" and ";".
This is still an extra token in comparison with ALGOL 68, where your example would be written so:
if x For the verbosity of a programming language, only the number of syntactic tokens matters, because, depending on the preferences of the programmer, one syntactic token can be represented by either a long keyword or by an abbreviation or by a single symbol.
If minimum verbosity is desired, single symbols can be used for each syntactic token, e.g. in my own programming language the 3 syntactic tokens of ALGOL 68 would be single symbols:
{ x Earlier quoted context omitted.
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 t…
What I have written above about the C-derived languages is a fact, not a personal opinion. Anyone who downvoted it has just demonstrated ignorance about programming languages. Too many modern programmers are familiar only with languages derived from "C", which have retained the bad syntax of C, despite criticizing C for unsafety or other such properties, and they do not know anything, or they know only incorrect myths, about the many other programming languages that have existed, and which frequently had certain features that were superior to any of the currently popular languages.
In another comment in this thread I have given a couple of typical program structures of the C programming language, which require a double number of syntactic tokens in comparison with well designed older programming languages, such as ALGOL 68 (which has been the source of several C features, but even some of those have been dumbed down a lot in comparison with the original, e.g. "union").
Earlier quoted context omitted.
This is such a undervalued benefit, once you've learned s-expressions, you can basically learn a bunch of languages without having to learn completely new syntax. It'll be slightly different, with different idioms and names, but a hell of a lot easier than doing the same across every "It's like C but 50% of the syntax is different actually" language out there, which is most of them.
Is the syntax really the stumbling block for most languages? Would Rust's lifetimes or Swift's isolation rules be easier if they used more parens? Are the scoping rule differences between Emacs Lisp and Scheme easier to comprehend because the syntax is similar?
So often people coming from one linguistic syntactical style express themselves in that style which makes their code in the new language less understandable or maintainable.