Ian Bicking: the old part of his blog

Re: Why Web Programming Matters Most

interesting discussion.

i'm rather new to this web programming world, but i've spent the better part of the last 6 months developing a web application framework to build a commercial web app. a considerable amount of time was spent considering the existing open source solutions there were out there at the time (i hate to reinvent the wheel). (FWIW, i ended up using something very simple and nice called "draco" and plugging SQLobject into it, and then writing custom code on top of it.)

i think that there are no easy answers to the python web programming issue. there are too many different pieces and too many varying desires. it's a very exciting sphere. some people what an object db backend (better conceptual mapping to data structures), some people want SQL db backends (solid, fast, tried tested and true). some people want to use apache as a front-end server, some people want a single running process (e.g. Zope). some people like a distributed model of treatment (many childs running, e.g. mod_python), some people like an event-based model (simpler, e.g. twisted). some people want one thing to do it all (zope), some people want to provide independent pluggeable pieces (e.g. python webobjects). some like templates (zpt, etc.), some don't (e.g. using stan directly to generate a tree). some people like to write low-level unit tests (e.g. zope), some people like to test from the browser's point-of-view (e.g. using mechanize).

lots of options. you want to get started in a few hours?

i haven't seen anything serious out there that allows you to create a SERIOUS app in a few hours. sorry. it's either too complicated, or there is something you have to fiddle with to make it do what you want. i don't even believe it's possible to do so. and it doesn't even matter. you can't do this in a few hours if you're trying to solve a real complex problem, with lots of customers banging on your app at the same time (and you HAVE to simulate that). sure, you can write a cool little happy demo in ruby-on-rails (or whatever hello world comes with the python frameworks out there) but writing a seriously complex app will ALWAYS require of you that at some point you will be debugging some deep problem down to the bare metal, some race condition, some hard-to-find bug that'll suck an afternoon (or even sometimes a couple of days). software is hard. the more experience you acquire, the more you become aware of this. it just won't go in any other way than getting hurt year and year by the same tendencies to want go fast fast faster. writing a serious product REQUIRES of you that you write a lot of tests (or spend painful hours fixing bugs reported by customers). this will seem a bit lame, but IMHO in a few hours you barely have time to draw a couple of diagrams and explicit the most important issues in a document. if you have much development experience, you've been hurt in the right places and you can sort-of "foresee" where it's likely to hurt again. you walk about a little more carefully. if you think that you can finish a production-ready app in a few HOURS you're fooled. you've got NOTHING. VALUE in software, real value, is acquired with testing and with real usage from real customers, and years of maintenance, not once you finished the code. once you're code complete, you still have no value. you have a good intentions and a first step. this is why there is still a lot of COBOL code around. it's got great VALUE. it's _working_ code. it solves _real_ problems.

this reminds me so much of OLE/COM. you had these macros that were supposed to do all this magic CoCreate factory stuff for you, but as SOON as you needed to move a little bit away from what was intended, you had to write all this goo by hand. same with the web programming frameworks: do NOT judge it by its "hello world". this is why i'm not the least impressed with the ruby-on-rails demos i've seen. all i saw was that doing the trivial thing is easy, and it comes out of the box. can i really develop a large serious app with it? (Maybe yes, maybe no. I still don't know.)

so who cares if the newbies can't get in easily? who cares if the "hello world" is nicer with ruby-on-rails? who cares if there is nothing comparable in python? who cares if PHP is attracting a lot of people?

in the end, if you're a hacker, you'll put the pieces that you need together and you'll just make it work. you'll get down to the bare metal and just f**ing fix it. because you have to. put your hands in the grinder and the grease. i truly wish that we had found the magic formula to make software development easy for everyone but we're not there yet. you still gotta do your homework, learn your data structures and algorithms, and learn practical DIY skills.

and you know that even those writing PHP code today will have to do that once their app becomes anything close to serious. and they'll suffer. the grease pit of python is not bad at all if you ask me. the C code embedding is super nice, and the modules code is simple to understand, when you have to go there. anyway, they'll eventually gain experience. and they'll eventually look at it again and recognize the elegance of Python and that in the end, it's not that hard to pry all the pieces you need to make it work, and it's worth the boot-up effort. those who don't get it will keep suffering in their PHP world.

so how do we make Python more accessible to the web programming world? the language already rocks. the libraries are all there. all you have to do is provide one good solution to get the newbies hooked up, and one good solution that makes it easy to install as PHP. AFAI can see all that is needed is easy deployment. what is the big deal? people with serious intentions will get over the lack of quickstart appeal.

cheers,

Comment on Why Web Programming Matters Most
by Martin

Comments:

"so who cares if the newbies can't get in easily?"

Anyone running a project on a tight budget! Yes, PHP is short-sighted but newbies can get the demoware ready quickly and cheaply with PHP. When choosing two from [good, fast, cheap] tight budgets imply cheap. Fast will make typical management happier than late goods.

Not caring is always an option, quality survives. Lisp, Smalltalk, etc. Those tools also generate these debates.

# anonymous