The Lisp Curse (2017)(winestockwebdesign.com) |
The Lisp Curse (2017)(winestockwebdesign.com) |
A lot of people are very into whatever the language is, but for me, I want a huge standard library.
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]
obj_send(foo, msg_foobarboo, baz, hoo);
An alternative would be Turbo Pascal 5.5-style OOP where
struct foo : base {
foo();
~foo();
void blah();
}
foo::foo(){ base(); }
foo::~foo(){ ~base(); }
void foo::blah(){}
struct foo foo;
foo.foo(); /* call constructor chain */
foo.~foo(); /* call destructor chain */
struct foo* foo = malloc(sizeof(struct foo));
foo->foo(); /* call constructor chain */
foo->~foo(); /* call destructor chain */
free(foo);
Of course unlike a language with Lisp-like macros you'd need to modify a compiler or write a preprocessor to do the above, which makes it a bit harder, but in any case adding object orientation to C does not mean you have to make it as complex as C++.
var result = call(foo, "bar: %s boo: %f", baz, hoo);
Dynamic typing, arbitrary messages, and no memory leaks. Just like Lisp. It's not perfect (string message could have typos, and might use %p for objects), but it's not too bad.
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.
From the author's home page.
Edit: Potentially ignoring that quote - I can't help observing that although I used Common Lisp as my main development language for 6 years in an academic research environment and really enjoyed it I've never wanted to use it since then...
There are still a lot of interesting things happening with Lisp, but I can't see how Common Lisp will be the path forward. Of course, there have been many challengers seeking to upset it as King Lisp, including this site's very own Arc. Clojure has seen the most commercial success in recent years, though the extent that it's actually a Lisp is debatable. I'm a fan of Kernel [0], which makes macros first class members of the language, like everything else. Who knows, but saying it's power will necessarily lead to its downfall is a kind of fatalistic mentality that I have little patience for.
Check out https://github.com/factor/factor. Check out how much stuff they have implemented early on, just 2-4 guys tops. I found it really impressive.
Note that you can still build useful programs this way since such languages can still allow certain forms of recursion such as primitive recursion, structural recursion etc... You can also use sized types [1] to allow even a larger set of (halting) programs.
[1] This is a way of compiler statically analyzing the size of each type (i.e. how many recursive constructors necessary) which puts an upper bound on the number of recursions need to be performed.
Now if you want to gain the ability to make serious proofs about your programs, one can make the argument you need non-TC.
Perhaps The Curse is because Lisp programmers are generally of the same ilk as mathematicians and physicists?
Strongly disagree with this statement. I've read it so many places now that it has to be a meme. I actually wish I could use C++ on the web instead of this JS nightmare ecosystem. I don't understand where the idea comes from. I'm never "bit-fiddling" in C++ and almost never need to use pointers.
otherwise, he speaks from my heart. social issues only
> Update on October 6, 2017. N.B.: Please stop submitting this to Hacker News! Look at the Hacker News search results for this essay. Check out the note for the first entry: Come on, everyone! Let's beat the dead horse one more time!
Past discussions https://hn.algolia.com/?query=The%20Lisp%20Curse&type=story&...
Perhaps the author is confusing the norms with Reddit where in many subreddits reposts are often frowned upon.
There have been plenty of old articles that I've seen for the first time in a repost.
I wonder why the author is upset about the posts. Does it generate too much costly traffic? Do they receive a lot of e-mail because of their essay?
People resubmit stories all the time, new and better (or different) discussions form around each resubmission, and new people get to read it.
That's because most programmers are incapable of making any informed decision about the language they use (and, even more so, about languages they don't use). There's a strong tribal mentality, a lot of cargo-cults, and the very narrow perspective on what's possible and (more importantly) what's desirable is prevalent.
[1] https://www.erlang.org/doc/programming_examples/bit_syntax.h...
Welcome to Clozure Common Lisp Version 1.11-r16812M (DarwinX8664)!
? #*010010010101001
#*010010010101001
? (type-of *)
(SIMPLE-BIT-VECTOR 15)And whoever wishes to use C++ on websites... who is stopping you since Webassembly? Speaking about ecosystems... I also don't think the package management ecosystem in C++ is that much better, right? And there are enough horror stories about illegibility and foot-guns even in modern C++ code, rivaling the worst YOLO frontend style...
C++ requires you to be a lot more verbose and precise for almost everything. That translates to more work, and the benefit isn't automatically worth anything.
I've been, on and off, working on a little toy game engine, for a few years. Its a mix of keeping up with C++ advancements, learning various concepts like physically based rendering, and just the fun of crafting a big project, with no constraints other than my time and ability, no deadlines, no expectation of releasing anything. Its cathartic and enjoyable. I really do enjoy it.
Last September, I got frustrated with something I was working on in a more serious capacity. It was some server software, it responded to HTTP requests, it accessed third party services over HTTP and Websockets, it talked to a Postgres database. Overall it was an event driven system that transformed data and generated actions that would be applied by talking to third party services. The "real" version was written in Clojure and it worked pretty well. I really like Clojure, so all good.
But because I was frustrated with some things about how it ran and the resources it took up, I wondered what it would be like if I developed a little lean-and-mean version in C++. So I gave it a try as a side project for a few weeks. I used doctest[1] for testing, immer[2] for Clojure-like immutable data structures, [3] lager for Elm-like application state and logic management, Crow[4] for my HTTP server, ASIO[5] and websocketpp[6] for Websockets, cpp-httplib[7] as a HTTP client and PGFE[8] for Postgres, amongst some other little utility libraries. I also wrote it in a Literate Programming style using Entangled[9], which helped me keep everything well documented and explained.
For the most part, it worked pretty well. Using immer and lager helped keep the logic safe and to the point. The application started and ran very quickly and used very little cpu or memory. However, as the complexity grew, especially when using template heavy libraries like lager, or dealing with complex things like ASIO, it became very frustrating to deal with errors. Template errors even on clang became incomprehensible and segmentation faults when something wasn't quite right became pretty hard to diagnose. I had neither of these problems working on my game engine, but both became issues on this experiment. After a few weeks, I gave up on it. I do think I could have made it work and definitely could go back and simplify some of the decisions I made to make it more manageable, but ultimately, it was more work than I had free time to dedicate to it.
So my experience was that, yes, you can write high level application logic for HTTP web backends in C++. You can even use tools like immer or lager to make it feel very functional-programming in style and make the application logic really clean. Its not hard to make it run efficiently both in terms of running time and memory usage, certainly when comparing to Clojure or Python. However, I found that over all, it just wasn't as easy or productive as either of those languages and I spent more time fighting the language deficiencies, even with modern C++, than I do when using Clojure or Python.
I think I would think very long and hard before seriously considering writing a web backend in C++. If I had the time, I'd love to retry the experiment but using Rust, to see how it compares.
[1] https://github.com/doctest/doctest
[2] https://github.com/arximboldi/immer
[3] https://github.com/arximboldi/lager
[4] https://github.com/CrowCpp/crow
[5] https://think-async.com/Asio/
[6] https://www.zaphoyd.com/projects/websocketpp/
[7] https://github.com/yhirose/cpp-httplib
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 standard libraries and marketing. Google invested millions into these two things, so people use their decidedly inferior language.
You'll find that pretty much every big language has a big company behind it that threw tons of money at its development.
I tried http://mlton.org/ConcurrentML but gave up due to lack of time and the state of the documentation.
Another answer that hasn't been discussed much is that... maybe it isn't better for development. The article discusses one way in which this could be true: that technical superiority essentially leads to a hopeless community fragmentation that more or less forces it to be inferior in terms of community effects (which are, presumably, more important for commercial development rather than individual development).
A different facet, though, is that I believe the better language isn't the one that gives you more powerful tools to write correct code, but the one that keeps you from writing incorrect code (while still letting you write correct code). A salient example here is goto. Most modern languages don't have the goto keyword anymore, but they instead retain things like break, continue, and early routine... all of which are restricted forms of goto. By using only these restricted forms instead of the general form, it is much easier to immediately see what the code is doing (and presumably quicker to understand why), even though it may strictly be less powerful.
Same reason most of us use QWERTY keyboards instead of one the many better layouts available. After a long enough time as the dominant tool, things get locked in regardless of whether or not they're the best tool for the job. C-Style languages gained dominance early on and became the defacto standard.
Many people here are coders, not writers, and the layout for generating human language is irrelevant. With QMK firmware tap-hold, and one finger each hand chording, one opens up a quadratic expansion of expressibility, all near home row. Now one can automate all frequent actions (VSCode commands, application launches, windowing scripts) as paired keystrokes.
Keyboard layouts should be the poster child for "Don't get sucked into taking the problem statement as given, THAT's usually what needs questioning."
If you have ever taken a train or subway in Europe, you depended on Lisp.
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 may be asked and answered ad nauseam, bit it’s worth answering in the context of the very article discussing the Lisp curse.
Read TFA. What if every programmer rolling their own version of everything makes it an astoundingly good language for people but terrible for gaining industry-wide adoption?
JavaScript had this problem with every framework implementing its own OOP. Ember.js comes to mind as a recent example. The language stewards added a class keyword to ES6 in large part to quash further Balkanization of JS OOP.
Why didn’t JS wither while Lisp did? Ah! The answer is very relevant to your question. Every popular language began as the scripting language for an explosively successful platform.
JavaScript being the only way to script browsers bought it over a decade of time to fix its warts while it really wasn’t a “good” general-purpose language strictly on its merits.
Likewise, C and C++ were the scripting languages of Unix and Windows native application development. Ruby is the scripting language of Rails, for another example.
What is Lisp the scripting language of? A CS wag would reply, “Lisp!” And that is simply not good enough to motivate enough people to standardize the things that would lead to widespread adoption.
It’s a social problem, just as TFA says. Which leads us to a different essay about Lisp succeeding and failing:
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), ...
“Another interesting answer assumed that “the test of time” is somehow a cosmic optimization. But as every biologist knows, Darwinian processes “find fits” to an environment, and if the environment is lacking, then the fits will be lacking. Similarly, if most computer people lack understanding and knowledge, then what they will select will also be lacking. There is abundant evidence today that this is just what has happened.”
Exactly. If we used popularity and usage rates as the measure of merit, we'd have to conclude that the highest quality restaurant in the world is MacDonald's.
I'm a happy qmk enthusiast. My point was that the overwhelming majority of people will stick with the defaults for most things, which is why usage and adoption rates are not always a good indicator of the quality or utility of a tool.
1> A = 2#0010010010101001.
9385
2> << _:2, B:4, _/bitstring >> = << A:16 >>, 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 << 2#01...:N >> in Erlang, but you need to give the N (number of bits) yourself, so it's a bit less convenient.
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.
C++ doesn't only require you to be precise, it requires you to be verbose. JS is quite precise, and a lot more expressive because of the runtime. TypeScript is all of this and also allows you to be more explicit in order for the compiler to check your work, much like a proof checker.
The C++ type system is relatively stupid compared to that of TypeScript and F#, for example. In TS and F#, you can use types to help you, in C++ you already need the types because otherwise the compiler doesn't have a clue what to do.
Case in point: I looked into Agda and ended up in a deep rabbit hole that involved something I had never heard of called "Walther recursion." Whether this qualifies as "nearly impossible" or merely "hard" is quibbling over terminology, not substance.
Isn't it so? The meal is enough healthy (for hard-workers only, not for calories-gathers), calorage as I have mentioned is excellent, waiting is minimum, non-meal payings (keeping the restaurant attractive) are the lowest possible, the most important thing is that in poor countries (my is in the bottom of bigmac index) the prices are lower than anything else available in big cities.
As for price - not sure what you mean by "poor" countries. In the ones I've traveled to, McDonald's is considered a high end restaurant and is not cheap by the local standards.
What do you think is needed to be add or to be removed?
> The nutrient content is poor
Can you disclosure your information a little bit? Maybe you have a link to some publications or anything better then just an opinion.
> potatoes are cultivated with nasty insecticides
Of course they are, or you know any better protection from colorado beatle? If you are living in America or in another place where transportated species are not a problem for your local nature - you can not even imagine what a hard problem is to beat a specie which has no nature enemies.
> shit in the meat, etc, etc Well, I don't know where to get better ingredients then MacDo has gotten. I definitely not sure that meat in my fridge has no shit tbh.
call(
window, "draw: %d %d %p", x, y,
alloc("Circle radius: %d color: %u", r, 0xFF0000)
);
This is all in response to the article claiming you "need to be Bjarne Stroustrup to add OOP to C, but it's a sophomore assignment to add it to Lisp". If I hadn't mentioned the GC, someone else would've jumped on the example for how unpleasant manual memory management is in comparison to Lisp.
> If you're willing to use a garbage collection library [0], you can even have a pleasant syntax for ObjectiveC style OOP in C:
That sounded to me as if you were claiming that GC is a pre-requisite for having a particular syntax. But I gather that's not what you meant. I'm still a little unclear about what you actually meant. You can have memory leaks like the one in your example above in vanilla C without any OOP features at all. GC is completely orthogonal to OOP, and both are completely orthogonal to syntax.
var temp = alloc("Circle radius: %d color: %u", r, 0xFF0000);
var ignored = call(window, "draw: %d %d %p", x, y, temp);
drop(ignored);
drop(temp);
Neither the Clojure page, nor its users seem to agree with you.
But it's "a Lisp" in the colloquial sense that it uses s-expression syntax and has macros.
- 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)