Live data from Hacker News

How knowing Lisp destroyed my programming career (2006)

coding.derkeiler.com

361–370 of 433 posts

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

#361
post #196

Earlier quoted context omitted.

Sorry to interject, but I'm curious: as someone who is in their first semester of a CS education, could you elaborate on what you mean by abstraction? So far, I just know it to mean making your function more widely applicable. I'm assuming there's a better definition I'm missing?

Nope, that's pretty much it. It just have very far reaching consequences. To illustrate, let's use a simple example. Let's assume you need a logging feature in your application and your language/framework doesn't provide one(pretty much impossible nowadays). The simplest solution is to just append to a hard-coded file. It solves the imminent problem. It's also very bad solution unless you will never write log again.…

This is not what I understand a leaking (or more commonly 'leaky') abstraction to mean.

Instead, assume the previously mentioned Logger does internally write to a file. Now, when the disk becomes full, Logger throws an exception and the caller must do something about it. The abstraction of just writing anything to log is broken and the underlying complexity leaks through.

This example also demonstrates the difficulty of keeping abstractions from leaking. You can't exactly make the code automatically free up disk space or sign up to a remote logging service when disk space runs out.

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

#362

Earlier quoted context omitted.

> Maintaining a distinction between "actual software development" and "plumbing" is elitist I don't think it is. Someone that is slapping together libraries from npm, but has no idea how to debug with gdb or use strace / ktrace / dtrace etc to diagnose problems with the resulting system, or does not have the skills to fix bugs or add new features to the "plumbing" - that person is not an actual software developer. Th…

I think this is going into the wrong direction. In my world "plumbing" means realizing ways to do things. When you want to write a simple web app that shows a Hello and has a contact form: even in 2018 that's still a reasonable amount of work. It's really not a lot of code but every line needs to be chosen wisely. That's what I call "plumbing". Most people new to Software Development become desperate at such tasks an…

> I'm not sure if you must be able to use strace to be productive

You will be productive until whatever runtime/library you are using has a serious bug or performance issue. Then you either use tools like strace or your productivity drops to 0. It is not a matter of marginal or order-of-magnitude productivity differences. You don't "understand stuff" for sentimental reasons, you "understand stuff" because the alternative is your manager has to call in people like me that "understand stuff" and pay them tens of thousands of dollars to fix things that you can't.

> It always puzzled me how people can be comfortable using this kind of stuff.

It's called learning.

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

#363
post #47

