NASA Programmer Remembers Debugging Lisp In Deep Space (thenewstack.io) 70
joshuark writes: NASA programmer/scientist, Ron Garret shares his experience debugging LISP code from 150-million miles away on the robotic Mars rover Sojourner. Garret describes his experience in a recent episode of Adam Gordon Bell's Corecursive podcast. Garret later explains, "And it didn't work..." for the next project NASA's New Millennium project using LISP.
Like a professor said in LISP programming class, LISP -- getting it done is half DEFUN. Garret had written an essay in 2006 , titled, "How knowing LISP destroyed my programming career." Available on the web archive. So much for LISPcraft, or the Little LISPer.
Like a professor said in LISP programming class, LISP -- getting it done is half DEFUN. Garret had written an essay in 2006 , titled, "How knowing LISP destroyed my programming career." Available on the web archive. So much for LISPcraft, or the Little LISPer.
cdr/car from afar (Score:2)
Re: (Score:3)
It seems like an extremely niche language. Like there are a few very specific problems that it works well for, but everything else is a challenge hack akin to seeing what we can get Doom to run on.
I would hope NASA had a very good reason for using it. I vaguely recall it being a nightmare to debug even small lisp programs.
Re:cdr/car from afar (Score:4, Insightful)
It seems like an extremely niche language. Like there are a few very specific problems that it works well for, but everything else is a challenge hack akin to seeing what we can get Doom to run on.
I would hope NASA had a very good reason for using it.
Don't know about production uses, but it's very good for research. I did a *lot* of LISP programming in college in the '80s and as an undergraduate research assistant on this NASA grant/project Analysis and synthesis of abstract data types through generalization from examples [nasa.gov].
I vaguely recall it being a nightmare to debug even small lisp programs.
It's an elegant language and easy to read once your brain adapts. Using the interpreter's pretty-printer to auto-format/indent your code helps finding errors. Once auto-formatted, I could usually spot the extra/missing parenthesis with a quick look-see.
Re: (Score:2)
It's an elegant language and easy to read once your brain adapts. Using the interpreter's pretty-printer to auto-format/indent your code helps finding errors. Once auto-formatted, I could usually spot the extra/missing parenthesis with a quick look-see.
But then you might as well use a more explicit syntax and get done with it. I mean all functions/expressions/math can be reduced to either prefixed notation (MyFunc(SomeArgs)), postfixed (4!) or infixed (1+1). Lisp only uses the first one and that makes it very hard to read for some things (Add(1,1)). If you abuse C++ overloading you can do most things infixed but then that hides what is actually going on. A balance needs to be reached and Lisp ain't it.
Re: (Score:3)
On the other hand ... The simplicity of LISP's syntax makes it easy to write programs that (re)write other programs in LISP and build code from data and data from code, etc... Sometimes it's not all about the programmer.
Re: (Score:2)
Re: (Score:2)
No, that is not the first rule of computer programming.
Exactly the opposite is. Self modifying code is one of the first things invented and (was) often used to jux bugs in running systems.
You would find a place where you can smuggle in a jump. Copy the code at the jump to the jump destination, side load, e.g. via a monitor, the fix/extension behind that code, and add jump back to the opcode behind the first jump.
Usually that would be done by a small helper program, triggered by an interrupt. And after insta
Re: (Score:2)
Re: (Score:3)
I worked on/help design a moderately large medical claims clearinghouse that used LISP in a lot of places. The back plane was a J2EE Java app, but all of the customer-specific filters and routing logic was done in a flavor of Scheme that ran in the JVM called Monk.
Re: (Score:2)
That characterisation, "very good for ivory towers" and "an elegant language and easy to read once you rewire your brain to deal with it" sounds like every other language that academics have fallen in love with over the years (*cough*Haskell*cough*). I guess they do have one useful role, if academics love it then you know (a) you'll never have to know it outside academentia and (b) on the remote chance that you ever see a job advertised with it, RLF.
You can actually tell at which point someone was at Uni
Re: (Score:3)
One of those niches that work out very well is as an AutoCAD scripting language. AutoCAD tried to get users to switch to Visual Basic, but most users stuck to AutoLISP, which is a superset of a subset of common LISP. Now AutoDesk is pushing Revit over AutoCAD, and I don't think Revit even has any scripting language for users, AFAIK you have to make compiled add-ins and jump through hoops to get permissions right (at least most office environments).
Re: (Score:2)
In the early 90's I helped a co-worker debug some AutoLISP import/export routines that he was writing
He had written long routines as single lines, and I ended up breaking them out with each command on a separate line and the parenthesis indented to show how they matched up
Often, it just came down to adding or removing a parenthesis from the end of the line, but just jumping to that solution would often introduce unexpected errors
It taught me a lot about indenting and readability, which I continue to use in
Re: (Score:2)
I loved using AutoLISP. It's where I cut my teeth. Not that I'm a great programmer by any means or would even refer to myself as a programmer. But I learned a lot that I've applied in other areas, all while helping my co-workers be more productive with AutoCAD in our usage. It was really nice when they finally created Visual LISP IDE. Made dealing with formatting of the code way easier among other things.
Re:cdr/car from afar (Score:5, Insightful)
It seems like an extremely niche language. Like there are a few very specific problems that it works well for, but everything else is a challenge hack akin to seeing what we can get Doom to run on.
The phrase, "seems like," implies no direct experience, and, by extension, a gap in knowledge that would be good to fill through study. I recommend Abelson and Sussman's, "Structure and Interpretation of Computer Languages". You can even download a free PDF from MIT.
Many fundamental ideas in Computer Science come from the development of Lisp and its derivatives. Ever used a map, reduce, sort, etc. function on a list? Those were invented for Lisp. The idea of a conditional? Lisp. All of the ultra-efficient list manipulation algorithms? Invented for Lisp. Tail recursion? Lisp. First class functions? Lisp. Serialization? Lisp (*). Anonymous functions? Lisp. Recursion? Lisp. First class environments? Lisp. Closures? Lisp. Incremental / JIT compilation? Lisp. Proper garbage collection? Lisp. Association lists? Lisp. Dynamic typing? Lisp. Data-driven specialization? Lisp. Keep your Python, Rust, Go, or whatever flavor of the month. Lisp (well, Scheme) remains my favorite language, ever.
And among the amazing things about the language, you can write a complete Lisp interpreter in a few KB of machine language. That's *kilo*bytes, not megabytes or even gigabytes. That's a high-level language in almost no storage. A version was recently written that fits in a few *hundred* bytes of machine code, including a GC, although that requires an additional 40 lines of limited Lisp to then implement a full Lisp. Still, the beauty of Lisp, its elegance, has not been surpassed.
(*) The idea of serialization wasn't actually pursued as a specific goal, it's just that Lisp was the first language where there was no distinction between code and data, and thus, *anything* could be, and was, stored in a file. Lisp Machine were also the first to implement what has later become commonly known as deep hibernation (i.e., save machine state to disk), though a feature that, oddly, has not been fully replicated elsewhere as far as I know: you could bring your machine to whatever state you wanted, starting programs, opening windows, etc., and then save that state out to bootable storage called a "band" so that machine initialization to a known state was nearly instantaneous at the next power-on.
Re: (Score:3)
Re: (Score:2)
It's more of a "this is my opinion". I try to avoid stating my opinions as facts. There's a lot of that going around.
Lisp was one of the many courses I took in college as I basically took at least one course on every language they offered. (though I've never used lisp professionally)
Re: (Score:3)
Re: (Score:2)
"It seems like an extremely niche language."
If software for gizmos on different planets ain't a niche, I don't know what is.
Re:cdr/car from afar (Score:4, Interesting)
Lisp fans say one eventually learns how to read Lisp quickly, but I'm still not convinced. The biggest problem is it lacks visual cues: you have to interpret words to know what a set of code does. Punctuation is generally quicker to visually process, at least for my eyes. It's a visual cue instead of a linguistic cue such that the brain processes it earlier in its "stack". We know that "{...}" means a block of code, "(...)" means a parameter list, "[...]" an array index, "=" is assignment, etc.
I've been floating a language syntax called "Moth" that potentially offers the meta power of Lisp but the visual cues of the C family (JavaScript, C#, etc.). It's an attempt to have a C-like language syntax convention using simple primitives such that one doesn't need to reinvent an interpreter/compiler for each dialect. It's influenced by XML's goals: a uniform syntax for a variety of domains and programming styles.
Re:cdr/car from afar (Score:5, Funny)
Lisp fans say one eventually learns how to read Lisp quickly, but I'm still not convinced.
When I took computer science, the joke about Lisp was that it was a language that's so simple you can learn it in an afternoon... unless you already know a different language, in which case it would take six months.
Re: (Score:2)
That's a joke we now make about Lua...
Re:cdr/car from afar (Score:4, Insightful)
Lisp fans say one eventually learns how to read Lisp quickly, but I'm still not convinced. The biggest problem is it lacks visual cues: you have to interpret words to know what a set of code does. Punctuation is generally quicker to visually process, at least for my eyes.
As I noted above, I did a *lot* of LISP programming in college and on a NASA grant/project in the '80s. LISP is easy to read once your brain adapts. The visual cues can be obtained by using the interpreter's pretty-printer to auto-format/indent the code as it would interpret it. Intention problems indicate either a missing or extra parenthesis. Once auto-indented, I could usually find the problem easily.
Re: (Score:2)
Plus pretty much the majority of languages are viewed through the lens of an IDE which can bring visibility to one's code.
Re: (Score:2)
> The biggest problem is it lacks visual cues: ...
Indeed! That is the biggest obstacle with Lisp -- an "endless" run of parenthesis just becomes noise.
There have been various proposals over the years such as David Wheeler's Readable Lisp S-expressions Project [sourceforge.io] that describe [dwheeler.com] the problem and a solution but no idea if that ever went anywhere.
One of the nice things with C/C++'s braces is that you have many different indentation styles [wikipedia.org] for indentation. Allman style makes for very nice consistent readability w
Re: (Score:1)
> UGH. XML is a bloated markup. Not really a good standard to base on.
For clarity, Moth does *not* use XML. Moth borrows the *idea* of a relatively simple base syntax for a variety of domains and sub-languages. Borrowing an idea is not the same as borrowing syntax.
(To XML's credit, it works reasonable well for a good many things and is relatively easy to read. Often JSON is too cryptic.)
As far as which language has the best syntax, I have my personal preference, but I realize the market keeps voting for
Cue all the people can't functional program (Score:3)
There's a reason telecoms and other must-fail-gracefully projects use functional programming languages. No use explaining it. Commence ragging on lisp.
Re: (Score:1)
I won't disagree there are niches where it shines. But that's not the same as shining everywhere.
Re: (Score:2)
Lisp forces you to figure out a way to organize your code, and gives you the flexibility to do so.
That's why so many great languages have come from former Lisp programmers: they are just formalizing their Lisp organization strategy in a language. (The Rust guys would have been better off spending more time in Lisp).
Re: (Score:1)
For team programming, conventions and standard matter a lot. Without someone ensuring standards, the power of Lisp can also be its downfall. We all think different and like idioms shaped like our heads. However, our favorite style may confuse others and thus it either needs vetting, or a language that reigns in too much variation.
That being said, I believe a Moth dialect can potentially be almost as powerful, meta-wise, as Lisp, but still have many of the C-like symbol visual cues that I believe speed up re
Re: (Score:2)
Yeah. The proper way to use Lisp is to use it until you want to write your own programming language. Then you have acquired its knowledge.
Re: (Score:1)
Re: (Score:2)
Lots of Insignificant Stupid Parentheses (LISP). I remember it well.
Noting that all parentheses are significant in LISP ... :-)
Once you really get LISP you actually love it. (Score:4, Interesting)
I hated learning LISP, Compared to Procedural and then Object Oriented languages, going to a Functional Language felt extremely foreign and didn't make too much sense as I was used to a simple top down approach. However while I hated learning LISP, after the design principals clicked in my head, and I could think functionally vs trying to translate procedural to functional. I learned it is an extremely powerful way of approaching programming as you tend to work more on the problem, then the syntax.
Re:Once you really get LISP you actually love it. (Score:4, Insightful)
IME functional programming is simply polymorphism by value rather than by type as in OO languages. It makes some things simpler but its hardly the great step forward that its proponents make out.
Re: (Score:2)
Functional programming is more than that, notably that it discourages side effects and implicit state.
Re: (Score:2)
Re: (Score:2)
Re: Once you really get LISP you actually love it. (Score:2)
Any program that does any kind of I/O has side effects, you cant avoid them. If the coder doesnt have to deal with them then the interpreter/compiler does, with necessarily hard coded assumptions that may not always be correct.
Re: Once you really get LISP you actually love it (Score:3)
Every program also has an instruction pointer, but it's rarely directly exposed in programming languages. It's just a side effect of executing code.
Same principle here. The side effects get pushed into well-managed state transformations. The bulk of the code has no side effects and gains all the testability/provability benefits of not having side effects.
Re: (Score:2)
You mistake side effects for state changes. In functional programming you avoid the first, which are prone to errors, and encapsulate the second, in the same way that you encapsulate local state in object-oriented programming so that it's not all over the place. But you can have as much state handling as you want.
This model brings the benefit of referential transparency (your variables are never unexpectedly changed by a subprocess), and most business use cases can be programmed with the same efficiency as
Re: (Score:2)
I take it most of your software work is UI?
I don't work in academia and I'm not (currently) a researcher, but most of my CPU time is spent on number crunching or serialization/deserialization. Apart from the IO feeding the latter (and, usually not IO-limited), once the numbers I need are in memory almost all my operations could be made pure. In actuality my stuff tends to be a hybrid of imperative and functional as is most suitable, but I favor pure where possible because it makes testing and reuse easier.
A
Re: (Score:2)
I take it most of your software work is UI?
Partly. I do command/control and data acquisition. So the chain is usually: embedded microcontroller or Linux program, communication via USB or TCP, reception on client machine, storage and dispatching of data, representation of status and current data in UI. I've been trying to move away from C for a long time... but it still does the job !
Re: (Score:2)
That's fair. If I were doing what you describe, I suspect I'd lean much more towards an imperative style. Certainly the times I've interacted with the embedded world, it's been almost exclusively in C, and I can't imagine doing that in a language like Haskell.
Re: (Score:1)
I believe there's a bigger "scoping principle" that encompasses both functional and OOP, where each is just a specific "instance" of scoping arrangements. (Or at least they can be viewed that way.) However, making scoping flexible (user defined) currently makes for inefficient compilers/interpreters (C/I). But if only certain scoping patterns are commonly used in practice, then maybe the C/I can be optimized for those by making them the defaults or cached internally. Thus, scoping can be open ended without
Re: Once you really get LISP you actually love it. (Score:2)
Those intermediate states should appear as arguments in a functional stack trace.
Re: (Score:1)
Such seems cluttered to me as it's lost in all the other arguments and stack layers. Maybe with a really good debugger and/or lots of debugging practice it's smoother, but a fancy debugger etc. can improve other language usage also.
Re: (Score:2)
"as you tend to work more on the problem, then the syntax", and then the closing parentheses. ;-)
Sorry not bashing your insightful post, and yes I realize the extra phrase is redundant. I felt similarly when learning it back in 91-92. Since then I've wondered if LISP would be more popular today if we'd had the code editors we have available today to automate the more painful aspects of the syntax. Or perhaps if different flavors of the language had come out that had more palatable syntax but identical princ
Re:Once you really get LISP you actually love it. (Score:4, Insightful)
I've wondered if LISP would be more popular today if we'd had the code editors we have available today to automate the more painful aspects of the syntax.
Not sure how parentheses are painful, but I worked on a NASA grant/project in the '80s with a Xerox 1108 (Dandelion) running InterLISP-D and it was pretty awesome. The entire environment was written in LISP and using the interpreter's pretty-printer to auto-format/indent your code and being able to run things directly from the editor made the experience pretty seamless. Most (all?) LISP interpreters have a pretty printer to to format the code as it would be interpreted and, once done, it's pretty easy to spot errors based on the indent that would indicate a missing/extra parenthesis.
Re: (Score:3)
Scheme for example.
Re: (Score:2)
The parentheses issue was annoying, before fancy IDE's however if you got a handle of the language, you would use whitespace to your advantage to make the code manageable.
It is still a case where Parentheses are a problem when you are thinking in Procedure Based coding like Basic, Pasical, FORTRAN, or C at the time, and just trying to code your LISP to be a 1 for 1 conversion.
Re: (Score:2)
It is worth noting that the original creators of LISP expected it to be the basis for an actual language and not something that anyone would actually use as-is.
Re: (Score:2)
Three stages maybe: 1. Lisp is hard. 2. Lisp is great, I'm just entering the parse tree in manually!. 3. Lisp is OK, as long as the problem is best expressed in terms of the call-graph, and you don't abuse it.
I think the leap from 1 to 2 can be so difficult that a lot of people want to bask in their achievement and not see the flaws; but some do move on in various ways.
Re: (Score:2)
These are your father's parentheses (Score:4, Funny)
Re: (Score:2)
Interesting stuff (Score:1)
I also learned Lisp in the early 80's when I was a kid.
Naive people latch on to things just because it's new to them and they think it's the best thing ever then they end up going down lots of dead ends. That is stupid and wasteful. You need to test in the real world with an objective attitude. Lisp, Java, OCaml, Scala, Haskel, and yes, Go, Rust, Python. All dead ends.
Those kids in college he is talking about taking up reams of paper to do stuff is because they didn't know WTF they were doing. It's all abou
Re: (Score:2)
Re: (Score:1)
I have to agree with you. C has got to be the most costly language ever to escape the language lab loony bin. The second being SQL. Think of all the vulnerabilities, bugs, errors, etc. that we've had to hunt down and remediate because of the lack of simple things like type and bounds checking, and garbage collection?
Languages are developed because the author feels that there has to be a "better way" or to solve a specific problem space. Some are successful, some aren't. K&R developed C due to the s
Re: (Score:2)
I think the problem isn't that authors feel there has to be, as you say, a better way, but that once a language has enough of a community people want to import all the capabilities of other languages INTO their preferred one rather than use another language.. so anything popular enough sorta decays into a indistinguishable mush that has all the same features as the other popular languages.. alway
debugging LISP is really more difficult (Score:3, Insightful)
there seems to be this persistent view that somehow LISP is more difficult to debug than things like C/C++ or Pascal or, i guess, procedural languages in general.
Having done both (sort of, i've used scheme, not lisp, and C/C++) i can very confidently say it is not.
This particular example from TFA is not a great one for making a comparison.
Real time code is really, really hard. Coding this app in C/C++ would have been every bit as difficult to implement, and every bit as likely to create hard to find bugs. instead of deadlock it would have been a deadlock AND a dereferenced NULL pointer, lol.
The real question is, how long would it have taken to code the same application in C/C++, and how many errors would there have been and the end of it ? Hard to say.
Plus, aren't they going to be using Ada for future missions ? ;-)
Lispen to me! (Score:4, Interesting)
A quick read of tfa shows they used LISP to create a programming language where it was impossible to have a deaocked condition, and proved it and tested it.
Then a deadlock happened anyway. Some support programmer had written a low level function that didn't adhere to the no-deadlock requirement.
So...not a LISP problem, but a communication problem where the lead did not emphasize that to the other devs. Probably some level of integration testing fail as well.
I've done everything from AI in LISP to deeply embedded on mission critical stuff without even an OS or tasks, and everything inbetween. Knowledge of this all is highly valuable.
Python is a Lisp (Score:1)
Re: (Score:3, Interesting)
eh, that's a bit of a stretch. Python lacks homoiconicity, and its scoping rules are downright primitive. Also, there's really no equivalent to a macro system in python. I'm not saying it's not a good language -- python is a wonderful language. It's just no lisp.
Re: (Score:2)
You people know Python is a Lisp, right?
It really isn't. Python is shit, for a start.
Lisp complexity is O(x^2) (Score:3)
Re:Lisp complexity is O(x^2) (Score:4, Informative)
150 Million Miles Away? (Score:1)
8th Wonder of the Universe (Score:2)
Garret essay in 2006 (Score:1)