Live data from Hacker News

Mongrel2 Says, "Goodbye Python"

sheddingbikes.com

171–180 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#171

Earlier quoted context omitted.

I'd very much like to know why it wasn't easier for him to simply write a Python code that doesn't use anything not existing in 2.4. This isn't an "oh, a brand-new version just now came out and it's not in the distros yet" problem. Python 2.4 is six years out of date at this point. Python 2.3, which Red Hat will support until 2012, is even older (and for the longest time Red Hat didn't even use a 2.x Python at all --…

So after complaining that he could not use new language features that appeared six years ago, he went back and rewrote the whole thing using a different language whose syntax is much much more than six years ago. I guess he must have found these must-have Python 2.5 language features that are so important and desirable in C. And by the way, don't use new GCC features, because some ancient GCC versions will be support…

It was users complaining, not me. I had no problem with Python, but all of the non-python users (the users of one of the 9 other languages Mongrel2 supports) hated Python for these reasons.

Re: Mongrel2 Says, "Goodbye Python"

#172
post #76

Instead of inventing your own syntax, why didn't you use a portable syntax like XML, JSON, YAML, or better yet, libconfig[1]? Please compare the libconfig test file to the mongrel configuration file: http://www.hyperrealm.com/libconfig/test.cfg.txt http://mongrel2.org/doc/tip/docs/manual/book.wiki#x1-190003.... The mongrel conf is a subset of libconfig; it doesn't use the more advanced features. Plus libconfig has bi…

I thought about something like that, but wanted to duplicate the existing config file format so that people's configs would keep working (mostly). It actually had some cool advantages, like a nice psuedo variable system letting you setup variables for reuse in different parts of the config file. I haven't really seen that in other config formats, and it is damn handy.

libconfig has include directives, is far more useful to multi-instance setups. Plus you get a full type system, all in a 33k binary.

Re: Mongrel2 Says, "Goodbye Python"

#173
post #124

Earlier quoted context omitted.

There's a lot of equivalent old warts in Perl that haven't been fixed This is the crux of the issue. Serious language users (especially the ones writing the new libraries that add significant value to your platform) want the warts fixed to make the environment pleasant to work in. Meanwhile, most casual users are desperate for backward compatibility because it makes distribution easier. I actually prefer Python's cho…

I should have said: They haven't been fixed by default . Perl is also moving forward, it's just doing so differently than Python. Python has major releases like 2.6 and 3.0 where they explicitly break old code in the default installation. Perl however doesn't break any of the old warts by default, but developers can easily do so by importing modules like Moose and perl5i in their own code. See http://search.cpan.org/…

> Perl is also moving forward, it's just doing so differently than Python. Python has major releases like 2.6 and 3.0 where they explicitly break old code in the default installation.

3.0 yes, but 2.6 is simply not true. code written for 2.2 will work in 2.6, bugs notwithstanding.

Re: Mongrel2 Says, "Goodbye Python"

#175

I have found that the one system that doesn't give me any trouble running Python is Ubuntu. I'm using Ubuntu Server 10.4, specifically, which is the latest LTS (Long Term Support) version. Ubuntu 10.4 has Python 2.6 but I wanted Python 2.7 (which is the LAST 2.x version). So here's what I did: I installed all common dependencies (such as OpenSSL with "apt-get build-dep python2.6", since they're all the same for Pytho…

Oh yeah, that's no trouble at all.

Re: Mongrel2 Says, "Goodbye Python"

#176
post #163

So what can we learn from this for designing future languages? Make it standard idiom to have every file of code declare its version-dialect at the top? Default to throwing warning if interpreter and code version-dialect mismatch? Have the main code interpreter called by all code files simply be a host for routing code to the correct dialect-version interpreter? Perhaps include an optional "slim" download where the h…

> "So what can we learn from this for designing future languages?" We can learn that it's inevitable that your language will come into fashion, be hyped up to be "the language", then will fall out of fashion and be declared 'dead'. The idea of a '100 year language' is solid as long as developers don't choose languages like they choose what to wear. Unfortunately though, most developers seem to choose based on current…

Programming language popularity works like fashion, but not because developers are shallow and finicky. It's because it's actually important what other developers are using. You could have the best programming language ever, but libraries, resources, help, and advice won't exist until you have a lot of people using it. There's enough adventurous programmers to bootstrap this cycle with new languages, but the general principle holds.

Re: Mongrel2 Says, "Goodbye Python"

#177

Earlier quoted context omitted.

Will be using it host a small e-commerce web site that I am building on the side.

I would tend to say go with Debian, if that is your aim. While I understand that some of the Ubuntu long-term support releases have stable package bases, I have had nowhere near the same level of comfort with an Ubuntu LTS as I have with Debian stable, especially when boxes are to be migrated to newer releases. With Ubuntu the LTS to LTS hop is often not successful, usually for lack of testing, whereas I've rolled fr…

Thanks for all the replies.

Re: Mongrel2 Says, "Goodbye Python"

#178

So what can we learn from this for designing future languages? Make it standard idiom to have every file of code declare its version-dialect at the top? Default to throwing warning if interpreter and code version-dialect mismatch? Have the main code interpreter called by all code files simply be a host for routing code to the correct dialect-version interpreter? Perhaps include an optional "slim" download where the h…

I'd say a good start would be:

1. Less syntax, so that later language features don't cause upgrade problems and can more easily be worked around rather than causing syntax errors. 2. Awesome package management with everything not core in packages that work with the distros so they don't mind using them.

Both of those are damn hard to do though. Less syntax makes the language fairly unusable (Forth), and package management is just a nightmare in general.

Re: Mongrel2 Says, "Goodbye Python"

#179

Zed Should have used Lua(the entire lua source distro weighs couple of hundred kilo bytes). Lua is superb embedded language and even better configuration language. No one needs to know it is Lua, (which also happens to be a marketing problem for Lua, heh). His decision not to use Lua the second time around is perplexing because he is not averse to reusing third-party libraries and he is already using the code from Lu…

Well, he said he made the new parser read the unchanged config file format. Presumably, lua would have needed a change of syntax. Also possibly he decided to step outside the language wars because it's less hassle to write your own parser than wrangle language partisans.

Exactly. It was part technical and part social.

Re: Mongrel2 Says, "Goodbye Python"

#180
post #163

Earlier quoted context omitted.

> "So what can we learn from this for designing future languages?" We can learn that it's inevitable that your language will come into fashion, be hyped up to be "the language", then will fall out of fashion and be declared 'dead'. The idea of a '100 year language' is solid as long as developers don't choose languages like they choose what to wear. Unfortunately though, most developers seem to choose based on current…

Programming language popularity works like fashion, but not because developers are shallow and finicky. It's because it's actually important what other developers are using. You could have the best programming language ever, but libraries, resources, help, and advice won't exist until you have a lot of people using it. There's enough adventurous programmers to bootstrap this cycle with new languages, but the general…

I agree to an extent. That stuff matters when you're starting out and just learning. But after you get to a certain level the 'language ecosystem' isn't important at all IMHO.
Post reply on HN