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

241–250 of 433 posts

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

#241

Post by wglb »

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

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

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

#242

Post by contingencies »

neo2006 wrote: post #146

The biggest issue we are facing as a profession is abstractions. Most of us are good at abstracting things because this is the way we cope with complexity. But the moment we need to face that abstraction and need to understand what is hiding behind it we can reach some limit. A very common example I noticed with Java developers who use frameworks like spring, they use spring tooling to cope with code complexity and a…

I have struggled with complexity my entire career. One of our key approaches for managing complexity is to 'walk away' and start fresh. Often new tools or languages force us to start from scratch which means that developers end up conflating the benefits of the tool with the benefits of the clean start. The clean start is what is fundamental. The simplest way of controlling complexity growth is to build a smaller system with fewer developers. - Terry Crowley

An informed perspective: https://www.quora.com/Programming-is-all-about-managing-comp...

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

#243

Post by brightball »

watwut wrote: post #16

> knowing Lisp made me all too keenly aware of Java's shortcomings, and I had a very hard time not being angry at how stupid it was that I was being forced to use it. I would take this as a the thing to remember from this. When you are too angry at something, you cant learn it. I have seen the emotional refusal to learn new inferior thing (or read comments that amounted to the same) many times already. It is somethin…

You can experience something similar to this with just about anything that provides you with elegant solutions to problems you see.

I experience a similar thing Elixir at times. Even as a fervent "right tool for the job" guy it's hard to have in one hand something that elegantly solves just about everything you've experienced in your career...and not be able to use it.

Between Elixir and Python, there's not much of a need for anything else on a server these days.

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

#244

Post by pjc50 »

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?

In general, undergraduate assignments:

- are well specified and known to be completable

- start from a blank slate

- produce relatively short programs

- once complete and accepted, will never be run or looked at again

- are required to work individually

Whereas in a real software engineering department:

- goals will be to some extent vague and fluid, may be contradictory => requiring negotiation skills with PM, customers etc.

- you will nearly always be adding to an existing project => requiring ability to read code and perform archaeology

- programs end up huge => requiring schemes for better organisation, modularisation etc

- have a long life and a maintenance overhead => requires design for adaptability

- are required to collaborate => requiring use of a VCS, not having complete freedom to choose tools, techniques like CI and branching for managing incomplete vs complete work fragments.

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

#245

Post by rkangel »

YeGoblynQueenne wrote: post #169
quintin wrote: post #8

Earlier quoted context omitted.

Non-English speaker. What does "smug" mean?

It means "smartass".

Not quite. "Smartass" generally implies you go around showing off your (perceived) knowledge. "Smug" implies you sit quietly in a corner feeling good about your (perceived) knowledge.

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

#246

Post by osrec »

pjc50 wrote: post #69
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…

Maintaining a distinction between "actual software development" and "plumbing" is elitist, even if you're placing yourself on the downside of that comparison and setting yourself up for imposter syndrome. You can get an awful lot done by "plumbing". Entire businesses like SAP are built on it. It can also be mission critical; in SpaceX, is the literal plumbing of hydraulic fluid and fuel flow unimportant? No.

I think you have misunderstood OPs remarks. The way I see it, the distinction is between the innovators and the regurgitators. Very few people can innovate well when writing software. Others rely on the work of existing innovators to piece together their solutions. Both have their place, but one takes more practice to attain a high level of proficiency. Not elitist - just observing reality.

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

#247

Post by groby_b »

d3ckard wrote: post #95
pjc50 wrote: post #69

Earlier quoted context omitted.

Maintaining a distinction between "actual software development" and "plumbing" is elitist, even if you're placing yourself on the downside of that comparison and setting yourself up for imposter syndrome. You can get an awful lot done by "plumbing". Entire businesses like SAP are built on it. It can also be mission critical; in SpaceX, is the literal plumbing of hydraulic fluid and fuel flow unimportant? No.

I'm not trying to impose that one is more "noble" than the other. As you said yourself, businesses usually run on plumbing. I'm trying to understand the industry, as it appears to be(at least to me) different than what I thought was true. I believe it to be important if we're going to do better and there is a ton of metrics showing we should do better(percent of projects failing, percent on projects exceeding budget…

