> Employers much prefer that workers be fungible, rather than maximally productive.
This. A maximally productive non-fungible employee has leverage, and employers hate that more than just about anything.
The Lisp Curse (2017)
61–70 of 93 posts
Re: The Lisp Curse (2017)
#62I just wish more people understood that something being Turing Complete isn't a feature, it's a flaw.
Turing completeness may be a flaw, but it is nearly impossible to avoid.
Re: The Lisp Curse (2017)
#63If Lisp is do efficient for development, why are there essentially no commercial products that use it?
> If Lisp is [so] efficient for development, why are there essentially no commercial products that use it? I’m sorry you’ve been downvoted for asking this question, even if it was a rhetorical question. It’s easily the most important question to ask in the professional programming area, and it’s worth the effort to truly grok the answers rather than look up what everyone seems to say and then repeat it as gospel. It…
Lisp was the main language of Symbolic AI. That market largely crashed in the 80s/90s.
Planners&scheduling in the military&logistics (airlines, airports, train operators, satellites, ...), expert systems for maintenance, computational engineering systems (for example for airplanes from Airbus and Boeing), theorem provers (used in chip design), symbolic mathematics, natural language systems (text translation for the EU), ...
Re: The Lisp Curse (2017)
#64Earlier quoted context omitted.
In my experience the best for "bit-fiddling" is Erlang (and, by extension, Elixir) which offers bit-string literals[1], along with pattern matching on them. It's trivial to implement any binary protocol or parse any binary file format with these. It makes bit-fiddling pleasant and fun, but nobody ever mentions Erlang in these discussions. That's because most programmers are incapable of making any informed decision a…
Common Lisp has bit string literals: Welcome to Clozure Common Lisp Version 1.11-r16812M (DarwinX8664)! ? #*010010010101001 #*010010010101001 ? (type-of *) (SIMPLE-BIT-VECTOR 15)
I think it's not unusual to have base-x number literals (even Python got `0b01101` literals at some point), but not many languages support pattern matching on bitstrings. In Erlang, it looks like this:
1> A = 2#0010010010101001.
9385
2> > = >, B.
9
3> io:format("~.2B~n", [B]).
1001
CL doesn't have pattern matching in the standard, IIRC, but there are libraries implementing it, so I wouldn't be surprised if one of them also offered bitstring matching, but that's beside the point: I'm comparing Erlang and C++ here, not Erlang and CL.
[1] It could be 14 or 15 bits, but I wanted to have a bit of a leading padding to ignore in the pattern.
EDIT: I missed the fact that the #*01... literal in CL is not a number, my bad. The equivalent literal would be > in Erlang, but you need to give the N (number of bits) yourself, so it's a bit less convenient.
Re: The Lisp Curse (2017)
#65> Making Scheme object-oriented is a sophomore homework assignment. On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup. C++ added a ton of additional stuff to C. The original Objective-C is a much simpler approach on adding object orientation to C and at its core it'd all be about finding expressions like [foo bar:baz boo:hoo] and replacing them with something like o…
What’s the point of a constructor that isn’t called immediately? Couldn’t you just use any arbitrary function at that point?
If a constructor is called automatically then it also needs the destructor to be called automatically and both introduce a bunch of additional complexity, especially for stack allocated functions, the need to take into account the concept of a default constructor (not necessarily requiring it but still needing to consider it), etc so that someone doing...
while (something) {
foo foos[42];
/* use foos here */
}
Meanwhile by doing it manually you just bypass all that complexity at the language level and it becomes the programmer's responsibility to do it (or not) properly.
Also while you often want the above, this isn't something you always want, e.g. when you need to differentiate between where the memory of "foo" comes from and its lifecycle as an object (e.g. custom memory allocators, reusing objects without allocating/releasing their memory, etc).
Of course all the above could be done with functions too, after all there are a bunch of C programs and libraries doing OOP without the language itself providing any support for it.
Re: The Lisp Curse (2017)
#66Earlier quoted context omitted.
StandardML vs go is a great illustration. StandardML is just as fast, is more simple to learn with more simple syntax and basically zero gotchas, has more powerful syntax, has an actually sound type system (which has better generics than the ones proposed in go), does a better job at defining public functionality (via modules), has a better CST model, and many other great features. The only area where it loses is sta…
SML is great as a language, but has terrible tooling and a balkanized ecosystem of incompatible implementations, many of which only support REPL workflows (and these tend to be the implementations used for teaching). These are a far cry from the typical "point a compiler at a build file and go" that developers are used to. Go may be a strictly worse language as a language but still be better for building and distribu…
SML doesn't have "incompatible" implementations per-se. If you stick with what the standardized language and basis libraries specify, your code will compile everywhere (I don't know of any popular implementation that doesn't support the spec). If you use their proprietary extra features, then portability will naturally go down.
The primary means of developing uses SML/NJ for development and MLton for the final, optimized build. Both use the same Compilation Manager[0] and generally share the same ecosystem so using them together pretty much just works.
Re: The Lisp Curse (2017)
#67Earlier quoted context omitted.
> If Lisp is [so] efficient for development, why are there essentially no commercial products that use it? I’m sorry you’ve been downvoted for asking this question, even if it was a rhetorical question. It’s easily the most important question to ask in the professional programming area, and it’s worth the effort to truly grok the answers rather than look up what everyone seems to say and then repeat it as gospel. It…
Lisp was the main language of Symbolic AI. That market largely crashed in the 80s/90s. Planners&scheduling in the military&logistics (airlines, airports, train operators, satellites, ...), expert systems for maintenance, computational engineering systems (for example for airplanes from Airbus and Boeing), theorem provers (used in chip design), symbolic mathematics, natural language systems (text translation for the E…
Would you agree that the general term for the market crash is the "AI Winter?"
Re: The Lisp Curse (2017)
#68I would argue that rather than some curse of expressiveness, the lackluster showing from the community in recent years has been the results of a premature standards process. Common Lisp hasn't changed since before I was born, and while to some people that denotes stability, it also leaves new features to be done in the manner the author describes, as 80% projects by lone hackers. The language is more than capable of…
I'm curious; what is Clojure missing a Lisp?
I've seen people report lack of deeply capable repl, slime a few times. People don't like immutable first too (maybe they prefer metaobject update protocols).
Re: The Lisp Curse (2017)
#69Mathematicians and physicists would rather use another's toothbrush than another's notation.
Perhaps The Curse is because Lisp programmers are generally of the same ilk as mathematicians and physicists?
Re: The Lisp Curse (2017)
#70Earlier quoted context omitted.
But Clojure is not a Lisp. It is Lisp-adjacent, a bit, but it is really not the same language.
Let's see: - Insists on every expression being (wrapped (in parenthesis)) - Uses polish prefix notation - Profound belief that recursion is more intuitive than loops - Macros everywhere, because code is data, so why not? - Whole language built from a very small set of axioms - REPL-based workflow QED Clojure is _a_ Lisp. (FWIW I'm learning Racket right now)
Lisp: "List processing". Clojure doesn't even have cons cells... A Lisp without cons cells is like a C derivative without pointers...is it really C at that point? I'd also question the "profound belief that recursion is more intuitive than loops" since Lisp supports loops extremely well -- better than most languages, since you can build up your own iterative constructs using tagbody. And Clojure doesn't even have proper tail calls, so I doubt that Clojure actually believes in recursion.