131–140 of 152 posts
> at a party, Sydney Von Arx asked if i could name 40 programming languages. An attempt (without looking) JavaScript QBasic PHP Haskell C C++ Ada Algol Racket Scheme Clojure Common-Lisp GOOL Fortran Awk Postscript Forth C# F# Lua Java D Odin Rust Zig Julia Python Nim MATLAB Bash Brainfuck Arnold-C Intercal Gleam Unison Ruby Crystal Erlang Go TCL Phew!
Earlier quoted context omitted.
I can't view the site (Org blocks github for reasons) but I suspect this would be a lot like forth if forth weren't so stack focused
Forth is at this point more of a culture than a language. It's a culture about keeping designs simple so that they're understandable. Without this, Forth is only powerful for programmers who can keep a lot in their heads, but lots of Forth programs end up being write-once. Moore's view, as well as most other high-level Forthers preach simplicity above all; a code cleanliness that would make Uncle Bob blush. Lean and…
As the saying goes, once you've seen one Forth, then you've seen one Forth.
I've mucked around with my own Forths in the past, including one that recognises lexical type, so you could build something like a parser in Forth. I didn't take it that far. Forth is normally conceived as being built from the ground up, but if you're you're going to implement it in C or C++ then you can be more imaginative.
I played around with colorforth for 5 minutes on a couple of occasions, but I ran away screaming. What - just what - the hell is going on? I'm sure it all works for Charles Moore, but for mere mortals it might as well be a klingon control panel.
I think Moore effectively gave up on programming a couple of years ago? There was some strange modification in the guts of Windows and he couldn't get his environment to work any longer. He concluded that the game was not work the candle.
Earlier quoted context omitted.
>You realize that "The Lisp Curse" isn't some paper, survey or objective reflection? It's just someone's essay back from 2011 - an opinion. It's also the deficit of code we actually use day to day that is actually written in lisp. I file it under the same heading as haskell - a language that clearly has useful ideas , but...
You're using Lisp software right now! I think this is the most treacherous assumption people tend to make about programming languages, for a few reasons. One of them is that we really don't have any way to measure software that we actually use day to day. Think about the software controlling your local water treatment plant, traffic lights, the software your local power company relies on, the software running the ser…
I know people who work in the embedded space working on stuff similar to traffic lights and LISP isnt even on their radar. Rust is. LISP isnt.
Every niche language has its fanboys who can end up using it all over the place but when it doesnt spread to non fanboys there is usually a reason to which they are wilfully blind, usually related to its practical value.
> because it's perfectable. it's not perfect, but it is perfectable. you can write down properties about Lean, in Lean. Homoiconicity anyone? Lisp is one of the oldest high-level programming languages, and it's still around.
Hm. Homoiconicity is not a well-defined term (see, for example, Shriram Krishnamurthi's thoughts [0][1]), but even skimming over that fact, it is a syntactic property, while the quoted line is about semantics . Switching your language to Lisp (or one of its descendents) doesn't gain you anything semantically. [0] Shriram is an original member of the Racket project, so he's been working in the Lisp-like domain for at…
Earlier quoted context omitted.
Some languages have only a single type, e.g. BrainFuck only has "byte". Shells tend to only have "string" as a fundamental type, and some helpers to do things like split strings on a separator & iterate over the elements or to treat strings as numbers to do arithmetic. Such single-type languages tend to be esoteric and/or difficult to program in, since every sort of data manipulation not supported by that type has to…
> Such single-type languages tend to be esoteric and/or difficult to program in, since every sort of data manipulation not supported by that type has to be done at runtime, by the programmer. It depends; I recall programming in Tcl in the late 90s, and that has only the string and the list as datatypes, but it felt very powerful, like Lisp but without the easy syntax.
Earlier quoted context omitted.
You're using Lisp software right now! I think this is the most treacherous assumption people tend to make about programming languages, for a few reasons. One of them is that we really don't have any way to measure software that we actually use day to day. Think about the software controlling your local water treatment plant, traffic lights, the software your local power company relies on, the software running the ser…
That's a lot of words to say a lot of FUD. I know people who work in the embedded space working on stuff similar to traffic lights and LISP isnt even on their radar. Rust is. LISP isnt. Every niche language has its fanboys who can end up using it all over the place but when it doesnt spread to non fanboys there is usually a reason to which they are wilfully blind, usually related to its practical value.
At no point does a post about "You can't draw sweeping conclusions about this kind of thing" imply "all dark matter tech relies on esoteric stacks". I'm not sure why you would even bring up that anecdote?
> there is usually a reason to which they are willfully blind, usually related to its practical value.
Lame passive aggression aside, I'm not a Lisp "fanboy" and I actively don't like the grain of the language. Language adoption is always down to familiarity, taste and ecosystem constraints. But I'm also not deluded enough to assert something like this because I actually know better. It's an argument that's always positioned without substance, because there can be none. You're positioning ignorant snobbishness as enlightened pragmatism, no offense but that's just pretense. If you can't get a Lisp program working on a 100mhz microcontroller with 5k of flash, that's kind of a skill issue dude.
Unfortunately Lean’s distribution went from somewhat about 15 MiB in times of Lean 3 to more than 2,5 GiB when unpacked nowadays for no good reason. This is too much. Even v4.0.0-m1 was a 90 MB archive. Looks like that Lean’s authors do not care about this anymore. Lean 3 was the least bloated theorem prover among Lean, Coq and Agda, and Lean 4 is the most bloated among this Big Three. This is very sad. Personally, I…
The name is amusingly ironic now.
The perfect programming language has: - The compile speed of Go - The performance of Go - The single binary compilation of Go - The type system of Kotlin - The ecosystem of JVM (packages for anything I could dream of) - The document sytem/tests of Elixir - The ability to go "unsafe" and opt for ARC instead of GC - The result monad/option monad and match statements from OCaml/Gleam - A REPL like Kotlin or even better,…
> The result monad/option monad and match statements from OCaml/Gleam Do you mean actual monads or just the specific result/option containers? If you mean a fully-fledged monad abstraction then you need a more sophisticated type system than what Kotlin provides (i.e. higher-kinded types).
Earlier quoted context omitted.
No, I realize that. It doesn't stop me from having my "perfect language wishlist". The author calling out "perfectable" is what got me thinking. What language would I choose if I were able to "perfect" it just a bit more?
But you had called your list "one size fits all".