Death marches are caused by the people who project the image that they understand software development better than others. Spaghetti code is caused by them as well, they just pretend it's so brilliant you can't understand it. (After their departure, the RDF usually fades)

We don't need a cult of brilliance. What we do need is an atmosphere of humility. Modern software/hardware systems are of breathtaking complexity. It turns out that's simply hard for humans to hold in their minds as a whole, but we still develop software like we actually could.

For a while, we had a glimpse on what a simpler world could look like. (The early days of the web - when everything was GET/PUT/POST). We promptly proceeded to layer complexity on top of that.

And that's OK, because it gave us a lot more power. But we pay a price for that power. And every time we attribute that price to lack of brilliant people, we mostly show that we haven't even come close to understanding what it even is that makes projects succeed.

The genius myth is just magical thinking in disguise.

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

#248

Post by pjc50 »

matte_black wrote: post #188
pjc50 wrote: post #69

Earlier quoted context omitted.

Maintaining a distinction between "actual software development" and "plumbing" is elitist, even if you're placing yourself on the downside of that comparison and setting yourself up for imposter syndrome. You can get an awful lot done by "plumbing". Entire businesses like SAP are built on it. It can also be mission critical; in SpaceX, is the literal plumbing of hydraulic fluid and fuel flow unimportant? No.

In general plumbing is considered the “blue collar work”. No one would put a boot camp front-end JavaScript grunt in the same league as an MS or PHD guy doing artificial intelligence research, compiler assembly, or reverse engineering malware. And it seems ridiculous at times to even throw around the title of “Software Engineer” when the field has no standards of certification or regulation like other engineers. The…

Interesting that you put those three together; while cutting edge AI research might require that level of academic background, I wouldn't say that compiler work does. It's more within the reach of an undergraduate degree course. And malware (for and against) is a completely different field altogether, full of people with unconventional backgrounds and a large chunk of poachers-turned-gamekeepers.

I think it will be a long time before the field slows down enough that standardising it will be viable.

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

#249

Post by soundwave106 »

d3ckard wrote: post #95
pjc50 wrote: post #69

Earlier quoted context omitted.

Maintaining a distinction between "actual software development" and "plumbing" is elitist, even if you're placing yourself on the downside of that comparison and setting yourself up for imposter syndrome. You can get an awful lot done by "plumbing". Entire businesses like SAP are built on it. It can also be mission critical; in SpaceX, is the literal plumbing of hydraulic fluid and fuel flow unimportant? No.

I'm not trying to impose that one is more "noble" than the other. As you said yourself, businesses usually run on plumbing. I'm trying to understand the industry, as it appears to be(at least to me) different than what I thought was true. I believe it to be important if we're going to do better and there is a ton of metrics showing we should do better(percent of projects failing, percent on projects exceeding budget…

For many programming jobs, the ultimate goal is not the code, but solving a business problem. So to me it's fine to just "piggy-back on libraries" if the library doesn't get in the way, doesn't lead to poor performing code, and saves time.

Even as a business programmer, I agree that I do think it's a good idea to occasionally step into some places that are a little more low level. Yet from what I've seen (playing around with embedded systems and VSTs and the like), the actual coding process is, more or less, more similar than different. Both in process ("the basics" of Javascript translate to some degree to "the basics" of C), and even at the "lower level", libraries are also used quite frequently. For instance, JUCE is a package pretty frequently used for developing VSTs (VSTs itself are an SDK). These packages save time and allow developers to focus on the meat of the audio plugin, the DSP algorithms.

At a certain level, what happens is that you get into the realm of math / engineering problems. And there definitely is mindset and focus differences between engineers and business -- one that's good at one is not necessarily good at the other. I just don't think the coding aspect of that separation is as stark as you make it out.

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

#250

Post by bpicolo »

dhimes wrote: post #235
bpicolo wrote: post #163

Earlier quoted context omitted.

I imagine this varies, but for me most of college was very much about the pure bits of computer science - how things tick, so to speak. But very little of your day to day at most enterprises is about writing new versions of data structures, or academic-level operating systems/database work (obviously there are some roles in the industry where this is the task, but it's not the majority). That's not to say learning it…

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 would be interesting to see a course than spanned multiple years building upon the same project with the same team, emphasizing different aspects year-by-year, but I imagine that would be pretty nightmarish on the scheduling front.
Post reply on HN