Flutterby™! : Python 3.0 2008-12-05 15:23:57.905743+00

Python 3.0

2008-12-05 15:23:57.905743+00 by Dan Lyke 12 comments

Python version 3.0 has been released, and somehow I happened across the /. thread on this topic which had someone commenting about the from _future_ import ... feature for exploring forward compatibility, in which it came out that from _future_ import braces results in SyntaxError: not a chance.

On the notion of Python in general, it's becoming a cleaner more consistent language, which, on the one hand, makes it appealing like C, but on the other hand pushes it towards just being "a better Java" rather than either a better Perl or a better C++. I like Python in theory, but every time I sit down to do something in it I wonder why I'm not writing in either of the latter two.

Perl results in unmaintainable code. As much as I love the concept of a language that tries to "do what I mean, not what I say", I find the syntax hard to keep straight in my head because too much happens "automatically". I'm sure that'd be different if I used Perl daily. I don't have to use Python (or C/C++ or Java) daily to be able to get my head wrapped around a piece of code.

Python reminds be of how nice it is to work with an interpreted language but I quickly start wishing I was using C++ as soon as I misspell a variable name or loose track of which code block I'm in because there is no terminator for the end of blocks. BASIC (even the Visual variety) makes up for the linguistic failures of Python - but I think Bill G.'s love of that language kept it from seriously being considered by open source folk. And Microsoft never let it take off...

PHP has become the lingua franca of the web. I was always able to do what I needed on the back end of a web server with perl or tcl (anyone else remember/use aolserver?). However, I've now been reorganized into a hacker/tool group with a fat server and what's the toolset?: Apache+PHP+MySQL (on Solaris so not LAMP). Therefore a PHP programmer I shall become.

My problem with the xAMP tool stack is that it forgets a couple decades of IDE development. You end up leaving breadcrumbs. But the architecture is perfect for the application.

Maybe this is a good thread to ask this question: what good tools are out there that help PHP overcome its "the code is the template" problem? I've mostly worked with Rails and other MVC-type stacks, and that architecture seems to work for the kinds of problems I come up against.

I am not a PHP programmer, but having written a fairly extensive templating system for Perl, I think my attitude is starting to evolve towards "CSS is your code vs appearance separation mechanism". But I haven't done much HTML/web stuff recently.

#Comment Re: made: 2008-12-07 07:44:48.256692+00 by: meuon [edit history]

CSS and basic html/table code is wonderful stuff, when kept to usable minimums, CSS and a few PHP-ish variable options makes a wonderful "code/vs appearance seperation mechanism", I fight the MVP/MVC terminology, yet yearn for ways to make such things happen effectively. And theirin lies the problem, hand coding PHP pages, with an understanding of what is really going on makes for some very powerful, efficient things that I don't think an IDE and normal framework will allow.

The real problem is the web has evolved, and uses a little bits of many things, all with different syntax. My latest small web ~~abortion~~ project uses PHP, JavaScript, MySQL, CSS, XML, Flash/ActionScript for the front end, and the back end uses PHP, Perl. MySQL, Ansi C, and some shell scripting. The PHP alone is > 15k lines..

While I have little experience with modern IDE's, I think they work better when most of the project is in one language and toolset.

I've done one little thing in Python,, It's neat, it worked, but I kept wondering why we needed another scripting language with such different syntax/layout.

And for those PHP nuts that don't know about it: PHP Beautifier is a wonderful tool.

dexev: Smarty is typically the tool that is used for templating. I find it works great for me, but then I'm not worried about high performance.

Dan: I'm thinking less of appearance than control of content -- 'fill this table with the contents of this array' sort of thing.

The part of PHP that bothers me is that it is very much a templating system on steroids -- the default mode is to send output to the browser. It sounds like meuon has some PHP files that are just HTML + basic control structures and variables, and just has a mental separation.

I've been looking into doing some independent web development work, and there are a *lot* of people wanting to use a LAMP stack. I've used PHP before, but I have some issues with it -- which is why I mostly use Python -- but it looks like I'll be spending some time learning.

#Comment Re: made: 2008-12-08 08:56:40.165492+00 by: spc476 [edit history]

One problem (of too many to get into right now) with PHP is the difficulty in separating logic, layout and language (that is, human language, not computer language) in such a way as to keep from going absolutely mad in the process (throw in some DSLs like SQL and the madness grows). I've wondered what a multi-language IDE would look like, and almost wish I had one (right now, I'm maintaining a PHP project with a MySQL branch and a PostgreSQL branch; it's not pretty).

But how else would you describe any PHP-ish web project, although specifically for me it's PHP that outputs HTML, not HTML with embedded PHP..

Sure, I've also hacked on more true "MVP" code like MediaWiki, and even messed with Smarty some. I find that level of abstraction fat, obtuse and distracting. But luckily, (most of) my clients really don't care about tweaking look and feel, I do boring web database and communications stuff.. and by being good at mixing "logic and layout" I can make some pretty nifty things work well. And yes, it's a real painful kludge to maintain.

SPC476, that stuffing all the language into an array "die ($lang['a_horrible_death']);" is a mess. My way is far worse, I run everything through mysql lookups via a function. But it works well enough that I'm delivering some interfaces in Chinese. Fast hardware is cheap, and these systems get few actual page views. Dang MySQL is fast. And I've got some awesome PHP tricks for grabbing real time translations via Google's translate functions and stuffing them into SQL so the next I need Spanish for "Enter Payment Amount" it's local. the translations are then editable by the client once loaded so they get tuned up well by a human to be correct in context. Tuesday, I'm demoing in Japanese. I sure hope those translations don't insult some ancestors.

#Comment Re: made: 2008-12-08 13:49:07.224064+00 by: Dan Lyke [edit history]

Okay, it's supported now, although it looks like there's nothing in the stylesheet for it...

#Comment Re: made: 2008-12-08 19:40:30.741456+00 by: spc476 [edit history]

I actually inherited the codebase, and sticking the language stuff in an array was the way it came to me, so I stuck with it (even though there's only one language supported, English). I find that less annoying than the differences between MySQL and PostgreSQL (so close, oh so close).

And thanks Dan. I tend to over abuse <ACRONYM>, but only because I personally want to know about the IRA for the IRA IRA and not get confused.