Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp is sin

blogs.msdn.com

Post reply on HN
Print view View original

11–20 of 60 posts

Re: Lisp is sin

#11

Post by KirinDave »

TallGuyShort wrote: post #6

>> one of the driving forces was to let non-geeks build software He makes the extremely important point that the technology has failed if ordinary people can't use it to get their own work done. However, I've personally seen a project where the aim was essentially to let non-programmers program, and the result was horrendously messy. In large part, I think that's because a lot of people ended up developing that had n…

Shouldn't we ask ourselves if this goal is reasonable? Making arbitrary software is at the limits of our capacity right now, even if people devote their lives to it as a profession, passion, and an art.

It's one thing to take an approach like Apple Automator (a much beloved automation environment), but it's another entirely to say, "General Purpose Software should be within the grasp of the 'average person.'" It's not clear that the goal is even reasonable! A lot of software, to do what it does, requires the use of complex mathematics, algorithms, and cryptography that frequently even the implementors only vaguely understand. Manipulating those in an abstract and correct fashion is difficult in the extreme (e.g., the morass of timing attacks that have plagued modern implementations of cryptographic protocols). We can barely make software with smart people!

Re: Lisp is sin

#12

Post by jrockway »

KirinDave wrote: post #11
TallGuyShort wrote: post #6

>> one of the driving forces was to let non-geeks build software He makes the extremely important point that the technology has failed if ordinary people can't use it to get their own work done. However, I've personally seen a project where the aim was essentially to let non-programmers program, and the result was horrendously messy. In large part, I think that's because a lot of people ended up developing that had n…

Shouldn't we ask ourselves if this goal is reasonable? Making arbitrary software is at the limits of our capacity right now, even if people devote their lives to it as a profession, passion, and an art. It's one thing to take an approach like Apple Automator (a much beloved automation environment), but it's another entirely to say, "General Purpose Software should be within the grasp of the 'average person.'" It's no…

Making arbitrary software is at the limits of our capacity right now, even if people devote their lives to it as a profession, passion, and an art.

Yeah, you are exactly right. Programming languages need to be designed for the very best programmers -- they are the ones that need the productivity boost. For me, not understanding the language is never a problem. Making something "easier to understand" will not help me write software that goes together faster or ends up more reliable. It often has the opposite effect; Java's lack of ... everything, for the sake of simplicity, really slows me down. Comparatively, learning a new concept is much easier. If I start using a library that uses Arrows, I read the Arrow paper, spend a few days playing with it, and then I have one more tool that will help me be more productive every day for the rest of my life. Making a language that doesn't have arrows saves me reading a paper about them, but it wastes my time every day for the rest of my life.

So, "simple" programming languages -- do not want. I am not saying that you should start your "intro to computer programming" class with a long lecture about category theory, but I am saying that you should never hide things from people that want to know about them.

Re: Lisp is sin

#13

Post by erikb85 »

Hm. If Lisp would be an "everybodys" language, what would be the Lisp then? Actually, the main success of lisp comes from its purity its scientific deepness. If you try to follow another goal, you just lose vision for your actual one. If somebody really needs an "everybodys" language, for example because he is a lawyer or something else, okay. There is Python, Javascript, Java and many other languages who try in different ways to be for everybody. And all of them are important. As is Lisp, how it is.

Re: Lisp is sin

#14

Post by itgoon »

KirinDave wrote: post #11
TallGuyShort wrote: post #6

>> one of the driving forces was to let non-geeks build software He makes the extremely important point that the technology has failed if ordinary people can't use it to get their own work done. However, I've personally seen a project where the aim was essentially to let non-programmers program, and the result was horrendously messy. In large part, I think that's because a lot of people ended up developing that had n…

Shouldn't we ask ourselves if this goal is reasonable? Making arbitrary software is at the limits of our capacity right now, even if people devote their lives to it as a profession, passion, and an art. It's one thing to take an approach like Apple Automator (a much beloved automation environment), but it's another entirely to say, "General Purpose Software should be within the grasp of the 'average person.'" It's no…

