Live data from Hacker News

How knowing Lisp destroyed my programming career (2006)

coding.derkeiler.com

311–320 of 433 posts

Re: How knowing Lisp destroyed my programming career (2006)

#311

Earlier quoted context omitted.

> Honestly curious why Lisp has so much admiration and praise on HN. Paul Graham and Robert Tappan Morris, two of the founders of YCombinator, love Lisp/Scheme. They got rich by selling their company Viaweb to Yahoo. You guessed it: Viaweb was written in LISP and Paul Graham believes that this was their secret weapon: > http://www.paulgraham.com/avg.html Also the software that drives Hacker News is written in Arc, a…

Which promptly got rewritten after pg left. EDIT: From the years being here, and having played with LISP myself, it's a language that appeals to a certain type of programmer, who claim to find it very productive compared to other languages. And everyone else hates it. So you pick a LISP language you're severely limiting your hire pool.

The whole point of picking Lisp as a language for many people is to have a hiring pool of small but good programmers.

Re: How knowing Lisp destroyed my programming career (2006)

#312

Worked at Google Pre IPO, worked at the Jet Propulsion Lab, became an Angel Investor, acquired Startups, founder and CEO of Spark Innovation Labs.... ....I hope to one day have my career destroyed as badly as this.

Maybe he didn't leave his mark as a programmer/engineer the way HE wanted to, but you definitely have to admire his ability to identify good opportunities. He laments choosing and then using LISP for so long and in a way seems to blame the language for adversely affecting his perspective on programming, but it really seems like it served him well when it was useful. I think the same intuition that helped him choose LISP for solving problems (because it was a nice set of tools at the time) probably ended up helping him choose good professional opportunities, too. If he's frustrated about the way his perspective changed then I have to agree with the other commenters that he would need to work on changing that perspective and not remain complacent.

Re: How knowing Lisp destroyed my programming career (2006)

#313
post #272
post #241

Earlier quoted context omitted.

Peter Norvig, a serious lisper, calls Python "an acceptable lisp": https://news.ycombinator.com/item?id=1803815

If you read that post he actually didn't say that. He moved from Lisp to Pseudocode to Python for his co-written AI Book (AIMA). If you also look at the pseudocode or the python code, it's not very Lispy. Python more or less is used on a level of an object-oriented BASIC.

https://www.quora.com/Where-did-we-go-wrong-Why-didnt-Common...

In the above answer to a question in Quora, he seems to suggest that most of the features in lisp eventually got adopted in most other mainstream languages. Or in other words the concept of 'acceptable lisp'.

I get what you are saying, and I feel the same way. But I think what people try to imply here- If you are using Lisp for a certain set of features, most of them are now available else where.

Re: How knowing Lisp destroyed my programming career (2006)

#314

Earlier quoted context omitted.

I can't tell if that's a typo or commentary on Perl.

