>Could you give me an example of a real-world software engineering task which takes “weeks” in Python and minutes in Lisp?
Not "weeks vs hours" but let me offer my personal experience. I already had around 3 years of professional experience in Python and about the same in Common Lisp.
Last year I had to create a small utility to help some document scanning process, this included doing some OCR. I had the choice to do this in Lisp or Python or whatever language (I also could as well have written the stuff in Java, C#, C, JS, etc.)
Initially I thought "ok, i have good tesseract binding and PDF output libs in Python, where as the Lisp bindings look unmaintained" so i chose Python.
Well, back into Python's antiquated way of working: No compiler-time checking of anything, and, even worse, upon finding an error, there was no way of correcting the offending function and restarting program execution at that point (restarting a stack frame). No sir, I had to run my whole program again (this was an interaction heavy program) to test it again.
So MANY hours were lost in just having to restart the program again and do all the clicks needed to bring back the program to a specific state.
Where with Common Lisp those hours would be reduced to zero, since I can modify the program while it's running and I can always inspect all stack frames and restart them at will. Not to mention other benefits in terms of being able to write code that is way higher in abstraction level. Not to mention I can actually SAVE the current program's state to disk and resume it back at a later date.
And not to mention that the Lisp program would probably had executed 20 to 30 times faster as well.
So far, that's the last time I chose to use Python for non-trivial tasks.
Not weeks to minutes, but still, try writing an Airlines booking, scheduling application which gets the traveler the best route given his/her requirements.
That is just an algorithm, isn't it? I cant see how it would be simpler to implement in Lisp that Python.
I suspect the issue is that a flight booking system is basically the only significant commercial system written in Lisp, which is why it is always dragged out in these discussions.
The claim was that something which would take weeks in say Python would take minutes in Lisp. Then this flight search system is presented as evidence.
I just don't see how it is any form of evidence for that rather extraordinary claim? It just shows it is possible to write complex software in Lisp, but I wasn't disputing that. I'm disputing the claim of 100 x productivity.
I was addressing your 'That is just an algorithm, isn't it?', in case you would be interested what that application is actually about.
There was no general claim of 100x productivity. The commenter wrote: "I had a lisp master that did teach me that what had taken me weeks in c, c++ and python code he could do it in lisp in minutes"
That was his personal impression, not a general claim. I can't also imagine how this could be a general claim.
Yes the sauce is in the algorithm and its a non-trivial one. Its a NP hard problem of searching through a combinatorial explosion of possible configuration. I am not aware of any other product that comes close to what ITA offered.
The feature of Lisp that was heavily used in the code was the use of macros and metaprogramming. These are the kinds of problems were lisp excels. ITA made use of the fact that Lisp is a programmable programming language and they adapted programming language to the domain.
I am not doubting that Lisp is a language with which can be used to write succesful commercial applications. I am questioning the claim that it is vastly more productive for commercial applications.
Of course it is not really possible to say how somebody else in a different language would have needed, so maybe a compromise would be to see some 'magical'lisp code examples.
If it runs on C++ now, it's been rewritten. Sabre predates C by many, many years and it almost predates Bjarne Stroustrup himself. I suspect a lot of it got moved to IBM assembly when they moved to S/360 mainframes in the early 70's. TPF is a descendant of that project.
