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

391–400 of 433 posts

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

#391

Post by [deleted] »

dancek wrote: post #361
d3ckard wrote: post #274

Earlier quoted context omitted.

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…

[deleted]

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

#392

Post by d3ckard »

dancek wrote: post #361
d3ckard wrote: post #274

Earlier quoted context omitted.

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…

Well, you're right, I misused the term a bit. I used 'leaky', because it well describes that abstraction cannot hide implementation details(and in the second example those implementation details are used to achieve new functionality). However, it is because of the user abusing abstraction, not because abstraction is inherently leaky in that regard(and that is the reason the term was coined).

I definitely need a new word for situations like this.

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

#393

Post by vgy7ujm »

surprisetalk wrote: post #366
6ak74rfy wrote: post #288

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 larg…

Perl fits into C-Like, Pure Fun and Code-Golfy in addition to Stringy.

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

#394

Post by tech2 »

dhimes wrote: post #153
bpicolo wrote: post #138

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?

For me it was "How to learn more" with a fair bit of "how to work with others" and a lot of the theory.

The how to learn bit is (and has been, for the last 20 years for me) massively helpful. It's rare that I think back to a particular thing I learned about (it still happens though), but I cherish knowing how to move from one subject to another when trying to work out how I should solve something and where I should look next.

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

#395

Post by dhimes »

AnimalMuppet wrote: post #324
dhimes wrote: post #235

Earlier quoted context omitted.

Thank you for your thorough reply. Colleges are under fire, even from their own ranks, by people whom I believe confuse training with education , but it's clear that's not your issue. It sounds to me like there needs to be some sort of deep-dive "onboarding" program where new hires can work on a curriculum of projects and learn the SOPs of the organization. Colleges could take some of it on, of course (testability an…

It seems to me that, out of ten graduates from a CS program, only one is going to go on to do academic computer science; the other nine are going to become computer programmers. CS programs are doing a poor job of preparing those nine. Now, in other areas, we have a distinction. We have physics departments that teach people theory, and we have separate engineering departments that prepare people for careers putting t…

So, you're suggesting that computer engineering be separated from computer science, with CS being in the Math department. And you would expect CS to be a relatively small major.

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

#396

Post by JustSomeNobody »

d3ckard wrote: 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…

The 10% of developers you mention are the ones who don't cargo cult program. They don't seek "Neo" architectures. They are the ones who knuckle down and solve actual, real problems, not some fantasy generalized version of it. They are the ones who code and hone their craft. They don't spend any time arguing over React vs VueJs, Rust vs C++, etc.

I think the average developer can do this too if they'd just get out of the programming echo chambers and trust their gut.

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

#397

Post by lispm »

sedachv wrote: post #367
oblio wrote: post #187

Earlier quoted context omitted.

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://com…

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

Both are seen slightly controversial by some. On Lisp for example indicates that PG actually wanted to program in a different language - and eventually did: Arc.

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

#398

Post by mikelevins »

mikelevins wrote: post #320
auganov wrote: post #256

Earlier quoted context omitted.

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 progr…

Sorry to reply to myself, but when I awoke this morning, it occurred to me that above I am describing my daily-driver programming environment from early 1988, Coral Common Lisp (except that who-calls wasn't built in; it was a contrib).

Besides the previously-mentioned features, I could build a windowing UI by dragging pieces together. I could build the resulting native-code app for delivery by choosing "Save" from a menu. I could write WDEFs (the code resources that defined window shape and behavior) and other low-level stuff interactively in Lisp. I could patch arbitrary calls with assembly code written and debugged interactively in the Lisp environment (one of the SK8 authors was previously an assembly-language video-game programmer; he was ecstatic about this feature of CCL).

Comparing my current daily-driver development machine to the one on which I was using Coral Common Lisp in 1988, the new machine has twice the word size, 400 times the clock speed, 16,000 times as much RAM, and 400,000 times as much disk space.

Meanwhile, the development tools are in many ways worse, rather than better.

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

#399

Post by jcadam »

StavrosK wrote: post #371
mercer wrote: post #252

Earlier quoted context omitted.

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.

Exactly like OOP!

Though, I'll point out that my problem is not necessarily with OOP, but OOD. OOP can be quite useful in some situations, such as modeling and simulation :)

Of course the design of the Java language is predicated around the idea that OOD is the one true way to design large software systems and thus must be forced by the language itself, and that is the primary reason I hate it.

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

#400

Post by RivieraKid »

vzcx wrote: post #364
RivieraKid wrote: post #332

Earlier quoted context omitted.

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?

Hard to tell, not an expert, not a beginner. Enough to conclude that other languages are more productive for me.
Post reply on HN