Still, switching from Lisp to Python is bound to be painful...
Still, switching from Lisp to Python is bound to be painful...
- you use softwares that are scriptable in Python (SIG, Blender, etc)
- you write a lot of glue code. That pretty much Python raison de vivre.
- you do a lot of data analysis manually. Pandas is the new excel, and jupyter the new matlab.
- you do a lot of sysadmin. Scripting is just easier in a dynamic language.
- you do a lot of CRUD websites. You just can't beat the frameworks from this language for this kind of things. They do most of the work for you, and do security better than you do.
- you want to integrate new members in your team faster. Python is easier to learn than lisp.
- you are coding a GUI. With kivy you can target desktop and mobile with one code base, and some skins are pretty (https://imgur.com/a/IjM0XGW). With QT you can do powerful things on the desktop. With wx you can do simple GUI simply.
- you have a lot of different kinds of task at hand, and don't want to have too many different languages in your stack. Python is never the best language at anything, but it's a damn good language for most things, so it makes it a versatile toolbox.
Heh, I listed Python in my resume and got this as my first job (after working at my local college) and I learned it on the job (I had used Python before, but nothing major yet) and I gotta say, not only is it easy to pick up if you know other languages, it's fun to experiment with if you do know other languages!
I have only played with Clojure and Racket the most on the other hand, I appreciate them and would love to learn more but I get more done with Python in shorter spans of time.
When it does, you use another tech. E.G, you needed something to consume less RAM, or you target the browser, or you want an small APK, you need multi-core AND cheap memory sharing, whatever...
But the thing is, short of some very specific constraints, Python is good enough for a lot of things and so we don't "forget" about other languages, we just end up not needing them more often than not.
I also had BeeWare hit my radar again this year at PyCon. The last time I looked it was "just" an IDE, which I had no need for. It turns out they've basically written an entire cross-platform GUI framework since then, and based on my brief conversation with their representatives, it looks to be pretty damned handy. In particular, they mentioned that a minimal iOS or Android app ends up being ~5MB - Kivy's big problem when I last looked at it was that the resultant applications were huge.
I'm not so sure on this point.
I've been writing Python for just over a decade now, with a year or so of Ruby thrown in for good measure. At a previous job I was asked to implement an authentication service in Clojure. It took me longer to understand the Clojure ecosystem than to learn to actually write the code. In ~3 weeks I went from having never seen Clojure to having a complete (if minimal) application that authenticated users against third parties via OAuth and issued JWTs.
I'd agree that it would be much easier to onboard junior-level developers to a project that's written in Python (or any similar language), but if you're targeting more senior-level people any modern language isn't really going to be a significant barrier.
That's especially true for lisps - there just isn't a lot of language structure to learn. Python is a "shallow" language in my opinion - there are only a few layers of complexity between a newbie and complete understanding of a language feature. Lisps are shallower still.
>
>There is one legitimate reason to switch from Lisp to Python: The number of packages and extensions. Python really has more than just batteries included
Which you can "steal" by using them from Common Lisp. By using the lisp library called "burgled-batteries".
But still, as pointed below, the Java ecosystem is even bigger, and you can easily leverage by running Common Lisp on the JVM (using Armed Bear Common Lisp).
And then there is Clojure, a lisp-like language that is weaved together with the JVM and thus with very easy ways to interoperate with the JVM.
Only their teachers need to adjust to the updated code examples in Norvig's updated book, and this summary is a very nice introduction to the main differences between two basically similar languages.
When and whether students should learn Lisp, Python, neither, or both is an entirely different issue.
> I prefer programming in Lisp, but the packages available for Python makes me a lot more productive. That alone is enough for me to choose Python. I still miss Lisp though.
Language wars are started because people talk about their preferences as an absolute truth (and other people disagree with the presented absolute truth), and you don’t avoid them by starting with “I don’t want to start a language war” while continuing talking in the same way.
If you look at the other replies you see what typically happens: someone mentioned that Lisp does also have libraries, someone mentioned that there are other reasons to choose Python, someone mentioned that the article has a different focus (teaching, not writing). Instead of a comment thread where people talk about their experiences we have a thread where people point back at the OP and loudly complain “no, but see, you are wrong, because of x”. We even have a case where the OP is getting annoyed because someone assumed he didn’t know about Norvig. Seriously, this is exactly what happens when you write in such a style.
This comment alone will make someone annoyed because there are plenty of people who have used both Lisp and Python and (guess what?) prefers Python:
> Still, switching from Lisp to Python is bound to be painful...
And JavaScript with their one liner packages probably beats all.
Python still misses having a proper mix of AOT/JIT compilers as standard toolchain, like Lisp does.
I was going to say that C probably had more complete non-standard libraries than Java. But, on reflection, for the price of writing a JNI wrapper, Java can use all those C libraries, so Java gets the superset - its own plus C's libraries. In that environment, it is obviously impossible for C to win.
They're related to an archaic file format that is surprisingly popular, though still esoteric.
His post illustrates how many programming tasks have gone from problem solving to lego-brick programming, where library is piled upon library and each of them is incomplete and contains piles of bugs. What could possibly be wrong with that approach?
Just like Norvig, I don't claim that Python is bad per se or anything like that. All I've said is that it's painful to go from CL to Python in terms of the general features of the languages (not their tooling). If you have never done this transition, have never programmed sufficiently large programs in CL and Python, please don't comment on it.
Compared to problem solving which doesn't use "lego bricks" and re-makes the wheel?
And instead of a factory making it to recognized standards across that class of vehicle, it's an ad-hoc design for a particular vehicle.
Often it's also square.
As a programmer with full experience in both languages, I agree with this in 200%.