Honestly curious why Lisp has so much admiration and praise on HN. I played around with Scheme some long time ago, read SICP, learned a lot. And I know Lisp inspired many programmers like the founder of Ruby. But I would not think of Lisp when it comes to solving day to day problems. I rather pick Python because it helps me solve all kinds of problems. There are many more solutions I can think of (Ruby, Node, Go, eve…

That depends heavily on what your day to day problems are.

If you work in a complex or rapidly evolving domain, I cannot think of a better choice than Lisp. If you are doing a lot of text processing or writing CRUD apps, then you will probably not get much benefit.

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

#364
post #47

Honestly curious why Lisp has so much admiration and praise on HN. I played around with Scheme some long time ago, read SICP, learned a lot. And I know Lisp inspired many programmers like the founder of Ruby. But I would not think of Lisp when it comes to solving day to day problems. I rather pick Python because it helps me solve all kinds of problems. There are many more solutions I can think of (Ruby, Node, Go, eve…

I've been programming for 10+ years, tried many different languages and just don't get the appeal of Lisp. Swift for example is simply more productive and fun to use in most use cases. Same with Haskell. I don't believe PG's claim that Lisp made a significant difference in productivity for them.

How well do you know lisp?

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

#365

Earlier quoted context omitted.

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.

>So you pick a LISP language you're severely limiting your hire pool. I'd rather have 5 very good Lisp programmers than 50 code monkeys.

I might even prefer 5 average lisp programmers to 50 code monkeys.

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

#366

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…

I like to think of each programming language as a separate musical instrument.

If Java is a tuba, then maybe Python is a trumpet. They're two very different instruments, but they share a lot of the same underlying intuitions. In fact, I would say that C-style languages are probably equivalent to the collection of brass instruments. There are major variations from trombones to trumpets to french-horns, but not as large as you'd think.

So if you've only played tuba, what happens when somebody hands you a violin? You may understand "music theory" (or computer science) pretty well, but actually sitting down to learn the violin will give you strange insights that aren't apparent on brass instruments. For instance, violins' strings are tuned perfect-fifths apart -- certain scale patterns naturally jump out at you. In the same way, let's compare Haskell/Idris/R to stringed-instruments. It's easy to switch between them when you realize that a viola is a cello is an upside-down bass-guitar. And at a higher level, learning violin and tuba together will make you better at BOTH instruments! As a bonus, playing music is more fun when you can antipate the habits and difficulties of your peers' instruments.

As a side-note, I think Lisp is either a piano or a theremin. I'm not sure why.

Anyway, I think learning each "family" of languages is a worthy aim for every engineer. Here are the groups that I personally hope to master over my lifetime:

  - Hard         : Assembly
  - C-Like       : C, Java, Python, JS, PHP, etc.
  - Pure Fun     : Haskell, Idris, OCaml, Elm, etc.
  - Distributed  : Erlang, Elixir
  - OO           : Smalltalk
  - Lispy        : Scheme, CL, Clojure
  - Stringy      : BASH, Perl, SNOBOL
  - Code-Golfy   : APL, J, K, AntLang
  - Stacky       : Forth, Joy
  - Data-Driven  : R, Mathematica, Wolfram Language
  - Logic-Driven : Prolog
This list is long, but don't let it discourage you! Every family has plenty of magical ideas that make the next one easier to master.

Best of luck on your journey!

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

#367
post #187

Earlier quoted context omitted.

*how many languages would have given you [the luxury of programming effectively] for twenty years? C++ doesn't qualify, to my mind, because the language has had many iterations and also because, as the post's author points out, writing C++ in the early 90s was not always a pleasant experience. Python and even Perl are good contenders, as they have both been relatively stable languages. I'm not sure Java counts - Java…

I know that Lisp has been largely stable, but are you sure it hasn't changed much? Programming paradigms advance, we didn't even have unit tests or continuous integration 20 years ago (at least not widely adopted in the industry). I find it hard to believe that even a Lisp programmer would be completely "static" across 20 years, i.e. the code written 20 years ago would be truly similar to the code he writes now. So I…

I think there was a big change in Common Lisp style in the late 2000s coming from Free Software, particularly concerning how macros and read macros were used. Edi Weitz's coding style had a big influence, and Tobias Rittweiler's named-readtables[1] was a paradigm shift. I think of Paul Graham's On Lisp[2] as the first wave of modern Lisp style, and Doug Hoyte's Let Over Lambda[3] as the second wave.

[1] https://common-lisp.net/project/named-readtables/ [2] http://www.paulgraham.com/onlisp.html [3] https://letoverlambda.com/

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

#368
post #133

Earlier quoted context omitted.

Sounds like you coded in Scheme, not Lisp. ( https://news.ycombinator.com/item?id=16584082 ) Common Lisp was designed for the messy real world, it's a workhorse, even at the cost of 'prettiness' that Scheme fans like to point out as a benefit for Scheme. So it's been used (either directly or to output a lower level machine code) for all sorts of real world things like OSes (see the Lisp Machines), video games, CAD sy…

Yeah, I remember very little about it except a _lot_ of parentheses. Interesting to hear it is a lot more "real world" than I thought - seems my understanding is flawed... but equally interesting that I was unaware of it, having never once encountered it in my entire career.

The average engineer has some dozen things they encountered in their career, and everything else is something that they haven't encountered once.

Off the top of my head, I've never encountered such tools as: Visual Basic, PowerShell, VHDL, and IBM 370 assembly language.

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

#369

Earlier quoted context omitted.

Good list. I'd add macros and the conditions mechanism for error handling. The latter still has no analogue in other languages.

> The latter [the conditions mechanism for error handling] still has no analogue in other languages. Could you explain this for a non-Lisp person? (I have some understanding of macros already.)

The CL condition system separates the signaling of a condition (of which errors are a subtype), the handling of a condition, and the definition of recovery strategies (restarts).

Instead of unwinding the stack when a condition is signaled, handler code is invoked in the dynamic context of the signal and thus has much more information available to decide how to recover.

If a decision on how to recover can't be made programmatically, the system kicks out to the user where they are presented with the choices you have given them.

See: http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h... for more.

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

#370
post #363
post #47

Honestly curious why Lisp has so much admiration and praise on HN. I played around with Scheme some long time ago, read SICP, learned a lot. And I know Lisp inspired many programmers like the founder of Ruby. But I would not think of Lisp when it comes to solving day to day problems. I rather pick Python because it helps me solve all kinds of problems. There are many more solutions I can think of (Ruby, Node, Go, eve…

That depends heavily on what your day to day problems are. If you work in a complex or rapidly evolving domain, I cannot think of a better choice than Lisp. If you are doing a lot of text processing or writing CRUD apps, then you will probably not get much benefit.

>If you work in a complex or rapidly evolving domain,

or if you are creating a big system that needs to work reliably and be able to be corrected (patched) while it's operating

Post reply on HN