Horse hockey.

While I know that there are a lot of horror stories (and I can tell a few), some of the most productive "programmers" I've ever met used MS Access or Excel.

If you don't consider advanced usage of these applications as a form of programming, then you are illustrating the point: It is not only possible to "dumb down" programming, it is inevitable. So much so that you haven't even noticed it happening.

Re: Lisp is sin

#15

Post by tnovelli »

He rambles a lot, but he's right about the need for a new Lisp, and refers to the ILC'05 presentations by Dussud, Baker, and McCarthy on "Re-inventing Lisp". Those are some pretty radical proposals. (Summaries: http://www.findinglisp.com/blog/2005/06/ilc-2005-wednesday-r...).

I think the trouble with Lisp (and Scheme) is that there's so much cruft and inconsistency beneath the veneer of simplicity (see http://tnovelli.blogspot.com/2009/08/lisp-crisis.html). Lisp is a great language to study; I just wish it was more practical and popular. It sucks having to choose between awkward (Lisp) and inflexible (everything else). :-(

Re: Lisp is sin

#16

Post by steveklabnik »

jrockway wrote: post #12
KirinDave wrote: post #11

Earlier quoted context omitted.

Shouldn't we ask ourselves if this goal is reasonable? Making arbitrary software is at the limits of our capacity right now, even if people devote their lives to it as a profession, passion, and an art. It's one thing to take an approach like Apple Automator (a much beloved automation environment), but it's another entirely to say, "General Purpose Software should be within the grasp of the 'average person.'" It's no…

Making arbitrary software is at the limits of our capacity right now, even if people devote their lives to it as a profession, passion, and an art. Yeah, you are exactly right. Programming languages need to be designed for the very best programmers -- they are the ones that need the productivity boost. For me, not understanding the language is never a problem. Making something "easier to understand" will not help me…

... slightly off topic, but do you have a good resource for learning Arrows? It's on my list of things to do, but I haven't dug around for a good example yet.

Re: Lisp is sin

#17

Post by tnovelli »

itgoon wrote: post #14
KirinDave wrote: post #11

Earlier quoted context omitted.

Shouldn't we ask ourselves if this goal is reasonable? Making arbitrary software is at the limits of our capacity right now, even if people devote their lives to it as a profession, passion, and an art. It's one thing to take an approach like Apple Automator (a much beloved automation environment), but it's another entirely to say, "General Purpose Software should be within the grasp of the 'average person.'" It's no…

Horse hockey. While I know that there are a lot of horror stories (and I can tell a few), some of the most productive "programmers" I've ever met used MS Access or Excel. If you don't consider advanced usage of these applications as a form of programming, then you are illustrating the point: It is not only possible to "dumb down" programming, it is inevitable. So much so that you haven't even noticed it happening.

Heh... I know a guy who thinks he's too dumb to program in anything except Lisp (ALGOL syntax is hard! It's like math! :-)

Re: Lisp is sin

#18

Post by KirinDave »

itgoon wrote: post #14
KirinDave wrote: post #11

Earlier quoted context omitted.

Shouldn't we ask ourselves if this goal is reasonable? Making arbitrary software is at the limits of our capacity right now, even if people devote their lives to it as a profession, passion, and an art. It's one thing to take an approach like Apple Automator (a much beloved automation environment), but it's another entirely to say, "General Purpose Software should be within the grasp of the 'average person.'" It's no…

Horse hockey. While I know that there are a lot of horror stories (and I can tell a few), some of the most productive "programmers" I've ever met used MS Access or Excel. If you don't consider advanced usage of these applications as a form of programming, then you are illustrating the point: It is not only possible to "dumb down" programming, it is inevitable. So much so that you haven't even noticed it happening.

The only conclusion I can draw is that you didn't read my comment, because if you had you wouldn't try to counter my argument by circuitously agreeing with me. I am sure your friend was very productive with Access and Excel, and I'm sure they used advanced cryptographic protocols, solved tricky problems involving communications timing, handled cross-platform compatibility issues, programmed efficient inner rendering loops, etc.

