7 ms·
> And that makes me grumpy sometimes. If you will excuse a moment of cheekiness... Could be that you have cause and effect backwards here: because you are gru
by lukego 10y ago
> And that makes me grumpy sometimes.
If you will excuse a moment of cheekiness...
Could be that you have cause and effect backwards here: because you are grumpy you are dismissing 99% of other language developers' work as rubbish. Could be that it's less than 99% and you are overlooking some great ideas.
- lisper 10y agoThat's not cheeky, it's a perfectly fair question. Yes, that is certainly possible. And there have been a few cool new ideas that have come along that are not easily subsumed by CL, like Haskell's type system. It's easy to implement Hindley-Milner, but actually using that information to inform the compiler, plus adding laziness as a core language feature, is much harder. But I think the jury is still very much out on whether or not Haskell is really a net win. But the most popular language on github at the moment is Javascript, and there is no question that it is simply a very badly designed Lisp with C syntax. This is not intended to disparage Brendan Eich. He had a week to design and implement something, and under those constraints he did a pretty amazing job. But I can't help but imagine how different the world would be if he had used Scheme as a starting point. Was there something in particular that you had in mind that you think I may have missed?
- gaius 10y agoBut I can't help but imagine how different the world would be if he had used Scheme as a starting point. I've heard that he did in fact use Scheme, but the suits insisted on the whole curly-brackets-and-semicolons thing so they could call it Javascript and piggyback on Sun's marketing efforts.
- lukego 10y agoMy take is that Language X usually has major deficiencies compared with Language Y for domain Z, for many values of X or Y: Lisp, Scheme, Smalltalk, Forth, Erlang, Haskell, assembler, C, etc. Confirmation bias makes it easy to bind those variables to values that make one's own favorite language obviously the best and everybody else's infuriatingly, irrationally terrible. If unchecked then this leads to wildly false conclusions, such as that languages fit into a hierarchy of powerfulness ("Blub Paradox.")
- lukego 10y agoTangentially: I am working with LuaJIT these days and this feels really exciting to me. The compiler is a new kind of beast and possibly the beginning of a large Lisp-like family tree. Feels very "MACLISP" to me - exciting!
- lisper 10y agoWhat do you see as Common Lisp's "major deficiencies"? (Pick your favorite value for Z.) This isn't a challenge, I'm genuinely interested in your answer.
- allenbrunson 10y agothat should be pretty obvious: lack of library support. there is the famous example of the reddit founders, who believed pg's lisp story, and built the first version of their site with it. it went so badly for them that they had to start over again in python. ... but i bet you are going to have a very plausible-sounding reason why it didn't work for them.
- lisper 10y agoI have no idea why Lisp didn't work for Reddit. But Common Lisp has exceptionally good library coverage today, and with Quicklisp, getting access to it is virtually seamless.
- allenbrunson 10y ago
- kazinator 10y agoSome functional languages make certain behaviors implicit, such as partial evaluation and laziness. However, these work better if they are explicit. They work better because one of the two is severely confusing when implicit and the other potentially performs badly. C:\Users\kaz>txr This is the TXR Lisp interactive listener of TXR 162. Use the :quit command or type Ctrl-D on empty line to exit. 1> (defstruct integers () val next (:postinit (me) (set me.next (lnew integers val (succ me.val)))) (:method print (me stream pretty-p) (format stream "#<integers ~a ...>" me.val))) #<struct-type integers> 2> (lnew integers val 0) #<integers 0 ...> 3> *2.next #<integers 1 ...> 4> *2.next.next #<integers 2 ...> 5> *2.next.next.next #<integers 3 ...> Why would I want implicit laziness everywhere? The best of all worlds is to have expressions reduced to their values eagerly before a function call takes place. When I don't want an expression evaluated in (what looks like) a function call, I can, firstly, make that a macro. If I really want lazy semantics, I can have a decent vocabulary of lazy constructs that fit into the eager language. For instance for making objects lazily I have lnew, distinct from new. Implicit laziness everywhere is academically stupid. You're drowning the execution of the code in an ocean of thunks and closures. The pragmatic approach is best of making a compromise between making everything explicit and visible, yet keeping it syntactically tidy and convenient.
- lisper 10y ago> Why would I want implicit laziness everywhere? For the same reason you want automatic memory management: so you can fob off the job of figuring out where the thunks should go onto the compiler, just as you fob off the job of figuring out where the calls to malloc and free should go. At least that's the theory. It seems plausible to me. I think it's an open question whether my failure to grok Haskell is due to a problem with Haskell or the ossification of my brain.
- AnimalMuppet 10y agoNot trying to troll you here... To what degree do you use Lisp as an FP language? As a pure FP language? The forced purity may make Haskell a very different language. And, to return to your original complaint: If you dislike new languages, I bet XML drives you straight up the wall...