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

Lessons learned defying Joel Spolsky with Django

speakerdeck.com

Post reply on HN
Print view View original

71–80 of 155 posts

Re: Lessons learned defying Joel Spolsky with Django

#71

Post by macspoofing »

jroseattle wrote: post #35

I was expecting this slidedeck to be a bit more focused on defying Spolsky, and whether or not that was a good decision. FWIW, I've never bought into Spolsky's vision that re-writing code is poor strategy. Steve Jobs never thought twice about ripping something apart and starting over. If anything, code re-write can be an advantageous position -- you often have a greater understanding of the problems you're intending…

>I've never bought into Spolsky's vision that re-writing code is poor strategy.

I think it's something that's true in general but false in some specific cases. Rewriting involves spending enormous time and resources to at best standstill, and at worst move backwards ( chances are your re-written product will be poorer in features, and initially buggier than your old, stable, battle-tested version). For smaller companies, it is a death knell.

Re: Lessons learned defying Joel Spolsky with Django

#74

Post by macspoofing »

zzzeek wrote: post #4

Don't use just one ORM and then declare "ORM's are stupid". The "object = None" / "object_id = None" issue illustrated here is certainly not a mistake every ORM makes.

True, but every ORM will make that kind of mistake. You can't just build an object model without paying attention to the SQL layer.

Re: Lessons learned defying Joel Spolsky with Django

#75

Post by jokull »

pyriku wrote: post #26
nnq wrote: post #6

Bumping into ORM limitations + moving to Jinja for templates --> one word: Flask ...really, what advantage does Django provide at this point in this project anymore?

Middlewares, context processors, forms, (class based) views, and tons of third party applications. The CTO of a startup where some friends are working thought the same you did, and 2 years ago rewrote everything to Flask. Now they're going back to Django. Django is much more that an ORM and templates.

Django middlewares is a poorly designed system. Flask has all of the things you mentioned except for forms. For that you can use Flask-WTF, but these libraries are becoming outdated anyway because they’re HTML based and don’t work so well for JSON validation.

Re: Lessons learned defying Joel Spolsky with Django

#76

Post by pbz »

mythz wrote: post #8
InclinedPlane wrote: post #5

Earlier quoted context omitted.

Do you have an example of an ORM which is not in some fundamental way "stupid"? I haven't found one yet, but I'd love to know one existed somewhere.

There are several Micro ORMs for .NET: http://www.servicestack.net/benchmarks/#dapper-benchmarks That don't try to handle hidden-magic-state and lets you easily access via Raw SQL if you need to do complex queries. Many don't try to abstract anything and are simply extension methods over the underlying IDbConnection (so you never lose any flexibility), i.e. they simply exist to remove the tedium boilerplate of mappin…

And if you want to take it to the "next step" and not rely on strings, having everything compiled and checked by the compiler, while staying low level: http://bltoolkit.net/ or https://github.com/linq2db/linq2db

Re: Lessons learned defying Joel Spolsky with Django

#77

Post by macspoofing »

PommeDeTerre wrote: post #32
Aqueous wrote: post #15

Earlier quoted context omitted.

Why not just write the SQL?

When ORMs first started becoming popular during the 2000s, especially within the Java world, their proponents drummed up a lot of animosity toward SQL. While a lot of us who had started working with SQL in the 1980s, if not earlier, were perfectly fine with using it, many younger developers were scared away from it by these claims. So we've had a generation of software developers who were essentially raised to hate S…

I disagree. There's a lot of boilerplate ontop of raw SQL that can and should be abstracted away. At some point you'll have to parse out result and build an object graph anyway, it would be nice if it was done for you already. You can also plug-in things like a caching engine easily and transparently.

Most ORM systems will give you options. My experience was with Hibernate, which had let you do Object queries, Criteria queries, HQL queries, and finally raw SQL. You hardly ever needed to go down to raw SQL. It's nice not to worry about the particulars of the underlying SQL engine, and certainly you want serialization to be handled for you.

The OP is right though, you can't treat ORM framework as a total blackbox. You need to be aware of what it's doing else you can really get yourself in trouble.

Re: Lessons learned defying Joel Spolsky with Django

#78

Post by antihero »

nnq wrote: post #6

Bumping into ORM limitations + moving to Jinja for templates --> one word: Flask ...really, what advantage does Django provide at this point in this project anymore?

It has an entire ecosystem and tool chain to sort building websites/webapps. When I used to use Flask, before moving to Django, I found myself essentially creating a whole bunch of stuff that Django already has, and is better written.

Re: Lessons learned defying Joel Spolsky with Django

#79

Post by jokull »

Alex3917 wrote: post #30
nnq wrote: post #6

Bumping into ORM limitations + moving to Jinja for templates --> one word: Flask ...really, what advantage does Django provide at this point in this project anymore?

"what advantage does Django provide at this point in this project anymore?" Documentation. I use Django but without any ORM and with Jinja2, so it's basically just Flask but with more stack overflow threads and more third-party software. Is there any actual advantage that I would be getting by using Flask instead?

Flask’s documentation is great, and the codebase is readable and small. The third party community is not as big as Django’s, but the 3rd party work is verified and approved by Armin (Flask and Jinja2 author). These guidelines encourage authors to publish higher quality code and better documentation. You couldn’t verify my claims, but this is my experience coming from Django a couple of years back. Django’s extensions are often very poor quality.

I’d also like to point out that Flask-Admin has come a long way with adapters for SQLAlchemy and at least one other ORM library. Very usable and extendible.

Re: Lessons learned defying Joel Spolsky with Django

#80

Post by antihero »

Aqueous wrote: post #15
zzzeek wrote: post #4

Don't use just one ORM and then declare "ORM's are stupid". The "object = None" / "object_id = None" issue illustrated here is certainly not a mistake every ORM makes.

Why not just write the SQL?

Because you end up writing the same basic SQL over and over and over again?
Post reply on HN