Ian Bicking

"The Smalltalk image may seem unfamiliar or even scary at first, but it's really little different from a standard Ruby or Python process, except that it is serializable and contains all of the code (both compiled and in source form), data, and execution state as objects that you can manipulate."

Well that's not very similar to a Ruby or Python process then, is it? And those processes are short lived and built from scratch on every execution. Anything you want to keep around you have to serialize and save explicitly. This is a painful but useful discipline. Perhaps an interesting analog, Docker emphasizes recreating over storing, while in normal sysadmin practice you update systems in place. In theory they can achieve the same results, but enforcing discipline makes a difference in practice.

Smalltalk of course is code, and you can do whatever you want with it. And Smalltalk is delightful in many ways, I enjoyed it a great deal when I used it, and people using Smalltalk can be very productive when they have to recreate the world. But you have to recreate the world. And there's strong cultural drift. Lots of things are possible, but possibilities aren't enough to create a community of practice.

Looking at files, I looked up "using git with smalltalk" and got the GitHub list of Smalltalk projects: https://github.com/trending?l=smalltalk – I look at one that has a couple contributors, find Cuis: https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev – it's got giant…

Ian Bicking does a great job of debunking the many of the alleged advantages of code sharing: http://blog.ianbicking.org/2011/03/30/js-on-server-and-client-is-not-a-big-deal/

Validation on the client is primarily a user experience concern,
where you focus on bringing attention to problems with a form, and
helping the user resolve those problems.

Once the form is submitted, if you’ve done thorough client-side
validation you can also avoid friendly server-side validation. Of
course all your client-side validation could be avoided through a
malicious client, but you don’t need to give a friendly error
message in that case, you can simply bail out with a simple 400 Bad
Request error.

At that point there’s not much in common between these two kinds of
validation — the client is all user experience, and the server is all
data integrity.

Absolutely right: Ian is one of the best Python programmers and technical writers ("blogger" just doesn't capture it) whose prose and code I've ever had the pleasure of reading and using for decades. (I'm still maintaining a TurboGears project using his SQLObject library even today, which I gleefully adopted as a traumatized Zope refugee.) If I had an open position worthy of his talents, I would move heaven and earth to work with him.

https://ianbicking.org/events-and-sqlobject.html

https://ianbicking.org/archive/sqlobject-and-me.html

https://en.wikipedia.org/wiki/SQLObject

Edit: In case you have "show dead" enabled, I'd like to add that smohare has no fucking clue what he's shit talking about, but by looking at his dead downvoted posting history and useless comments and worthless opinions, to be jealously insulted by him is the highest complement.

In my experiments (http://blog.ianbicking.org/2008/03/30/python-html-parser-performance/) lxml performed better than cElementTree for memory -- notably cElementTree creates Python objects for all nodes, while lxml does so only on demand (though I suppose if you ultimately touch every node in Python then lxml will use more memory).

Also lxml preserves the namespace prefixes, which while formally not necessary to understand a document are often in practice both aesthetic and sometimes necessary (e.g., RDF).

Also algorithmically, I find lxml's parent pointer on nodes to be very handy. I find some things really really hard in ElementTree because you can't directly get the parent of a node.

There are lots of people that agree with you: http://www.plope.com/Members/chrism/pythonic

I preferred what Ian Bicking wrote in response: http://blog.ianbicking.org/unzen-of-unpython.html

One thing I like about the Django community is that part of Djangocon specifically features critics who are invited to criticize Django or some aspect of it, for example:

"Why Django Sucks and how we can fix it"
http://blip.tv/djangocon/why-django-sucks-and-how-we-can-fix-it-4131303

Flasky Goodness (or Why Django Sucks?)
http://reinout.vanrees.org/weblog/2012/06/06/flask-django-sucks.html

That's much better and productive than circling the wagons and letting personal insults fly.

So Python 2 did not have super obvious string handling. One of the odd things that they seemingly could have fixed pretty easily is to change the default encoding from 'ascii' to 'utf8'. That would have fixed a bunch of the UnicodeDecodeErrors that were the most obvious problem with strings: http://www.ianbicking.org/illusive-setdefaultencoding.html

If they had to make Python 3 anyway, I think the main thing they were missing is that they should have added a JIT. That makes upgrading to Python 3 a much easier argument. If the only point of the JIT was to add a selling point to Python 3, that probably would have been worth it.