Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mongrel2 Says, "Goodbye Python"

sheddingbikes.com

Post reply on HN
Print view View original

161–170 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#161

Post by metamemetics »

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 host only includes the interpreter for one dialect-version, but make this non-default\opt-in.

Re: Mongrel2 Says, "Goodbye Python"

#162

Post by zedshaw »

nailer wrote: post #20
gaius wrote: post #18

Earlier quoted context omitted.

In the ancient days, stuff the OS relied on was in /usr/sbin and stuff that was "yours" was in /usr/local/bin (or /opt) and stuff that no-one was quite sure whose it was was in /usr/bin. And lo, peace and harmony did reign upon the face of Unix. And the sysadmin did lie down with the developer, and it was good. Who even knows how it works these days?

Stuff that belongs to the OS (but runnable by all users) is in /usr/bin. That's FHS. Stuff that's yours is wherever dir you specified when you ran: export WORKON_HOME=$HOME/.virtualenvs Seriously. Use virtualenv (and virtualenvwrapper). http://www.doughellmann.com/projects/virtualenvwrapper/

People who don't do Python won't/can't use virtualenv. Also, you don't think that's a nasty workaround for something that should just be a non-issue? That's like you telling me to use NetBSD pkgsrc just to get around some ancient linux (which I have done).

Re: Mongrel2 Says, "Goodbye Python"

#163

Post by points »

metamemetics wrote: post #161

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 fashion rather than anything else.

Re: Mongrel2 Says, "Goodbye Python"

#164

Post by troutwine »

barfoomoo wrote: post #122
wwortiz wrote: post #117

Earlier quoted context omitted.

It depends on what you are using the server for and who is using the server. Ubuntu and debian are used by plenty of people in production and are probably the better choice for learning how to set up a server if you already use ubuntu. Apt is also a great package manager.

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 from one Stable release to another many times with no issue. The Debian project works very hard to do regression testing, issuing a new release only when the release is finished. This has proved to be more prudent an approach that that of Ubuntu's, which opts for a hard(ish) 6 month release cycle; a new LTS is release every two years but is a 6 month iteration over the last Ubuntu release plus some influx from Debian Testing.

It could well be that I'm biased--and you should certainly go with what you are comfortable if this is to be a one-man show--but in the pony show that is choosing a server OS, I'd go with Debian every time.

Re: Mongrel2 Says, "Goodbye Python"

#165

Post by zedshaw »

antileet wrote: post #8

Hi Zed, Can you please elaborate with some details about how "broken" python is on systems, and the situation with python 2.4? According to the article, "recent Ubuntu releases" had broken/deprecated python installations. A quick search reveals that python 2.5 has been shipping as the default "python" meta-package(?) http://packages.ubuntu.com/search?keywords=python Can you also please elaborate any "features" that t…

It was a fairly small chunk of Ubunutus that had problems with Python versions. I made sure m2sh-py worked with 2.5 (since I had an OSX around with 2.5) and I ran into a couple people with what was a recent Ubuntu, but with a 2.4 Python. Boggled the mind, but then again people do really weird stuff with their systems.

If your application is going to depend on Python then you definitely need to evaluate who's using it. If it's like mongrel2 where sysadmins will need to install it on various Linux distros they might not control, then you're screwed. You'll need some kind of installer that hooks up the right kind of python in a safe area.

If it's more like a Desktop application, then just get it to work on the latest of the desktop Linux variants, and then have it bomb out if they don't have the right python. People on Desktop systems are used to having to upgrade to use software.

Re: Mongrel2 Says, "Goodbye Python"

#166

Post by ChuckN »

ptn wrote: post #109
bcl wrote: post #94

FYI - Fedora 13 shipped with Python 2.6, Fedora 14 is going to ship with Python 2.7 and 3.1 in parallel. Not every distribution ships ancient versions. I also recommend using virtualenv and pip, these tools make it much easier to create an easily reproducable Python environment.

CentOS is on 2.4

Why are people using anything but Ubuntu anymore

Re: Mongrel2 Says, "Goodbye Python"

#168

Post by metamemetics »

points wrote: post #163
metamemetics wrote: post #161

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…

Let's try to be constructive here!

Come up with solutions and ways to avoid the problems mentioned in the future. There's always fashions and trends sure, but I think most people chose to program their last web app in Python or Ruby over assembly for more practical reasons...

Re: Mongrel2 Says, "Goodbye Python"

#169

Post by zedshaw »

acqq wrote: post #63
ubernostrum wrote: post #55

Earlier quoted context omitted.

You can write code that runs on 2.4, yes. But you miss quite a few useful features of more recent Pythons by doing so (context managers, for example, are a big deal, as are several of the newer standard-library modules). The same thing used to happen with Python 2.3; you could write 2.3-compatible code, but it meant no decorators, no generators, etc. Python has these useful features and has had them for years; why is…

In his particular case, he certainly was not missing the newer Python modules as he was able to write a "small" C-only replacement. That what he wrote in C would certainly be easier to write in Python 2.4 (or 2.2) Did you understand that he wrote the big C program just to process a small file with the syntax as in the following example (taken from his own file): main = Server( chroot="./", hosts = [mongrel2] ) settin…

"Big"? You keep using that word. I do not think it means what you think it means:

  $ rm src/parser.c src/cli.c src/lexer.c src/linenoise.c 
  $ wc -l src/*.c src/*.rl  148 src/ast.c
  646 src/commands.c
  267 src/config_file.c
   93 src/constants.c
   36 src/m2sh.c
   13 src/token.c
  186 src/cli.rl
  156 src/lexer.rl
 1545 total
That's dinky tiny, even with the linenoise and generated files it's only 4061 lines long, which isn't much at all.

Re: Mongrel2 Says, "Goodbye Python"

#170

Post by points »

metamemetics wrote: post #168
points wrote: 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…

Let's try to be constructive here! Come up with solutions and ways to avoid the problems mentioned in the future. There's always fashions and trends sure, but I think most people chose to program their last web app in Python or Ruby over assembly for more practical reasons...

heh true, although you sure can learn a lot doing things the 'unaccepted' way. So I'd actually advise everyone to try writing a webapp in assembly.

If most people tell you what you're doing is crazy, it's often a big sign that you should do it.

Post reply on HN