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).
>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.
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.
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.
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.
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.
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.
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.
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.
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 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)?
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 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.
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.
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.
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.
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
> "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.
" Another concluded: “some vc suit wants a maintainable-by-joe-programmer product. I hope he pays you millions.”"
so this guy is implying that we should be choosing our programming languages based on how hard and expensive it will be to get other dev's to work on it?
that is the most economically unsound and elitist thing i've heard recently.
>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'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?
117 comments
[ 3.5 ms ] story [ 241 ms ] threadLikely consumed by meta-patterns, like every other project who's primary reason to exist is to be a LISP clone of something.
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).
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.
Is the project really dead though? I have no personal experience, but these stats show a growing number of active users: http://pods.jasonrobinson.me/
I believe pg stated that HN was supposed to be what reddit was originally.
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?
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.
Wow.
What drama?
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.
Flask definitely fills that role for me. It's very simple to get up and going with it, and deploys easily.
The current github page is here: https://github.com/webpy/webpy
If you are looking to get up and running quickly, I would recommend forking this skeleton: https://github.com/jzellman/webpy-skeleton
Finally, the built in database framework is a bit simplistic. I like to pair this with Peewee (included in the webpy-skeleton).
The router block at the top plus:
Looks really nice. Haven't tried serving or rendering templates from it, so never tested that code.It should be noted that Django has since fixed that issue.
Edit: Found it. It was the 14th post on our blog a time, but definitely light on the implementation details. http://www.redditblog.com/2005/12/on-lisp.html
Also just as anemic as the last one. Oh well.
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.
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.
http://webpy.org/
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.
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.
>Enabling the cached template loader often improves performance drastically, as it avoids compiling each template every time it needs to be rendered.
[1] https://docs.djangoproject.com/en/dev/ref/templates/api/#dja...
Pretty sure flask is currently the front runner in "python microframeworks".
Generally refers to "how many people can continue to develop/support this software if original maintainer (and close co-developers) get hit by a bus."
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.
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.
[0] http://github.com/LeanFramework/Lean
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.
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.
That's a pretty low bar...
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.
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)
I also know http://www.cars.com/ is heavily powered by Pyramid.
Django doesn't need the magic, it's just annoyingly presented that way.
Selective memory I guess.
If you're using Clojure, ring + tomcat, etc...
Clack (https://github.com/fukamachi/clack)
A single-file web application in Django: https://github.com/mstepniowski/microdjango/blob/master/poll...
Django has definitely come a long way!
That still looks very complicated compared to most microframeworks I've used, including web.py.
And all that django-specific logic that needs to be in there makes it harder to read unless you're familiar with the django ecosystem.
What "django-specific" logic? Those are standard imports and a few helper objects, the kind of which you'll find in any web framework.
[edit: importants => imports]
All these things, when compared to a true microframework, contribute in legibility of the code.
Until they are. Then you go ahead and implement an ad-hoc settings scheme.
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.
RIP aaronsw.
http://www.pyvideo.org/video/234/pycon-2009--keynote--reddit...
25m 40s
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.
so this guy is implying that we should be choosing our programming languages based on how hard and expensive it will be to get other dev's to work on it?
that is the most economically unsound and elitist thing i've heard recently.
That must have ended as a huge success, because as we all know the important thing behind a website is the backend language...