Earlier quoted context omitted.
I think the whole enlightenment thing w.r.t. lisp is overblown.
lol @ random downvotes for criticizing lisp. Set and match.
I don't think that any Lisp programmer downvoted him.
Learn Lisp the Hard Way
131–140 of 144 posts
Re: Learn Lisp the Hard Way
#132Earlier quoted context omitted.
You could choose to understand it that way, but only if you want to kill the conversation. Which is fine, of course. Judging by the amount of controversy mirrored in the voting of my comment (I suspect moderator intervention was involved as well), a large number of HNers really do believe that all non-Lisp languages are abominations, that there is no appropriate paradigm besides Lisp's, and that Lisp already contains…
Try Lisp. You'll see most modern languages -- Objective C, Ruby, Java, &c -- and not so modern languages as well, don't have much that Lisp doesn't offer. That the pomposity may not be the best way is but a matter of opinion. But features? We can sit down and count those. I encourage you to learn Lisp. It's enlightening.
What makes you think I don't know Lisp? You didn't even read my comments, did you?
Re: Learn Lisp the Hard Way
#133Earlier quoted context omitted.
I wouldn't say "lies" so much as overly optimistic opinions. The idea that you can write a useful program in Lisp faster than in other languages is pretty unsupportable. For most users, the time and effort spent getting Lisp up-and-running on their machine of choice will already have lost. Incidentally, I played with the interactive REPL and it wouldn't advance beyond the second page. And, if you do write a useful pr…
The only thing that makes programs easy to deploy is the popularity of the language/environment they're written for. If the language you're using is popular enough that you can download the implementation using your system's package manager, deployment is easy. If not, it's harder. And for any language that's popular now, there was a time that it wasn't yet popular, and deployment was a pain. So I think you have it b…
The old joke with Common Lisp used to be if you've developed a program for one version of Common Lisp, you've developed a program for one version of Common Lisp.
Lisp is notoriously hard to deploy. Code is not portable between different lisp implementations. Apple's ATG ended up axing many projects because they had so much trouble moving their lisp from 680x0 to PowerPC.
The fact you talk about "your system's package manager" ignores my point -- I'm not saying Lisp is especially hard to deploy to servers (although it is -- but this is, as you say, a popularity issue; and it would be far worse if the world of servers hadn't converged on a small number of very similar platforms). I'm saying it's hard to deploy to desktops and mobile, which is where most of the "useful" programs people might want to write still live.
A huge part of Lisp's problem is fragmentation. Which Lisp? Aside from fragmentation in Common Lisp itself, there's all the not-quite-Lisps around, ranging from Arc to Scheme to Clojure to sheesh-I-really-have-no-idea. And of course this is because once you start coding in Lisp there's an overwhelming urge to abstract away difficult things in your own clever way, perhaps even hacking the language itself, and pretty soon your little world is utterly unique.
Another great, simple language in the exact same boat is Forth.
Re: Learn Lisp the Hard Way
#134Earlier quoted context omitted.
I worked through SICP years ago and used scheme as my primary language for a couple of years. I write in an ML dialect at my day job. 1. lisp got a lot of stuff wrong; there's really no reason not to use scheme. 2. lisp syntax is more something to overcome than something to become "enlightened" about. Language syntax no longer has to be motivated by ease of parsing. 3. Dynamic typing only gets so enlightening. At the…
The Lisp language syntax is not motivated by 'ease of parsing'. It is motivated by the 'code as data' idea, which enables a lot of useful source transformations to be implemented AND used in a relatively easy way. One of the applications of that are macros. Scheme got a lot wrong from a practical perspective. Use Lisp instead. Type theories are over-hyped. 99.99% of all software is written in languages without advanc…
Lisp's macros don't even get variable binding right. Treatment of bound variables was one of the explicit purposes for the development of lambda calculus in the first place. Imho if you get something as fundamental as this wrong, you don't get to play.
But Im not going to get into a language war.
Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users are somewhat over-the-top in their significance-to-hype ratio.
Re: Learn Lisp the Hard Way
#135Earlier quoted context omitted.
I'm not the above poster but I think the power of macros is way overhyped and not nearly as strong as people claim. I see the claim of "you can write a macro to do it" for any imaginable feature all the time , but it is simply not true. A recent example from personal use is continuations. Scheme has them as a first-class object. Common Lisp does not, but a common claim is that you can write macros to provide continua…
> I see the claim of "you can write a macro to do it" for any imaginable feature all the time, but it is simply not true. Which is not surprising. Actually nobody with a clue makes such a claim. Still, Lisp macros have a wide variety of very useful applications. > Yes, your language is extendable, but your extensions are limited to computation and source-to-source transformation at compile time. Still quite useful. F…
You'll note that I never said it was not useful, but rather it was not this powerful magic sauce that can do anything.
> Which is not surprising. Actually nobody with a clue makes such a claim.
Most Lisp books make this claim.
Re: Learn Lisp the Hard Way
#136Earlier quoted context omitted.
I like Land of Lisp, and I own the ebook+paperback, but I don't think that it's well suited to beginning programmers. I think the "let's make a game" approach actually works better for programmers who are coming from a different language and trying to understand concept translations, rather than novel concepts themselves. edit : I can't reply to you, but re-read what I said. I am making the point that I believe Land…
Uh, the land of lisp has the let's make a game approach as well. I'm not sure I understand what aspect you're talking about.
I'm not sure why my comment was downvoted, but having read and gone through over half of the Land of Lisp personally, I can factually state that it does indeed have multiple game exercises involved.
To quote from the book page:
Along the way you’ll create (and play) games like Wizard
Adventure, a text adventure with a whiskey-soaked twist,
and Grand Theft Wumpus, the most violent version of Hunt
the Wumpus the world has ever seen.
If someone would like to argue that it does not have a "game approach", I would like to see the specific reasoning as to why.
Re: Learn Lisp the Hard Way
#137Earlier quoted context omitted.
> I see the claim of "you can write a macro to do it" for any imaginable feature all the time, but it is simply not true. Which is not surprising. Actually nobody with a clue makes such a claim. Still, Lisp macros have a wide variety of very useful applications. > Yes, your language is extendable, but your extensions are limited to computation and source-to-source transformation at compile time. Still quite useful. F…
You'll note that I never said it was not useful, but rather it was not this powerful magic sauce that can do anything. > Which is not surprising. Actually nobody with a clue makes such a claim. Most Lisp books make this claim.
> Most Lisp books make this claim.
For sure not.
Re: Learn Lisp the Hard Way
#138Earlier quoted context omitted.
The Lisp language syntax is not motivated by 'ease of parsing'. It is motivated by the 'code as data' idea, which enables a lot of useful source transformations to be implemented AND used in a relatively easy way. One of the applications of that are macros. Scheme got a lot wrong from a practical perspective. Use Lisp instead. Type theories are over-hyped. 99.99% of all software is written in languages without advanc…
Lisp's macros don't even get variable binding right. Treatment of bound variables was one of the explicit purposes for the development of lambda calculus in the first place. Imho if you get something as fundamental as this wrong, you don't get to play. But Im not going to get into a language war. Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users a…
Given that macros 'don't get variable binding right', they are still amazingly useful.
> Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users are somewhat over-the-top in their significance-to-hype ratio.
Many of the powerful ideas in software development are available in Lisp.
Re: Learn Lisp the Hard Way
#139Earlier quoted context omitted.
Lisp's macros don't even get variable binding right. Treatment of bound variables was one of the explicit purposes for the development of lambda calculus in the first place. Imho if you get something as fundamental as this wrong, you don't get to play. But Im not going to get into a language war. Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users a…
Given that macros 'don't get variable binding right', they are still amazingly useful. > Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users are somewhat over-the-top in their significance-to-hype ratio. Many of the powerful ideas in software development are available in Lisp.
I mean, a really solid understanding of substitution is probably one of the major contributions of lambda calculus. For what's effectively an implementation to get that wrong is pretty pathological. And also, there's no reason to defend it. It's a bug. Period. Yet here we are.
And there's a whole hell of a lot more in the world than software development...
To the extent that lisp captures any of these other foundational ideas/theories/techniques, type theory does better (which is what I was pre-empting with my original reference, not the role of type systems in the world of practical software development).
Re: Learn Lisp the Hard Way
#140Earlier quoted context omitted.
Given that macros 'don't get variable binding right', they are still amazingly useful. > Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users are somewhat over-the-top in their significance-to-hype ratio. Many of the powerful ideas in software development are available in Lisp.
I mean, a really solid understanding of substitution is probably one of the major contributions of lambda calculus. For what's effectively an implementation to get that wrong is pretty pathological. And also, there's no reason to defend it. It's a bug. Period. Yet here we are. And there's a whole hell of a lot more in the world than software development... To the extent that lisp captures any of these other foundatio…
> Stepping back to the original point, there are other significantly important/powerful ideas in the world, and lisp users are somewhat over-the-top in their significance-to-hype ratio.
Lisp is not a version of lambda calculus. It's a programming language. Macro programming in Lisp works fine in many cases.
> type theory does better ... not the role of type systems in the world of practical software development).
Lisp is about practical software development.