21–30 of 31 posts
Because static typing is important for working productively with medium-to-large programs, because the Lisps have decrepit ecosystems, and because they aren't even good dynamically typed languages either, with the possible exception of Clojure. There is nothing that Common Lisp has, that other languages don't have, that makes it necessary.
I've read a lot about Lisps with an open mind, worked through SICP in Racket, and worked on some personal projects in Clojure. It was all fine, but at no point did I feel like there wasn't another language that would have done as well, possibly better. The one area where I was never fully comfortable was the lack of static type checking. I've also dabbled with Haskell and though it it is the most clean and consistent…
I've read a lot about Lisps with an open mind, worked through SICP in Racket, and worked on some personal projects in Clojure. It was all fine, but at no point did I feel like there wasn't another language that would have done as well, possibly better. The one area where I was never fully comfortable was the lack of static type checking. I've also dabbled with Haskell and though it it is the most clean and consistent…
Right. Lisp totally outshines every other language at building DSLs, so if you reconceptualize your project as a bunch of DSLs that utilize one another, you win big with lisp.
Earlier quoted context omitted.
Right. Lisp totally outshines every other language at building DSLs, so if you reconceptualize your project as a bunch of DSLs that utilize one another, you win big with lisp.
What I'm finding is that I can effectively do the same with a statically-typed functional language. The worst are DSLs with poor grammar and concept-fit which add-to rather than solve problems. The ways in which Lisp doesn't scale (people-wise) are well known and relate to each application essentially being its own programming language.
Well, memes about Lisp not scaling people-wise are well-known on forums like HN.
The actual data on this is lacking, like reports about someone having actually gathered five hundred Lisp developers onto one project and failed.
> each application essentially being its own programming language
Meme-fueled nonsense, I'm afraid.
Every complex application in any language is its own programming language.
New types and functions introduce new syntax, just like macros, along with new semantics.
So you know C? Okay, what's this, from the Linux kernel?
struct usb_host_endpoint {
struct usb_endpoint_descriptor desc;
struct usb_ss_ep_comp_descriptor ss_ep_comp;
struct usb_ssp_isoc_ep_comp_descriptor ssp_isoc_ep_comp;
struct list_head urb_list;
void *hcpriv;
struct ep_device *ep_dev;
unsigned char *extra;
int extralen;
int enabled;
int streams;
};
Guess what, this is new syntax. No, wait, what, it's just using the regular C grammar, right? How can it be new syntax? The same way that a Lisp program have new syntax if continues to be made out of parentheses, symbols, strings, numbers that conform to a rigid grammar.
The new syntax is in the schemas built with the definition abilities provided in the underlying fixed grammar.
Earlier quoted context omitted.
What I'm finding is that I can effectively do the same with a statically-typed functional language. The worst are DSLs with poor grammar and concept-fit which add-to rather than solve problems. The ways in which Lisp doesn't scale (people-wise) are well known and relate to each application essentially being its own programming language.
> The ways in which Lisp doesn't scale (people-wise) are well known Well, memes about Lisp not scaling people-wise are well-known on forums like HN. The actual data on this is lacking, like reports about someone having actually gathered five hundred Lisp developers onto one project and failed. > each application essentially being its own programming language Meme-fueled nonsense, I'm afraid. Every complex application…
Earlier quoted context omitted.
> The ways in which Lisp doesn't scale (people-wise) are well known Well, memes about Lisp not scaling people-wise are well-known on forums like HN. The actual data on this is lacking, like reports about someone having actually gathered five hundred Lisp developers onto one project and failed. > each application essentially being its own programming language Meme-fueled nonsense, I'm afraid. Every complex application…
Perhaps less well known are the well-meaning explorations into why isn't Lisp more popular. The absence of a 500 Lisp developers on one project is itself the datapoint being discussed.
The vast majority of all software tech ever invented is unpopular today. If we just pick a tech stack, language, editor, OS or anything from the last 70 years at random, it's almost certainly unpopular. That's our first-order effect that forms the bulk of the rational explanation for why anything is unpopular. By definition, not everything can be popular: popularity is the selection of a very small number of artifacts (almost always chronologically recent) to the exclusion of everything else.
Earlier quoted context omitted.
That‘s a pretty opinionated statement... Could you elaborate on why you think the Lisps aren‘t „good dynamically typed languages?“ And I don‘t think „necessary“ is a good metric when comparing programming languages; „pleasant to use“ or „efficient to write“ strike me as more pertinent (as well as the obvious runtime efficiency questions).
Use of a bad language like C or Java or Emacs Lisp (if that can be called bad) can be necessary -- the best choice. I don't have a novel explanation of what makes Common Lisp and Scheme bad dynamically typed languages, just the ordinary obvious reasons, so there's no point in writing it out.
And as an aside: what makes you call C and Java „bad languages“? (Especially since you are so much in favour of static typing?)
Earlier quoted context omitted.
What I'm finding is that I can effectively do the same with a statically-typed functional language. The worst are DSLs with poor grammar and concept-fit which add-to rather than solve problems. The ways in which Lisp doesn't scale (people-wise) are well known and relate to each application essentially being its own programming language.
> The ways in which Lisp doesn't scale (people-wise) are well known Well, memes about Lisp not scaling people-wise are well-known on forums like HN. The actual data on this is lacking, like reports about someone having actually gathered five hundred Lisp developers onto one project and failed. > each application essentially being its own programming language Meme-fueled nonsense, I'm afraid. Every complex application…
In any case, "When and where is this allocated? What does it represent? How do you use it?" is just C. The computational model hasn't changed.
Earlier quoted context omitted.
Use of a bad language like C or Java or Emacs Lisp (if that can be called bad) can be necessary -- the best choice. I don't have a novel explanation of what makes Common Lisp and Scheme bad dynamically typed languages, just the ordinary obvious reasons, so there's no point in writing it out.
Unfortunately, my CS background isn‘t strong enough to see the „ordinary, obvious reasons“. But I do like Common Lisp, so I am rather interested in discovering what bothers you about it? And as an aside: what makes you call C and Java „bad languages“? (Especially since you are so much in favour of static typing?)
In C it's easy to make mistakes with gotchas like implicit conversions, and nowadays it's archaic, lacking in basic features it could have, e.g. something akin to D's scope(exit) statements.
In Java it's very expensive, in effort and code bloat, to define new types; in general the language actively fights against making well-organized program, or even just moving data around.
With Scheme or Common Lisp, you might look at Clojure or Oz for some inspiration (as well as features we take for granted in Perl/Python/Ruby/PHP/JavaScript) in regard to what sort of features might make a dynamically typed language, even a Lisp, "not bad." Part of it is that statement-based function bodies are actually a good thing, and infix syntax is a good thing. Scheme is just lacking in basic stuff you need, and it relies on tail calls without explicit tail call syntax. And it has call/cc. Common Lisp is bad in detail -- it has all sorts of clever little features, like setf, that don't solve real problems, they solve Lisp problems. And they handle defining and using new types badly, even simple ones like plain record types. Back in the day, CL's advantage was that the competition was so weak. If you gave CL the Python or JS ecosystem today, it would be usable, but that's the nicest thing you can say about it.
Earlier quoted context omitted.
Perhaps less well known are the well-meaning explorations into why isn't Lisp more popular. The absence of a 500 Lisp developers on one project is itself the datapoint being discussed.
The absence of that is because it would require a substantial global recruitment and relocation effort to get that many Lispers into one organization. It speaks nothing to their ability or inability to co-operate on a project. The vast majority of all software tech ever invented is unpopular today. If we just pick a tech stack, language, editor, OS or anything from the last 70 years at random, it's almost certainly u…
Likewise during the last seventy years some languages saw wild uptakes in popularity for some languages much later in their life-cycle. Who would have expected the modern successes of Ruby?