Why do all lisp languages suck? Any sane person would agree that scheme-lineage languages (i.e. including racket and the like) are infinitely better-structured than the abomination that is common lisp. If languages were a purely academic pursuit then surely scheme languages would be near perfect. Writing in CL is practically like writing in C as soon as the program is any non-trivial, which defeats the whole point of not using C in the first place. Scheme-likes do not have that problem.
Unfortunately there is no lisp of any type with any good implementation. For example, they all have shitty gc with massive pauses, or massive overhead, or that leak memory (or all of the above, such as is the case in racket). Some don't even do anything without explicit gc calls (such as chez and ypsilon).
The gc also prevents all but chez (and bigloo?) and to a lesser extent racket (it is very limited but it's there) to support single-process multicore. But the problem isn't the gc but rather that each implementation has a garbage (haha) gc implementation (proof: none of the garbage collectors collect themselves).
How about a completely different massive wart: debugging and live programming. Gambit is pretty much the only implementation that supports restarts, and again it's quite limited. Other implementations don't even support that in the first place. Gambit's subrepls only evaluate at the current frame in interpreted code, if the compiled code breaks you have to evaluate in global scope exclusively, making them unsuitable for proper debugging.
As far as I'm aware, while racket is the worst offender there, none of the schemes have proper support for live programming. That is, when a change is performed, too much state must be reset and reloaded for actual use.
Common lisp implementations do not have these problems. Moreover, scheme implementations seem to have significantly worse error reporting than lisps', though lisps' aren't very good either most of the time. Since they have conditions and restarts, though, that's not much problem, unlike in scheme-land.
Other functional languages not in the lisp family (I'm talking mostly of the ML-family languages like ocaml, haskell and F#) manage to have (depending on which) competent gc's (parallel, low-pause gc's that don't block the existence of native threads), very high execution speed, efficient pattern matching, and optional (that is, hindley-milner based with proper inference, which is for all intents and purposes the same as optional) type checking (fantastic to help with program correctness). Typically, they have their own compiler-level extension systems ("macros", be it templatehaskell or camlp4/camlp5/ppx) as well. Unlike lisps, they can achieve sub-2ms max pause times on similar artificial tasks that take chicken 22ms, ypsilon 300ms, racket 50ms, and gambit 24ms pause times for example.
So what's the point of using a lisp since their strong points are directly mitigated and they don't offer any additional value other than these?
I'm not even going to talk about libraries or community because those can always be built or bootstrapped but it's a fact that they also impact the quality of the development experience with the language.
When are we going to get a lisp that doesn't suck? Lisp languages are objectively superior in design and features. Why can't they work in practice? Live image modifications and restarts are insanely powerful tools. Why do no schemes have them? Why is CL stuck in the 60's (despite having been formalized in 1996) to the point C is almost more expressive and more functional?
To be clear, I mean in non-academic pursuits. For sure, scheme is unparalleled to enable exploring language development and implementation technology.
Feel like implementing yet another lisp and see it go nowhere just so I can say "at least I tried". Who's with me?????
While I agree with you mostly and echo your sentiment, I think good CL programs are a lot more expressive than good C programs.
>>2
I'm exaggerating a bit but in my experience, the bigger the CL program, the more it looks like a C program, boilerplate and verbosity and all. They still make good use of macros but it's often doubtful whether the chosen macros add much (a lot of the time it's to avoid repeating a single trivial argument to a function call and such). The rate of use of higher-order functions in big CL programs is usually less than or equal to the use of the same in equivalent C programs (when counting both passing structs with function pointers and simply function pointers in C programs). CLOS is used, but it's often used in moderation (a GOOD thing, but that means that the useful properties of the language are being neglected).
An example of that is
http://www.ffconsultancy.com/languages/ray_tracer/verbosity.html
(though to be taken with a grain of salt since the author is a huge f# shill, formerly ocaml shill, and it's clear he took creative liberties in a few spots - the main principle still holds).
Another example (at the end), also to take with a grain of salt, perhaps a smaller one though (since it comes from norvig):
http://norvig.com/python-lisp.html
Finally, neither of these are real large lisp programs, I only chose them because I thought they were representative of what I see at large. Here's an example of a large lisp program that exhibit these patterns I talked about:
https://github.com/fare/asdf
For trivial examples, lisp can be shown to be much more expressive than C, but for non-trivial examples, that goes the other way, I find.
Scheme languages, on the other hand, really don't have that problem.
I am sure anyone who thinks non-trivial Common Lisp programs look like C has never written a non-trivial Common Lisp program. Why would the code look like C? Non-trivial Java, C#, JavaScript, Python, or Ruby programs don't look like C, and they have similar optimization requirements. Anyone who says C has comparable expressiveness to Common Lisp can't know what they're talking about the same way anyone who says C has comparable expressiveness to Python can't know what they're talking about.
>>4
Not an argument. An example was provided in >>3 which proves you're full of shit. Just as you say, java, C#, js, python or ruby don't look like C even in non-trivial cases. It's a major failure of cl in particular since scheme also doesn't have that problem.
Not an argument. you're full of shit
Go fuck a dead hooker. You're an idiot and idiots should be quiet. Common Lisp doesn't throw programmers into a quagmire of integer overflow, checking error return codes, using pointers for simulating multiple returns, stack overflow errors, use after free errors, and convoluted manual memory deallocation schemes. None of the examples >>3 provided show Common Lisp looking anything like C. The Norvig example shows, if anything, that Common Lisp is very similar to Python. The ray tracer example author blames a lack of pattern matching for Lisp and Scheme's verbosity, but both of them have pattern matching available, unlike C. Also, the ray tracer Lisp solution without pattern matching will be near identical to a Python or Ruby solution. Only idiots think because highly optimized Lisp subroutines look as ugly as C they might as well use Lisp instead of C. The Numpy people built a Python library with optimized C code running their speed critical parts, and Numpy is an excellent Python library. Lisp provides support for similar speedups without needing to use an FFI and C. There's little point in arguing with losers who start threads with names like "A lisp that doesn't suck" or the losers that support them, but maybe you'll learn something?
>>6
Today I learned that lisptard tears are more savory than the usual ceenbred's, and that lisptards seem to be a subspecies of the egyptian crocodile, as they live exclusively in the deepest parts of the nile. Thank you for this valuable lesson, master.
>>7
Usually when people are being mean to you it's because they're telling you to stop doing something or to go away. You're one of those whack jobs who's incapable of taking a hint and just continues to be retarded. Don't assert inane beliefs about things you have zero experience with and maybe people will be nicer to you. Lisp defeatism is a loser topic. Only losers publicly complain about things they've never really used because of baseless beliefs. Who would go on functional programming forums and say Haskell, OCaml, and F# are all shitty languages and ask for a functional language that doesn't suck? Who would want to listen to or be around someone like that? The toe dipping novice's opinion on what's good is not valued.
>>8
There's something different with Lisp. Criticism always come from people who used to love it. Lisp nears perfection in its formalism and it can be hard to forgive its flaws.
On a side note I would really love to work with F#.
oh noes someone has valid arguments that I can't argue against!
h-h-he j-just d-doesn't k-k-know what he's t-talking about
I wiiiiin!
Yum yum yum, keep crying. Your tears are my sustenance. Meanwhile the work on building a lisp that doesn't suck ass like common "C but somehow uglier and less expressive" lisp does as demonstrated in production-grade software like asdf is going great, thank you very much. Don't worry, it won't be a lisp-2 (more like lisp -2 because it's so backward).
Criticism always come from people who used to love it.
I wish. It seems to always come from people who used to love it, but never used it.
>>10
Of course the guy who never uses Lisp would rather implement a Lisp system than use one.
>>11
Lisp is easy enough to implement. Everybody does that at one point.
>>12
Of course Lisp is easy to implement, but implementing a robust, efficient, standard compliant Lisp system is not. Even getting the first two in any language is a real achievement. Python, a language with a reference implementation instead of a standard, can barely manage the first two.
For those unaware, Python's GIL, global interpreter lock, is why thread level parallelism is impossible using Python's standard library's 'threading' module. Getting true multi-threaded support without a performance drop on single-threaded applications is too hard to implement, so Python can only run one thread at a time. Programmers familiar with green threads are probably unsurprised by this, although I'm sure they're imagining an improved scheme where Python allocates green threads onto OS threads and each OS thread has a kind of local GIL on the green threads it owns. The weird part is, Python doesn't use green threads! As of 2016 (I think), and perhaps still today, it instead works in an ass backwards way. Every thread in Python is an OS thread, but every OS thread except one is blocked from running. This means you get none of the speedups of parallelism, but all the cost of context switches. You can make multi-threaded Python code faster by turning off CPU cores. This has been measured. https://www.dabeaz.com/python/UnderstandingGIL.pdf Python is a internationally known language taught in esteemed universities and used everywhere from web shops to research facilities and consulting firms. It took a lot of work to reach the embarrassingly bad efficiency Python has now.
Writing a lisp is a similar goal to building a game engine. You can learn some interesting techniques and make someone go "oh cool, you wrote a toy lisp" but never produce anything of real merit or value.
Of course implementing a simple Lisp is fun, and fun things don't need to be justified. Just don't confuse liking something with enjoying building knock offs of it. And don't be the guy who never used the real thing and claims their knock off will be better than all those things they never bothered to learn about. Talk about NIH.
>>13
Nobody cares about cl (aka crappy lisp). When people say lisp, they mean a competent lisp language like scheme. Fuck off with your irrelevant musing and retarded ass-backward shilling. Either address a point or admit you're wrong. Or fuck right off, you useless waste of oxygen.
>>14
Your points were addressed. Your links were shit. You were wrong and now you're taking it personally. You think I don't use or like Scheme, just because I called you out on your baseless Common Lisp complaints. If anything, you hate Scheme since you wrote that every implementation sucks. You seem to be unaware that Mark Tarver, Alexander Burger, and Lutz Mueller have already all tried to make a non-scheme non-common lisp and made significant progress. See Shen, newLISP, and picolisp.
http://www.shenlanguage.org/
http://www.newlisp.org/
https://picolisp.com/wiki/?home
Behold, people who managed to actually do something instead of whine about languages they never really used.
>>15
You have yet to address a single point or in fact do anything beyond digressing. Not too surprised though, only the clinically insane could possibly defend the absolute state of lisp languages.
You have yet to address a single point or in fact do anything beyond digressing.
These are the ravings of a paranoid lunatic. If you want evidence that I've addressed your points all you have to do is scroll up, but nothing I could say would ever satisfy you. I guess it's easier for you to fight convenient caricatures of me than to face the real world. When your shrink and you have worked out what you are really afraid of, let's get back to this discussion. until then, it is clear that you are quite irrational and have lost basic contact with reality.
clinically insane
The irony is rich.
M-x erybody-chill
going on a lisp-chan to talk shit about lisp
going on a anime website to talk shit about anime
going on website about X to talk shit about X
((λ (x) `(,x a gay)) 'you)C-s clojure
Failing I-search
Clojure suffers from some of those points you mentioned.
- JVM has a massive overhead
- error messages are notoriously shit
- no builtin restarts
but on the bright side,
- live programming is well supported in Clojure
- JVM supports multi-threading
- there are Clojure libraries
- there is a Clojure community