web.py never really worked well, so we ended up rewriting it again. The interesting thing was that Django still wasn't up to the task when we did that, mostly because it's templating engine was too slow. So we chose Pylons instead.
It should be noted that Django has since fixed that issue.
Was there one specific problem with web.py or multiple issues? Was there ever a write up about what you guys learned from trying web.py? Would be an interesting read.
Keysersosa answered this better below, but basically maintainability. There was no writeup, I guess because doing write-ups about internal software switches wasn't really a thing back then. :)
About this:
===If Lisp is so great, why did we stop using it? One of the biggest issues was the lack of widely used and tested libraries. Sure, there is a CL library for basically any task, but there is rarely more than one, and often the libraries are not widely used or well documented.===
If Clojure was available back then and if you had written it in Clojure instead of Lisp (and given that Clojure can leverage JVM based libraries) - would you still have continued using Clojure?
I know this is an extremely hypothetical question but I am trying to figure out if Lisp is finally getting ready for "mainstream" adoption because Clojure is bootstrapped of the libraries of Java.
Clojure is a beautiful language and its web ecosystem is improving rapidly, but breadth of, depth of, and support for libraries is still its main weakness next to the likes of rails and django. Clojure's a lot better for solving hard problems, but you'll also spend a lot more time getting tripped up by things that seem like they should be easy and reinventing wheels. Fortunately, it seems a near certainty that this will eventually no longer be true.
I don't work there so I don't really know, but I do know that I usually don't use Django for the reasons listed in the blog post -- namely that you have to live in their world view to write Django.
At the time that we switched to pylons and decided to punt django, flask didn't exist. I believe it was some time on '07 or '08. I'd check, but I also think it predates our switching to git from subversion...
Personally I like flask a lot and it's come a long way. Also, when spez and I moved on to hipmunk we started using tornado.
The switch to Git happened one day before we open sourced on June 17, 2008, I remember that day well :) So yeah, the history of when we switched to Pylons is probably lost forever sadly. But yes it was right around when I started in March '07 that you guys started working on the transition.
A lot of the decisions made in designing web.py were also carried over to tornado's web framework (which not coincidentally is also a web.py).
At the time (and I have to admit my memory is a little foggy as it was 7 years ago), I believe we mostly switched away from it for maintainability reasons. It wasn't under active development, and we were in the middle of a complete MVC rewrite to impose some order on some otherwise organically grown code.
That version of web.py has little relation to the one that Aaron wrote. The current version looks pretty good but I have no idea what it's scalability and modularity story is.
That's a little glib, but basically I ask other people with experience. You can throw as much fake traffic as you want at a framework but there is nothing like a real world test.
Django templating is still pretty slow.... the last time I benchmarked it (maybe 6 months ago) it was a fairly large amount slower than Jinja2 (3-4x maybe?)
What's cool is that there is a legitimate push to make Jinja a first class citizen in Django, with other third party templating engines being available via a new API.
Yeah it should be noted that all of the referenced decisions we made around web frameworks in this thread predate django's 1.0 release. I think I was comparing pylons to django 0.96 iirc, and in 2005 when aaron wrote web.py, I don't think django was on anybody's radar (or at least it wasn't on ours).
You're right. Settings are not even necessary in my example, as we should be fine with defaults in most cases. The only lines you really need are these four:
from django.conf import settings
settings.configure(ROOT_URLCONF='polls')
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
You lose some of the Django niceties (like being able to provide your own custom settings on the command-line) but flask doesn't have them anyway.
The first Python web framework I used was Django. I'm really glad I came across it first because I was inexperienced at the time and it forced me to adopt a lot of good practices.
However, now that I'm more experienced, I can relate a little to what Aaron is saying here. Learning all of this boilerplate stuff is annoying! Recently, I started contributing to a friend's rails app and I found the process of learning how to use each separate little tool tiresome.
This is why I like Pyramid - it starts off dirt simple. Hello World is almost as short in Pyramid as it is in Flask. As you grow, you can start organizing and adding different things as you need them. It has absolutely 0 magic. I find Pyramid to be a happy medium between Flask's minimalism and Django's extensibility.
I think a lot of that is in the presentation of the tutorials and the documentation. There's a book on Oreilly called "Lightweight Django" that strips away all of the absolute non-essential cruft of Django and starts from scratch, slowly adding pieces from the framework as it goes along. It shows you why you need each piece and why it goes where it goes.
Django doesn't need the magic, it's just annoyingly presented that way.
I wonder. How popular is Pyramid? I ask because I found Pyramid to be quite intimidating the first time (I'm not an exprienced Python developer). It took me four attempts to finally 'get' it - the first three times giving up in frustration and leaving it alone for 2-3 months before trying again.
Now that I get it though, it seems like an interesting framework but not a productive one. I've only dabbled in Pyramid with my free time and have never built a serious project with it, but I can't imagine building anything large scale with it.
(I'm a .NET developer BTW, MVC is what I work with in my day job)
Shodan is a decently-sized website and runs on Pyramid (https://www.shodan.io). I don't know how popular it is in the general Python community, but it's been amazing to work with as a framework.
>The Lisp newsgroup, comp.lang.lisp, was upset about the switch that they’re currently planning to write a competitor to reddit in Lisp, to show how right they are or something.
That must have ended as a huge success, because as we all know the important thing behind a website is the backend language...
I think you miss the point of the parent comment, which is that backend language is an implementation detail and generally shouldn't matter to users. You can disagree with that point, it just is a very different point than anything addressed by noting that HN has a Lisp backend.
I recall reading a more scathing post from spez at one point about frustrations with web.py, but I don't seem to see it now. It may have been removed. In any case, Flask seems to be the inheritor of the "write webapps in Python" description.
web.py is still my go to for lightweight webapps. I won't start a big discourse on the pros and cons vs. other technologies, but I will say it is incredibly easy to setup and use.
Used Tornado, django and flask quite a bit, web.py only once. As others have mentioned, it didn't work that well, and the community around it is smaller than other frameworks. Again today, Django seems a bit cumbersome, Tornado works well but has a very low bus factor.
Pretty sure flask is currently the front runner in "python microframeworks".
The number of developers that can be suddenly and totally lost from a project (e.g., by being hit by a bus) without the project itself becoming unable to proceed effectively.
I'm not sure if linuxydave is joking, but for those not in on the joke, Hacker News is written in arc, a Lisp variant. Hacker News resembles early versions of reddit quite a bit and Reddit was a ycombinator funded startup. Early on there was a big overlap in the two communities, although Hacker News was quite a bit more exclusive and limited in scope.
When he said "Whatever happened to that Lisp clone?" I'm pretty sure he was referring to the part of the article that mentions the folks on comp.lang.lisp who were discussing writing a competitor to Reddit in Lisp.
The discussion was not about writing a new Lisp or Lisp-like language, but a clone of Reddit.
The fact that HN is a site that performs a function very similar to Reddit, and happens to be written in a dialect of Lisp is completely coincidental :-D (unless there has been some comment by pg about his motivations for making HN that I missed, but I kind of doubt it).
The fact that HN is a site that performs a function very similar to Reddit, and happens to be written in a dialect of Lisp is completely coincidental :-D (unless there has been some comment by pg about his motivations for making HN that I missed, but I kind of doubt it).
I believe pg stated that HN was supposed to be what reddit was originally.
>I'm pretty sure he was referring to the part of the article that mentions the folks on comp.lang.lisp who were discussing writing a competitor to Reddit in Lisp.
Yep, spot-on. It's the same with those guys who wanted to make a Facebook clone focused on privacy or whatever. Lots of talk and then you never hear about the project again.
You mean Diaspora? (or maybe there's another clone I missed out on). The founder of Diaspora committed suicide. I think the project mostly died with him.
Oh interesting. I didn't know it was still moving along. It had a lot of momentum a few years back, but hasn't been making nearly as much noise since. Not sure if the founder's suicide actually correlated with the dropoff in media attention.
We currently use web.py + gevent to run our API where I work. It's really easy to work with since it's so tiny and simple, and since we only need JSON in and out for now, it's perfectly sufficient.
Before web.py, we were on a scary Tornado implementation. The API was rewritten to web.py in a week with a minimal delta. We won't be on web.py forever, and gevent sometimes kicks up minor fusses, but I think web.py has given us a nice malleable form that helped us get out of a terrible place, and we can easily hop off once we decide where we want to be.
I'm not very familiar with Tornado (we've switched to mostly Flask now) but I'd be interested to know what kinds of problems cropped up that lead you to switch to web.py
Yup that was the case. Though, I believe it was also a long weekend -- I think it might have been Veteran's day because I remember putting the finishing touches on it around Thanksgiving.
I've used CherryPy on a number of projects, and I really like it, but rarely see it mentioned in discussions of Python web programming. It's light and minimal, and seems equally deft for writing APIs as conventional web page driven apps. Flask is mentioned all the time, however. Does anyone have insight into the popularity of Flask vs. CherryPy?
I think you can leverage these criticisms at about 90% of the framework software out there written in just about any language. Most developers like to create complex, complicated software mainly to show off their "cleverness" without thinking through the implications for the people that have to use it. It's as if they think that by cramming in every design pattern they can think of and using many different libraries together for no perceptible reason makes the software better when they could've achieved the same thing much more simply and cleanly if they had put a little thought into it. Such over-engineering is equally a problem as the spaghetti code of programmers who don't know better.
I'm not too familiar with Django but with several other frameworks and I definitely feel like this applies to lots of them out there.
In my experience though, I've worked on teams with developers who criticize frameworks for those reasons, choose a minimal or no framework at all, and spend a ton of extra, unnecessary time reinventing a worse version of a framework they decided 'sucked' once they realize they need security, error handling, form processing, an ORM etc... Over-engineering is an epidemic.
I almost went down this route on a project once. As soon as I noticed myself writing an identity map, I slapped myself in the face and just downloaded Symfony.
Funnily, this is the reason I adore Slim so much. In the PHP world, it gives me exactly what I require in a framework, and nothing else. Slapping it on top of a well-defined class heirachy becomes a simple exercise. I like it so much, that I'm porting it to Hack/HHVM[0]!
Symfony is awesome but I feel they try to stuff too much into the default framework configuration. I don't want all those silly annotations, for example.
Django actually seems to be one of the least offensive frameworks to me in that respect. It didn't really try to be clever and it did things that made sense with a minimal amount of magic.
Great point. That's probably the worst case, IMO, along with over-engineering and plain spaghetti. I should have mentioned it, but I think my PTSD from dealing with such engineers and projects is still overwhelming.
One of the more simple litmus tests I use when evaluating a framework: Does it provide (and require you use) its own versions of data types already provided by the language (or the language's standard libraries)? If so, it's a big red flag. Not necessarily a reason to disqualify, but definitely cause to apply extra scrutiny.
The thought process is: If I have to spend precious development time converting all my std::strings to and from YourStrings, then I can bet that there is plenty more un-necessary cleverness and complexity waiting to bite me once your framework gets its claws into my code.
There are many reasons not to use std::string, some of them more valid than others.
Judging a C++ framework by whether it implements its own string type probably isn't a good idea. C++ is inherently limited, and a string type is often the only way to have certain design guarantees. In a performance-critical context, it's sometimes crucial to control the exact pattern of allocation. And not just how they're allocated in memory, but also how often they're allocated. You can control std::string's pattern of allocation by using a custom allocator, but you can't control how often std::strings are created, for example, because std::string implements an interface which is guaranteed to construct temporary strings. This normally isn't a problem, but in contexts where every millisecond is crucial (like gaming) this can be disastrous, since it's very hard to optimize the performance characteristics of std::string once it becomes pervasively used throughout your codebase.
Another reason to make your own string type is for proper unicode support. Maybe C++11 or C++14 added features to help with that, so maybe this is less valid nowadays. I haven't kept up.
>One of the more simple litmus tests I use when evaluating a framework: Does it provide (and require you use) its own versions of data types already provided by the language (or the language's standard libraries)?
Just wondering (as someone who only uses/touches Python indirectly, through some projects that use it, but is not currently a 'Python developer' by any means); was this posted in response to some recent drama in the Django community, or as an argument against Lisp?
I'm just wondering why it seems this story is quickly getting upvoted on the front page of HN, when it seems there are no other frontpage stories remotely related to Django, Reddit, or Lisp?
> when it seems there are no other frontpage stories remotely related to Django, Reddit, or Lisp
That may be true about Django, but not the other two.
Reddit being a YC-backed company, it always has been a hot topic here on HN. Maybe less now than a few years back but the same HNers are still here.
And as for Lisp, it has always been a hot topic on HN too. Many people know HN via PG who they discovered for his Lisp writings. HN is itself written in a Lisp dialect. And Lisp related stories appear monthly on the frontpage, maybe weekly if we take all Scheme and Emacs related links into account. Just take a look at the search results for the past week with any Lisp related keyword.
> "It means readable HTML with the proper HTTP headers."
said all the other frameworks's authors a few months before him that are now churning out deprecated headers just like that one will in a couple months, while gallantly trying to protect the user from handling headers.
It should be noted that Django has since fixed that issue.