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

21–30 of 41 posts

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

#21

Post by thirsteh »

SamReidHughes wrote: post #13
thirsteh wrote: post #12

Nice article, but I really didn't like the ending. It seemed a lot like Republican "everything the government does is wrong and costs taxpayer dollars" propaganda.

Nice comment, but I really didn't like the presumption. It seemed a lot like the internet commentator "let's discard the actual content of the article and niggle around about our misinterpretation of an irrelevant tidbit" archetype.

I would have ignored it if it was an irrelevant tidbit, but it wasn't. It seemed to be quite a major point in the article.

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

#22

Post by carussell »

nimrody wrote: post #6
sambeau wrote: post #5

"we're confusing best practice with standard practice" This nails my dislike of the phrase 'best practice'. It never means 'the best way to do it' and always means 'the way everyone else does it' or worse 'the way the person writing the phrase has just thought of doing it'.

Sometimes, when the difference between "best way" and "standard way of doing things" is not so great -- it is better to go with standard practice. Reduces time to learn for others, and avoids surprises when interacting with other systems (POLA).

And sometimes, that's fine. But call it what it is.

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

#23

Post by rhizome »

sambeau wrote: post #5

"we're confusing best practice with standard practice" This nails my dislike of the phrase 'best practice'. It never means 'the best way to do it' and always means 'the way everyone else does it' or worse 'the way the person writing the phrase has just thought of doing it'.

This nails my dislike of the phrase "never means." It never means that "it doesn't ever mean" and always means "nobody ever told me what it can mean" or worse "i've never looked for any other meanings."

"Best Practice" is a term of art within business and technology. It's a synonym for "conventional wisdom," and/or "common sense," which, as the man once said, is not necessarily common. That doesn't render it meaningless, though. Best Practices are not information handed down from God, so as best practices hold, it should not be relied upon as perfect.

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

#24

Post by rhizome »

tom_b wrote: post #19

From the article: "The management world has tried to develop software engineering processes that allow people to be plugged into them like interchangeable components. To my mind, the hallmark of the interchangeable component model of software engineers is Java." I hate that attitude in management. I've been surprised to find that at higher levels (think C-level) of management leaders who completely don't think of eng…

Management by metaphor, I'd say that's a red flag.

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

#25

Post by kenjackson »

chris_j wrote: post #10
Zakharov wrote: post #7

As someone who's never used Lisp before, what's the difference between Lisp and Haskell? I keep hearing old stories about the virtues of Lisp, but it doesn't seem like anyone uses it anymore. Has it just been replaced by newer functional languages?

The main difference between Lisp and other languages (including Haskell) is that Lisp is homoiconic. That is, a Lisp program is represented as a list, a data structure that can itself be manipulated by a Lisp program. This means that a Lisp program can contain macros that can generate Lisp code at compile time (or even at runtime). This might sound dangerous, especially if you have seen C macros or C++ templates bein…

That is, a Lisp program is represented as a list, a data structure that can itself be manipulated by a Lisp program. This means that a Lisp program can contain macros that can generate Lisp code at compile time (or even at runtime).

The latter (about Lisp macros) is actually orthogonal to it be homoiconic. What it does mean is that parsing, manipulating, and generating Lisp code is just like generating any other Lisp data structure. But there is nothing stopping non homoiconic languages from adding first-class macros (macros that are written in the language itself).

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

#26

Post by sigil »

"Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem."

I would love to see a transcript of this debugging session.

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

#27

Post by Zak »

Maro wrote: post #14

I think the article lacks a lot of meat. It talks about what the author used Lisp for, but it doesn't really dicsuss why he thinks Lisp should be used, or why others thought it should not be used. For example, "Someone (I don't know who) interrupted him [the software integration engineer] and asked if he could change only one thing to make things better what would it be. His answer was: get rid of Lisp. That one even…

The advantages of Lisp are fairly well-known among its users. Assuming that Lispers are the intended audience, it requires no explanation. It would be helpful to discuss for a broader audience though.

I think the market forces argument is overstated with languages like Lisp, Haskell and ML that have very devoted users. I believe, but cannot prove that hiring for a Lisp job in an area with a large programmer population would be at least as easy as hiring for a Java job. The mere fact of being a Lisp job would tend to attract the Lispers; there would be applicants. Certainly, they would be fewer than for a Java job, but that's not a bad thing; the hiring process often involves spending a massive amount of time weeding out people who are too inept to even consider. There are very few Lispers who are too inept to consider for most Lisp programming jobs.

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

#28

Post by genera »

nimrody wrote: post #6
sambeau wrote: post #5

"we're confusing best practice with standard practice" This nails my dislike of the phrase 'best practice'. It never means 'the best way to do it' and always means 'the way everyone else does it' or worse 'the way the person writing the phrase has just thought of doing it'.

Sometimes, when the difference between "best way" and "standard way of doing things" is not so great -- it is better to go with standard practice. Reduces time to learn for others, and avoids surprises when interacting with other systems (POLA).

"Sometimes, when the difference between "best way" and "standard way of doing things" is not so great -- it is better to go with standard practice. "

...and thus XML is born.

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

#30

Post by Zak »

kenjackson wrote: post #25
chris_j wrote: post #10

Earlier quoted context omitted.

The main difference between Lisp and other languages (including Haskell) is that Lisp is homoiconic. That is, a Lisp program is represented as a list, a data structure that can itself be manipulated by a Lisp program. This means that a Lisp program can contain macros that can generate Lisp code at compile time (or even at runtime). This might sound dangerous, especially if you have seen C macros or C++ templates bein…

That is, a Lisp program is represented as a list, a data structure that can itself be manipulated by a Lisp program. This means that a Lisp program can contain macros that can generate Lisp code at compile time (or even at runtime). The latter (about Lisp macros) is actually orthogonal to it be homoiconic. What it does mean is that parsing, manipulating, and generating Lisp code is just like generating any other Lisp…

But there is nothing stopping non homoiconic languages from adding first-class macros

This is true, and Nemerle is an example of a language with this feature. That said, it's harder to write macros in non-homoiconic languages. One can write Lisp macros by starting with the desired output and inserting quote and unquote where appropriate. Generating a syntax tree in other languages requires mentally translating them to something like Lisp.

Post reply on HN