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

The rise and fall of Lisp at the Jet Propulsion Lab (2002)

flownet.com

Post reply on HN
Print view View original

11–20 of 153 posts

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#11

Post by Retric »

travisgriggs wrote: post #9

> The management world has tried to develop software engineering processes that allow people to be plugged into them like interchangeable components. I've wondered about this a lot lately. It's not limited to software engineering only, you see it in other creative/human domains as well. Media production. Teaching. So on. But it's made me wonder, why doesn't the equation ever invert: "The world has tried to develop _m…

The basic premise of MBA programs is arguably to create interchangeable managers.

One size fits all is less efficient at both the managerial and employee levels, the advantage is largely risk minimization.

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#13

Post by sillysaurusx »

mepian wrote: post #8
nequo wrote: post #3

The author is Ron Garret. He was also interviewed last year on the CoRecursive podcast about the merits of Lisp at JPL, and the opposition to it. It’s worth listening to: https://www.corecursive.com/lisp-in-space-with-ron-garret/

He is also here on HN: https://news.ycombinator.com/user?id=lisper

Oh wow, I didn’t know lisper worked at JPL. Neat!

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#14

Post by michael1999 »

the_af wrote: post #7
comfypotato wrote: post #6

I’m intrigued by the distinction between best practice and standard practice. Isn’t it standard because it’s the best? I can understand that non-standard practices might be best in niche situations, but this sounds like a discussion of “traditions are solutions to problems so old we’ve forgotten what they were”.

My read is that a standard industry practice (e.g. considering programmers interchangeable pieces and that components should be designed with that in mind) will work in many situations, and therefore the "standard" is reasonable for most of them, but the best practice is context-sensitive; in this case, the context didn't require C++/Java and they were actually not good choices. This was specialized, mission-critical…

There is not such thing as a best practice without specifying a context. The kind of build hygiene required for long-lived commercial product is very different from disposable marketing content. This is especially toxic when the underlying context and goals are so different.

Businesses wants interchangeable programmers for many reasons: so they can ramp team size up and down, so hiring is easy, etc. But the number one reason in my experience is to minimize the bargaining power of the programmers. Execs absolutely _hate_ having star programmers holding them up for raises. Building complicated in-house tooling in a language like lisp might make it rain, but the devs are then in a position to demand a slice. Procurement 101 is always have secondary vendors to keep your main vendors honest. Lower productivity is an acceptable price to avoid being held up.

This is a very different context from somewhere like JPL where any programmer there could already leave for more money in industry. Anyone there is already committed to the mission. The cost of lower productivity isn't justified, and might make certain activities simply impossible given the current budgets.

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#15

Post by ghaff »

abadger9 wrote: post #10

My mentor worked at JPL - he was a BS, MS, PhD from MIT - he got out of there so quick (i believe less than 2 years). He said the pace of work was so slow, he didn't feel like anything got done in his entire time there.

It's pretty inherent in those types of projects. How long do big aerospace projects take? (And then they may be canceled when some other bidder wins the deal.)

Big hardware development has probably accelerated some overall--the development of new chip architectures and "big iron" computer systems was at least multiple years when I was a product manager, but especially safety critical systems or things you get one shot at still take slow deliberate process.

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#17

Post by ibrault »

abadger9 wrote: post #10

My mentor worked at JPL - he was a BS, MS, PhD from MIT - he got out of there so quick (i believe less than 2 years). He said the pace of work was so slow, he didn't feel like anything got done in his entire time there.

Depends on what you're working on and on if you're defining "getting stuff done" on a macro or micro scale. For large flagship missions, 2 years is nothing. The scale of work and level of verification required by these projects is massive and takes time. You've only got one shot to get things right with billions of dollars on the line, don't rush it.

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#18

Post by the_af »

michael1999 wrote: post #14
the_af wrote: post #7

Earlier quoted context omitted.

My read is that a standard industry practice (e.g. considering programmers interchangeable pieces and that components should be designed with that in mind) will work in many situations, and therefore the "standard" is reasonable for most of them, but the best practice is context-sensitive; in this case, the context didn't require C++/Java and they were actually not good choices. This was specialized, mission-critical…

There is not such thing as a best practice without specifying a context. The kind of build hygiene required for long-lived commercial product is very different from disposable marketing content. This is especially toxic when the underlying context and goals are so different. Businesses wants interchangeable programmers for many reasons: so they can ramp team size up and down, so hiring is easy, etc. But the number on…

> There is not such thing as a best practice without specifying a context.

Just to be clear: we are in agreement, right? The author of TFA is stating this, and that the JPL misunderstood its own context. It wasn't the kind of business/project where your second paragraph applies, and so the practices they adopted were mistmatched.

Re: The rise and fall of Lisp at the Jet Propulsion Lab (2002)

#19

Post by aidenn0 »

comfypotato wrote: post #6

I’m intrigued by the distinction between best practice and standard practice. Isn’t it standard because it’s the best? I can understand that non-standard practices might be best in niche situations, but this sounds like a discussion of “traditions are solutions to problems so old we’ve forgotten what they were”.

Phillips head screws are pretty standard in the US, but pretty much any other non-slot screw head is technically superior (including at least two other plus shaped drivers I'm aware of).

Most woodworkers I've known prefer a square shaped driver. Unless the costs of the screw significantly impact your margins, Phillips screws suck.

Post reply on HN