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

How knowing Lisp destroyed my programming career (2006)

coding.derkeiler.com

Post reply on HN
Print view View original

251–260 of 433 posts

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

#251

Post by kabdib »

timbit42 wrote: post #231
kabdib wrote: post #227

I learned C and LISP pretty much at the same time (back when rocks were young and you needed a PDP-11 if you wanted to run Unix). Then I went to college and the first course in the Computer Science major was a "killer" they taught in Pascal. Okay, so Pascal is a kind of screwed-up C, and I could deal with that. That "killer" course had a semester-long, multi-phase project that was a kind of symbolic calculator (with…

Technically, both Pascal and C are derivatives of Algol. Pascal is a variation on Algol. C is a screwed-up Algol.

Point taken. Though "call by name" still makes me twitch :-)

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

#252

Post by mercer »

oblio wrote: post #199
jcadam wrote: post #186

Earlier quoted context omitted.

I don't know. My industry (defense/aerospace contracting) is still infatuated with Java/C++ and Object-Oriented Design as the universal solution to all problems. It's like being stuck in the 1990s. This is the flip-side to age-discrimination - it's much less of a problem in my industry. Which, as a 37-year-old I find comforting. But when you're stuck working for 50-something pathologically risk-averse architects who…

> I'm basically waiting for the previous generation to die/retire so I can have the chance to build software the way I think it should be built. And by the time you'll be able to do that you'll be the 50-something who keeps using functional programming while the 37-year-olds want to use dilithium crystal programming :p

While you're joking, one thing that appeals to me about my recent dive into functional programming is that it strikes me as knowledge that is 'fundamental' enough that it'll never disappear or become irrelevant.

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

#253

Post by Vektorweg »

I was a C++ fanboy, before I had to deal with Lisp in college. While Lisp itself seemed unusual with all the parentheses, it had a few good ideas I really missed in C++ . That was the point where I looked for languages similar to Lisp and that lead me to what I'm working today with: Haskell.

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

#254

Post by wglb »

garganzol wrote: post #78

I came to Lisp (Scheme/Racket) from that another side (C++, Java, Perl) and it was an enlightening experience. Now I use Lisp nearly everywhere in a form of a small .NET runtime module. Lisp is excellent at templating tasks. Just for comparison: StringTemplate for .NET is a whooping 400 kB of compiled binary code while my implementation of Lisp is just 35 kB (!). Sure enough, Lisp does the very same thing as StringTe…

Ok, this is seriously intriguing.

Are more details about this magic thing available?

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

#255

Post by zeveb »

jstimpfle wrote: post #174
bjoli wrote: post #86

Earlier quoted context omitted.

What made it click for me is the nature of scheme: a few, very well thought out abstractions, that compose well to build a really neat language. I never really made friends with other languages. Where scheme composes the primitives for problem solving, I find that languages like python or ruby provide either one way for each different thing, or a very large hammer for every problem you might find, be it list comprehe…

> a very large hammer for every problem you might find, be it list comprehensions or generators or whatever OO voodoo you can come up with. List comprehensions, to me, are what makes Python a productive (or the most productive) prototyping language. It allows me to think and program in mathematical relations without much fuss. Add to that nice sets and dicts (needed for asymptotic efficiency), and I can easily forgiv…

> I much more need a syntax that does not hide what happens (procedure call, list indexing or at least "indexing").

Each of those is actually hiding what really happens. E.g. for a procedure call the runtime compares the arity of the call and the called function, inserts each argument into a data structure of some sort, perhaps grafts together environments or does other things on a language-specific basis, performs a jump of some sort, then the called function takes over, and finally stashes its return value(s) in a data structure of some sort and performs another jump.

Even list indexing in a language like Python is relatively complex, involving a lookup of the list length, bounds-checking &c.

> Code generation is mostly bad, it typically means the problem wasn't thought through, and that there is a lack of clearly defined building blocks.

Proper syntactic abstraction is all about building the right blocks for the problem at hand. At the end of the day, all we have are bits of silicon transferring electron: everything above that is an abstraction. A sufficiently-powerful programming language enables the programmer to develop the abstractions he needs for the problem he has.

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

#256

Post by auganov »

mikelevins wrote: post #225
falcolas wrote: post #177

Earlier quoted context omitted.

> Why is my editor on my PC not talking to the app running on my Android phone and letting me see its state and make changes in real time? All my opinion, of course: The time (cost) required to create such easily available introspection is too high for the comparatively small gains. REPLs in modern languages (when even implemented) are just so often a completely separate mode of operation.

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 way.

I actually like to use the 'repl' module in nodejs. With a little bit of effort, you can make the dev experience much easier.

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

#257

Post by tigershark »

garganzol wrote: post #78

I came to Lisp (Scheme/Racket) from that another side (C++, Java, Perl) and it was an enlightening experience. Now I use Lisp nearly everywhere in a form of a small .NET runtime module. Lisp is excellent at templating tasks. Just for comparison: StringTemplate for .NET is a whooping 400 kB of compiled binary code while my implementation of Lisp is just 35 kB (!). Sure enough, Lisp does the very same thing as StringTe…

Since when string interpolation is a such mysterious and arcane feature?

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

#258

Post by coding123 »

Unless you truly are a one-man army - one must absolutely be paying attention to the tiobe index. Even if the worst possible language is on top, its the one language that can't "destroy your career". It's 10 times more valuable to be programming the same language in a company than be the one Lisp or D or Erlang guy that writes side programs that no one will help you maintain - and will definitely be re-written in Java when you leave.

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

#260

Post by lispm »

kamaal wrote: post #166
bjoli wrote: post #121

Earlier quoted context omitted.

Well, it was true, at least until clojure. Now we've got clojure, common lisp and scheme.

Lisp user base is so small enough that these categories largely look pointless to people outside. For all practical purposes CL, Scheme, Clojure and Elisp are all lisps.

> For all practical purposes CL, Scheme, Clojure and Elisp are all lisps.

Since only CL and Emacs Lisp can and do share actual Lisp code, I call only them Lisp for practical purposes.

For 'unpractical' purposes - they share no source code but are influenced by practical Lisp - , Logo, Javascript, Ruby, Clojure ... are also Lisp.

Post reply on HN