[HN Gopher] The rise and fall of Lisp at the Jet Propulsion Lab ...
___________________________________________________________________
The rise and fall of Lisp at the Jet Propulsion Lab (2002)
Author : todsacerdoti
Score : 140 points
Date : 2023-01-25 21:41 UTC (1 days ago)
(HTM) web link (flownet.com)
(TXT) w3m dump (flownet.com)
| dagss wrote:
| I used to be a fan of programmer productivity and having the best
| tools to express ideas in. In our case, this is not about LISP,
| but about being able to write 40 lines of SQL in half an hour to
| solve things that other people reach for 1000 lines of backend
| language to do. But also trying hard to identify opportunities to
| simplify and delete code instead of adding another layer of
| complexity on top every time something doesn't add up.
|
| But I've started to wonder. In some ways I feel "our" area in the
| company has been a victim of our own success: By doing things in
| smart/efficient ways, the tasks we've done has become seen as
| simple, we didn't need to recruit as much, and eventually because
| of the low number of people occupied on the task in the
| organization it is seen as easier or less important and we are
| more vulnerable to churn than larger teams.
|
| I've seen simpler problems getting solved in (what I think is)
| very inefficient ways and I used to scoff at that. But now I
| think what they gain is a large robust team, which can handle
| both churn and have more weight politically in the organization.
| Solving something inefficiently simply offers a way to have more
| people do the same task, for redundancy.
|
| In a sense, once an organization hits a certain size it seems
| that efficiency in a programming language is an anti-feature. You
| WANT a larger set of programmers to be happily working on
| something just to have a larger team around the code and
| redundancy in people. If a programming language / environment
| allows you to be too efficient, then too few people get the job
| done and you become vulnerable.
|
| At least, that's the best explanation I have at what's really
| going on in the industry.
| taeric wrote:
| This sounds like the standard "but are they busy?" concern
| hitting. Folks claim they want folks that are working "smarter"
| and not "harder." Completely ignoring that that is, itself,
| hard.
|
| I agree with your general concern. I hate it when, not only do
| I know that I am in fact lazy, but that is not why I have done
| less in this case. I genuinely believe the smaller solution is
| far far preferable. All too often "don't do it" is by far the
| better option for what so much internal tooling does.
|
| To that end, I push back against you wanting a less efficient
| language. I think efficiency is itself a trap. Redundancy and
| general pacing is a good thing. Languages that try and forego
| that are not doing themselves any favors.
|
| But, and this is fully to your point, if you don't have the
| spots in your organization that are fully tolerant to mistakes
| and bad ideas, than you don't have room in your organization to
| grow. And if you don't have room to grow as an organization,
| than you probably don't have room to grow the software, either.
| AceJohnny2 wrote:
| I believe the original author posts around here, @lispm IIRC?
| aidenn0 wrote:
| lisper I believe, not lispm
| nequo wrote:
| 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/
| mepian wrote:
| He is also here on HN:
| https://news.ycombinator.com/user?id=lisper
| sillysaurusx wrote:
| Oh wow, I didn't know lisper worked at JPL. Neat!
| jmclnx wrote:
| > industry best practice
|
| To me that really means "industry best practice at commercial
| businesses". Moving to a different language because the new one
| is cool is a big wast of $
| travisgriggs wrote:
| > 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 <fill_in_the_blank> world has tried to develop _management_
| processes that allow people to be plugged into them like
| interchangeable components."
|
| Why has management never come under the scrutiny of "one size
| fits all" and the subsequent salary/headcount reduction?
| LarryMullins wrote:
| Are you familiar with the concept of co-ops? A lot of
| businesses are run by their workers or their members/consumers.
| They can hire or fire people to work as management as they see
| fit.
|
| It's not very unlike the board of investors of a business
| hiring or firing management, except instead of a board of
| investors you have co-op members.
| Retric wrote:
| 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.
| toss1 wrote:
| Yup
|
| Except that it is only local or small risk minimization; the
| catastrophic existential risks end up maximized to the point
| of becoming inevitable.
|
| With companies, the MBAs happily optimize away anything that
| isn't immediate revenue. So manufacturing gets offshored,
| along with all the deep knowledge of how to make things. R&D
| gets shrunk and minimized because it is a quarterly expense
| with returns not immediately specified. They kill or sell off
| all the "dogs" of products and try to milk the "cash cows".
| This makes the numbers look great until things change and the
| "cash cows" need updating for a new market environment. But
| the company now has no idea how to do it because they have no
| seasoned and up to date product development, no R&D
| technology development, and no manufacturing know-how. So, it
| goes into a death spiral if it hasn't already been disrupted.
|
| On the societal level, MBAs justified the western world
| outsourcing all the manufacturing because it was "fungible"
| and cheaper to do it offshore, made more profits this
| quarter. Meanwhile, all that know-how was stolen by China,
| who isn't interested in quarterly profits, but in global
| hegemony, and now has both economic and strategic chokeholds
| on the western democracies (everything from corners on
| lithium and solar panel markets, to spies in western
| corporations, to backdoors in key commercial and likely
| military microchips). The entire strategic advantage of the
| west was sold out for a few dozen quarters of increased
| profits. This will go down as a colossal strategic blunder of
| historic proportions.
|
| All thanks to trying to standardize management.
| didericis wrote:
| Same. The question I've been finding more and more interesting
| over the years is "how do you tell when you have an
| interchangeable component/what are the implicit dependencies
| holding things together".
|
| You run into an abstracted version of that in software all the
| time, but it's _way_ more ubiquitous that just a software or
| business problem. There's always a limit to interchangeability
| /some kind of assumed context. That rabbit hole is _incredibly_
| deep. I don't think I've ever run into anything comparable. If
| you pull on that thread long enough you end up in deep esoteric
| discussions about perception and philosophy and the history of
| categories /evolution. And whether or not all of that rabbit
| hole I ended up in is an unrelated tangent or not requires
| dealing with the same exact problem (which is whether or not
| the boundaries you've placed around something are
| legitimate/fit your definition, or if they belong somewhere
| else/you're missing very important hidden context).
| ep103 wrote:
| Because capitalism incentivizes maximizing capital flow to the
| owner of the organization. Making labor interchangeable and
| delivering a minimally viable end product are both ways of
| minimizing capital that could otherwise be made to flow to the
| owner of the organization.
|
| If you want to create a management style that optimizes for
| quality of product or optimizes for management styles that
| reflect the needs of labor, instead of a process that optimizes
| for minimizing labor, then you need to change the
| incentivization plan accordingly.
| abadger9 wrote:
| 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.
| ibrault wrote:
| 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.
| marmetio wrote:
| High-assurance isn't really the culprit. It's more of a
| funding issue. If long NASA programs could save part of the
| first year's budget to use the second year, things would go a
| lot faster.
|
| You might get hired into an overstaffed team and not do that
| much for a year until it's crunch time and then you're
| underfunded so it takes an extra year. Arguably you spent
| three years to achieve one year's worth of accomplishments.
| ghaff wrote:
| 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.
| dang wrote:
| Updated last year (edit: or not?), so I've left the date off this
| one.
|
| Previously:
|
| _Lisping at JPL (2020)_ -
| https://news.ycombinator.com/item?id=28113434 - Aug 2021 (9
| comments)
|
| _Lisping at JPL (2002)_ -
| https://news.ycombinator.com/item?id=22087419 - Jan 2020 (307
| comments)
|
| _Lisping at JPL (2002)_ -
| https://news.ycombinator.com/item?id=13626074 - Feb 2017 (37
| comments)
|
| _Lisping at JPL (2002)_ -
| https://news.ycombinator.com/item?id=7989328 - July 2014 (19
| comments)
|
| _The rise and fall of Lisp at the Jet Propulsion Lab (2002)_ -
| https://news.ycombinator.com/item?id=2212211 - Feb 2011 (36
| comments)
|
| _The Rise and Fall of Lisp at the Jet Propulsion Lab._ -
| https://news.ycombinator.com/item?id=304736 - Sept 2008 (72
| comments)
| comfypotato wrote:
| 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".
| aidenn0 wrote:
| 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.
| serf wrote:
| >Phillips screws suck.
|
| I felt this way through my entire engineering life until I
| bought a sailboat.
|
| Everything on marine stuff tends to be flat-head or similar
| design -- engaging a flat driver into a slot in a
| bumpy/roll-y ocean is _hell_. The self-centering engagement
| aspect of a cross-socket style drive is absolutely fantastic
| after a long day of trying to tighten flat-slot fastened
| tube-clamps and the like at sea during calm conditions, let
| alone during weather.
|
| That said -- yes, phillips head sucks, they round out and
| won't handle any decent amount of torque over repeated
| sessions without deformation. Robertson (square)/allen/torx
| _kind of_ suck at sea, because they lack any form of self-
| centering without using special taper drivers.
|
| In a perfect world I think that I would like to use pozi-driv
| fasteners and drivers everywhere, but the reality is that
| there are so many types of specialty hardware in use in the
| marine-world that it would be difficult -- if not impossible
| -- to switch it all entirely over.
| robocat wrote:
| > flat-slot fastened tube-clamps
|
| I am unsure exactly what you are referencing with "tube-
| clamps". If you mean hoop-clamps or hose-clamps, then those
| usually have "self-cantering" hexagonal heads as well as
| the slot: https://duckduckgo.com/?q=stainless+steel+hose+cl
| amp&iar=ima...
|
| But I can definitely think of places with slot-heads on
| deck of the yachts I have been on, which would be a bitch
| in swell. And stripping a thread would also suck!
| aidenn0 wrote:
| Yes, they are better than flathead screws, which are the
| second (or maybe third after a combination
| philips/flathead[1]) most common screw I encounter in daily
| use.
|
| 1: Which I just learned last month they make special
| screwdrivers for! https://www.amazon.com/Combo-
| Driver-4-Inch-Klein-Tools/dp/B0...
| the_af wrote:
| 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 software developed on a tight schedule and swapping
| programmers in/out of the project simply wouldn't work, so many
| considerations for choosing (say) Java were out of the
| question.
| michael1999 wrote:
| 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.
| the_af wrote:
| > _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.
| myth2018 wrote:
| I've read this article some years ago and always wanted to ask:
| besides size, what were the arguments against Lisp in JPL?
| Author's position is biased, as he recognizes, then I'm curious
| about the other side in this story.
| jcranmer wrote:
| One of the footnotes mentions that multilanguage integration
| was causing some headaches, and (the author's bias showing
| through) that is blamed by the author on the IPC server being
| crashy because it was C, not Lisp.
| mepian wrote:
| This is blogspam, the original is still hosted here by the author
| himself: https://flownet.com/gat/jpl-lisp.html
| dang wrote:
| Ok, so the update from Aug 2022 is not by Ron? geez.
|
| Changed from https://mecrisp-stellaris-
| folkdoc.sourceforge.io/lisp.html now. Thanks!
| [deleted]
___________________________________________________________________
(page generated 2023-01-26 23:00 UTC)