Looks like a typo, I think he meant: > When I was writing Pascal I was excited about stuff I could make the computer do, but Perl made me !@ 77 {{} #!@3 = ++ 90 x ( %}[.

That was not a valid example:

    $ perl -c /tmp/test.pl 
    Missing right curly or square bracket at /tmp/test.pl line 1, at end of 
    line
    syntax error at /tmp/test.pl line 1, at EOF
    /tmp/test.pl had compilation errors.
    $ cat /tmp/test.pl
    !@77 {{} #!@3 = ++ 90 x (%}[.

Re: How knowing Lisp destroyed my programming career (2006)

#315
post #40

For a while now I've had a feeling that all the comments about lack of engineers(especially in software) are vastly underestimated. Probably around 10% of us is capable of doing actual software development. The rest writes plumbing and can handle the project for only as long as abstractions available through libraries can hold the complexity. If we assume most of us don't really know what we're doing, that totally ex…

So how does one make sure they're not plumbing?

Re: How knowing Lisp destroyed my programming career (2006)

#316
post #272
post #241

Earlier quoted context omitted.

Peter Norvig, a serious lisper, calls Python "an acceptable lisp": https://news.ycombinator.com/item?id=1803815

If you read that post he actually didn't say that. He moved from Lisp to Pseudocode to Python for his co-written AI Book (AIMA). If you also look at the pseudocode or the python code, it's not very Lispy. Python more or less is used on a level of an object-oriented BASIC.

Sorry, I mis-remembered his position. Thanks for the correction.

Re: How knowing Lisp destroyed my programming career (2006)

#317
post #153

Earlier quoted context omitted.

> only a handful of people is capable of actually developing software project Failures here are almost definitely related to lack of adequate mentorship rather than anything else. College doesn't go half the way to prepare you to be a successful engineer. There are people out there that can be self-motivated to do better, but in almost all those cases they're building skills that do the dirty work but don't feature b…

College doesn't go half the way to prepare you to be a successful engineer. This is something I'm hearing alot at the moment, and not just about engineering. What would you say college taught you?

It's a little trite but the best thing college taught me was how to read critically and teach myself as needed. The second best thing was providing plentiful examples of good pedagogy (I went to a teaching college, not a research U.) which turned into models for how I try to mentor.

others comments about the difference between school work and real work are spot-on.

It's funny how much I hated group projects as an undergrad, but how in some ways they were the best preparation: How do you still get things done when everyone has different ideas, varying levels of competency, available time, and motivation?

Re: How knowing Lisp destroyed my programming career (2006)

#318

On a tangential topic : I am intimidated by how myriad experiences with programming languages HN commentators on this thread have. I have been in this industry for about 8 years and am considered an above average developer in my current company. I have primarily worked with Java, while fiddling with others here and there. No experience with pure functional languages such as Lisp or Haskell. Am I missing out some impo…

Yes, probably. Get some experience with languages that are good at memory layout (C), concurrency (Erlang/Elixir), productivity (Ruby). It's eye opening. You may realize you've been hammering nails with a screwdriver your whole life.

Re: How knowing Lisp destroyed my programming career (2006)

#319
post #40

For a while now I've had a feeling that all the comments about lack of engineers(especially in software) are vastly underestimated. Probably around 10% of us is capable of doing actual software development. The rest writes plumbing and can handle the project for only as long as abstractions available through libraries can hold the complexity. If we assume most of us don't really know what we're doing, that totally ex…

It's easy to differentiate: real software developers use butterflies [0].

[0] https://www.xkcd.com/378/

Re: How knowing Lisp destroyed my programming career (2006)

#320

Earlier quoted context omitted.

The gains from Lisp-like support of live-environment programming are not small, but they are hard to communicate succinctly. The costs are real, but not onerous for a language designed to support such features. But a person designing and implementing programming-language tools has to deliberately choose to provide the needed features because implementing them after the fact raises the costs and lowers the benefits. T…

On a fundamental level, there's not much difference between Lisps and any other language with real runtime eval. It's just that, say, in your average JS project you're going to have a lot of state all over the place, state that depends on side effects. I don't think Lisps do much to solve that. Clojure helps by discouraging state and side-effects, namespaces let you have everything sort of be a global in a manageable…

The great Lisp and Smalltalk systems are designed from the ground up with the assumption that a programmer may at any point inspect and possibly change absolutely anything in the dynamic environment of the running program. Everything is designed to facilitate doing that with the reasonable expectation that the program will continue to work correctly. Such systems are designed for writing software by modifying a program while it runs.

That basic assumption is a giant knife-switch that pervasively affects everything in the language and environment. Consider, for example, the generic functions CHANGE-CLASS and UPDATE-INSTANCE-FOR-CHANGED-CLASS. Those functions are in the Common Lisp language standard. That makes no sense unless the standard assumes that a Common Lisp system can modify a program while it runs.

Only a minority of programmers want such systems, but to be fair, only a minority of programmers have worked with them enough to understand them.

Not everyone prefers that style of programming, but most programmers will probably never have the opportunity to find out whether they prefer it. I did have the opportunity, and I learned that I did prefer it. I still prefer it thirty years later.

Get back to me with a Clojure or JS environment that does what I miss from a great Lisp or Smalltalk environment. Let me trigger an error and walk the call stack to inspect parameters and intermediate results. Give me a keystroke to get a list of every other piece of code that calls the function with the error--don't make me wait more than about a second for the list. Let me interactively edit the values on the stack in the suspended computation or, better yet, change their types (and have them properly reinitialized), then resume the computation. Let me redefine a function that's on the call stack and then restart the call using the new definition. Let me serialize the entire dynamic state of the program to disk, copy it to a colleague's machine, and start it up to show my colleague the same error in the same dynamic environment. Let me do all of that interactively without needing to leave the original break loop triggered by the original error. Oh, and package the tools as a single modest-sized executable that I can run with a simple command line or a double-click, that launches in a couple seconds or less.

I don't know of such a Clojure or JS environment. If you do, I would be grateful to learn of it.

Post reply on HN