I'm talking about "general purpose software," which encompasses a huge volume of space. Rare is the person who can competently address the wide variety of problems found in the world of software. Excel and Access, in my view, are perfect examples of paring down the acceptable problem space to something reasonable and making tools for people to solve those specific problems naturally. You can't write a 3d engine in excel, but that's okay, because the tool is not for that.

But this argument breaks down when you try to take it to a general-purpose software kit, which has to handle anything and everything. In this wide, unshielded world of hard problems you have to have the most capable and powerful tools available. Deliberately limiting tools in this environment is like saying, "Our river pilots have lots of experience handling barges, so it'd be counter productive to train them on oceangoing vessels, we'll just build bigger, sturdier barges for ocean travel." Yes, sailing on the open ocean requires more powerful and complex tools, but you appreciate those tools when the ocean gets rough.

Re: Lisp is sin

#19

Post by KirinDave »

tnovelli wrote: post #15

He rambles a lot, but he's right about the need for a new Lisp, and refers to the ILC'05 presentations by Dussud, Baker, and McCarthy on "Re-inventing Lisp". Those are some pretty radical proposals. (Summaries: http://www.findinglisp.com/blog/2005/06/ilc-2005-wednesday-r... ). I think the trouble with Lisp (and Scheme) is that there's so much cruft and inconsistency beneath the veneer of simplicity (see http://tnovel…

Your resources are pretty old, the "crisis" of car/cadr is just not there with modern, updated lisp implementations like PLT Scheme.

PLT Scheme is competitive in every way with Python and Ruby, I don't know why people keep ignoring it.

Re: Lisp is sin

#20

Post by jrockway »

steveklabnik wrote: post #16
jrockway wrote: post #12

Earlier quoted context omitted.

Making arbitrary software is at the limits of our capacity right now, even if people devote their lives to it as a profession, passion, and an art. Yeah, you are exactly right. Programming languages need to be designed for the very best programmers -- they are the ones that need the productivity boost. For me, not understanding the language is never a problem. Making something "easier to understand" will not help me…

... slightly off topic, but do you have a good resource for learning Arrows? It's on my list of things to do, but I haven't dug around for a good example yet.

In terms of using "them", the HXT documentation made it pretty clear for me. (I put "them" in quotes because things like Arrows and Monads are really adjectives, not nouns. When used as nouns, people generally understand what you mean, but this confused me for a long time and I try not to confuse other people. Consider it my version of a "Monad tutorial". :)

In terms of theory, I found the "Applicative Programming with Effects" paper and the "Typeclassopedia" very helpful.

http://www.soi.city.ac.uk/~ross/papers/Applicative.html

http://haskell.org/sitewiki/images/8/85/TMR-Issue13.pdf

I started doing a real implementation of these data structures in Perl this week. (I say "real" because people have "added Monads to Perl" before, but they didn't really add Monads, they just added a "programmable semicolon".) Anyway, in doing so, I saw in great detail the relationships between the various types (specifically "liftM2 ($)" and ""), and tried to generalize things as much as possible. The result was something like Arrows, and that helped me understand the "why" in addition to the "how". Writing test cases was also helpful to me; using these esoteric stuctures in "real code" helped me build up the intuition needed to advance farther.

Anyway, it took me three readings of the Applicative Programming with Effects paper to get Applicative Functors, and after that, Arrows were pretty easy. So I recommend that paper, and lots of poking around in ghci.

To bring this back on topic, yeah, it would be hard to teach this stuff to Joe Average. But a language that allows it is still important to develop. (I also learned firsthand that language design decisions to make it difficult to implement certain features. Implementing the equivalent of "instance Monoid b => Monoid (a -> b)" is almost impossible to do cleanly, due to the polymorphism of "mempty"; it's defined in Haskell as "mempty _ = mempty", and in Perl, we discard the type information before we have a chance to pick the "second" mempty.)

Post reply on HN