Real programmers don't use frameworks(vertonghen.wordpress.com)
vertonghen.wordpress.com
Real programmers don't use frameworks
http://vertonghen.wordpress.com/2008/08/29/real-programmers-dont-use-frameworks/
49 comments
Frameworks are not simply libraries and I think that's one of the more valid criticisms of frameworks. Frameworks call you. You don't just call them as you would call any other library function. That means they provide the glue code, not you. They structure the application, not you.
The difference between libraries and frameworks isn't allways clear cut, but try to combine multiple frameworks in one application and you'll quickly see what I mean. Frameworks create a lot of dependencies. In a way that is what makes them useful, because a dependency is a decision you don't have to make.
The general principle is this: Frameworks make you work if you want to diverge from the defaults. Apps combining multiple libraries make you work to define the defaults. Which one causes more work depends on how unique your application is. If you're a consultant who creates one middle of the road app every three months, frameworks are perfect for you. If you are a startup founder with some confidence in the future and uniqueness of your app, frameworks may not be the best choice.
The difference between libraries and frameworks isn't allways clear cut, but try to combine multiple frameworks in one application and you'll quickly see what I mean. Frameworks create a lot of dependencies. In a way that is what makes them useful, because a dependency is a decision you don't have to make.
The general principle is this: Frameworks make you work if you want to diverge from the defaults. Apps combining multiple libraries make you work to define the defaults. Which one causes more work depends on how unique your application is. If you're a consultant who creates one middle of the road app every three months, frameworks are perfect for you. If you are a startup founder with some confidence in the future and uniqueness of your app, frameworks may not be the best choice.
Another utterly vacuous post knocking frameworks to whore some traffic.
I kept waiting for this guy to argue for something. Is he proposing that we all use Java servlets? .NET? Drupal? Joomla? Ning? Raw PHP? Old-school hand-rolled Perl? Old-school hand-rolled C? Haskell? Erlang? Arc?
But: nothing. I'm supposed to accept that Rails, Django, Merb et al are hopelessly non-scalable, unstable, FUD-worthy Visual Basic technologies and switch to... nothing.
It's a mystery. I skimmed the guy's CV: Lots of impressive-sounding entreprenurial stuff, no technical details that I could find. (I didn't read too closely... the CV is wordy.) I skimmed his "Software" blog entries. A complaint about .NET, a mention of a Perl users group, some praise of Erlang. But nothing clear. Why do I have to solve this guy's advice like a puzzle? He should tell me what the hell he's talking about so that I know whether or not I should laugh, and how loudly!
But: nothing. I'm supposed to accept that Rails, Django, Merb et al are hopelessly non-scalable, unstable, FUD-worthy Visual Basic technologies and switch to... nothing.
It's a mystery. I skimmed the guy's CV: Lots of impressive-sounding entreprenurial stuff, no technical details that I could find. (I didn't read too closely... the CV is wordy.) I skimmed his "Software" blog entries. A complaint about .NET, a mention of a Perl users group, some praise of Erlang. But nothing clear. Why do I have to solve this guy's advice like a puzzle? He should tell me what the hell he's talking about so that I know whether or not I should laugh, and how loudly!
Real men don't need frameworks or high level languages. Real men write 1's and 0's.
This article is absurd. Maybe some frameworks do suck. Maybe some frameworks are not the correct solution to certain problems. The whole point of frameworks is that they offer higher level abstractions and you would decide to use them the same way you might decide to use a higher level language.
Real programmers use the right tools for the job. They don't make stupid blanket statements like this one.
This article is absurd. Maybe some frameworks do suck. Maybe some frameworks are not the correct solution to certain problems. The whole point of frameworks is that they offer higher level abstractions and you would decide to use them the same way you might decide to use a higher level language.
Real programmers use the right tools for the job. They don't make stupid blanket statements like this one.
Why do I have to solve this guy's advice like a puzzle?
Maybe because he blogs like he codes.
Maybe because he blogs like he codes.
Frameworks were invented to lower the barriers of entry to programming
Bullshit. Modern frameworks like Django and Rails were extracted from real-life projects written from scratch by real programmers to let the real programmers re-use common web-development code and make it faster and more stable with time.
When you use the framework you still can dive in pure Python/Ruby or even custom C/assembly extensions to optimize your bottlenecks if you really need.
Bullshit. Modern frameworks like Django and Rails were extracted from real-life projects written from scratch by real programmers to let the real programmers re-use common web-development code and make it faster and more stable with time.
When you use the framework you still can dive in pure Python/Ruby or even custom C/assembly extensions to optimize your bottlenecks if you really need.
Frameworks are about creating reusable, stable code that simplifies development. I would say this is exactly the type of thing that "real programmers" strive to create.
The author does mention that frameworks may be the "best choice for rapidly prototyping your startup." This is certainly true, but the model of rapidly iterating gets cut down when you create your 1.0 with a framework, begin getting customers, then pause for a 4 month rewrite for the sole purpose of eliminating a framework.
If it's necessary to eliminate the framework in order to optimize (I don't believe it is), let it work itself out over time and many evolutions of the product. Don't aim to start your project without one.
The author does mention that frameworks may be the "best choice for rapidly prototyping your startup." This is certainly true, but the model of rapidly iterating gets cut down when you create your 1.0 with a framework, begin getting customers, then pause for a 4 month rewrite for the sole purpose of eliminating a framework.
If it's necessary to eliminate the framework in order to optimize (I don't believe it is), let it work itself out over time and many evolutions of the product. Don't aim to start your project without one.
Django is fast as hell. Check out the benchmarks. The reality is that with performance and bandwidth getting cheaper, frameworks for the web look like a better choice every day.
Someone buy that guy one of these:
http://pics.bestpicever.com/pics/pic_12174328608285.jpg
http://pics.bestpicever.com/pics/pic_12174328608285.jpg
Real programmers understand the value of abstraction. End of discussion.
Frameworks are not equivalent to abstractions. Frameworks are prepackaged abstractions - that is, a proper subset of all abstractions. If you can make better abstractions than those used by a framework, you might advocate not using that framework because you understand the value of (good) abstraction.
And the "realest" programmers even understand that there are different kinds of abstractions and that abstraction is both a noun and a verb for good reason. We shouldn't just think about what a framework provides today, but also how it structures the way we evolve our applications, i.e our own abstraction process.
Real programmers ship.
This is statement has one of the highest value:word rations about programmers that I've seen in a while.
I'd adjust it only slightly to be:
Real Programmers Release.
Because, we don't really "ship" software anymore like we used to. We just put it out there. But regardless, well said.
I'd adjust it only slightly to be:
Real Programmers Release.
Because, we don't really "ship" software anymore like we used to. We just put it out there. But regardless, well said.
Yeah, and real programmers don't use weblogging software like WordPress.
Wordpress makes sense for the same reasons (good) frameworks make sense: somebody's already written the code to provide blogging/publishing functionality, and they're experts at it. Plus, it is extensible w/ plugins and has numerous options for themes.
If the site needs something that's not part of the Wordpress core and there's no plugin, write some PHP and make it.
Granted, it's not quite as hardcore and writing a custom app, but why reinvent the wheel?
If the site needs something that's not part of the Wordpress core and there's no plugin, write some PHP and make it.
Granted, it's not quite as hardcore and writing a custom app, but why reinvent the wheel?
I kinda see the point, especially as someone who's used RoR quite heavily and is currently developing code with Django.
It's ultimately a tradeoff between rapid and optimised development. Both have their advantages and disadvantages.
The project I'm developing in Django would never have more than 100 concurrent users so for me, that's fine. The framework approach and lack of need to optimise gives me an advantage I otherwise wouldn't have.
I wouldn't use Django (or RoR) if I had 10s of thousands of concurrent users, not because it can't scale, but because the effort required from me in terms of optimisation starts to outweigh the benefits gained from the framework at that point.
It's ultimately a tradeoff between rapid and optimised development. Both have their advantages and disadvantages.
The project I'm developing in Django would never have more than 100 concurrent users so for me, that's fine. The framework approach and lack of need to optimise gives me an advantage I otherwise wouldn't have.
I wouldn't use Django (or RoR) if I had 10s of thousands of concurrent users, not because it can't scale, but because the effort required from me in terms of optimisation starts to outweigh the benefits gained from the framework at that point.
Let me tell you a little secret. I convinced a large website to switch new development into Django and then we were able to do an entire site rewrite a few months later.
The site gets a ton of concurrent users. The framework provides some caching mechanisms at multiple levels that makes handing that very easy.
The site gets a ton of concurrent users. The framework provides some caching mechanisms at multiple levels that makes handing that very easy.
Ah, another cock-stroking "Real programmer" post.
Real programmers don't write about real programmers. Real programmers write code and get on with their fucking lives.
Real programmers don't write about real programmers. Real programmers write code and get on with their fucking lives.
Amen.
Duh, real programmers program in binary, right?
Real programmers patch in code with toggle switches. In octal. With their eyes closed. On quaaludes. Up-hill, both ways.
Or maybe good developers (as opposed to real programmers) have the ability to look beyond machismo crap.
Look at us, all feeding this stupid troll.
Or maybe good developers (as opposed to real programmers) have the ability to look beyond machismo crap.
Look at us, all feeding this stupid troll.
Ones and zeroes? What a luxury!
Back in MY day we used percussive maintenance. Since computers were either analog systems with rods and wires or new-fangled vacuum tube jobbies, you could debug them with a sharp knock on the right part of the hardware. That would shake the carbonization right off the contacts and you'd be back in business.
The other day I went diving, and the dive mater was showing off his new dive computer. Instead of buttons (which are prone to leaking and hard to press with bulky gloves on), it had an inertial UI: you tapped the sides to control its functions.
Made my day to see us rediscovering the virtues of banging on stuff to make it work.
Back in MY day we used percussive maintenance. Since computers were either analog systems with rods and wires or new-fangled vacuum tube jobbies, you could debug them with a sharp knock on the right part of the hardware. That would shake the carbonization right off the contacts and you'd be back in business.
The other day I went diving, and the dive mater was showing off his new dive computer. Instead of buttons (which are prone to leaking and hard to press with bulky gloves on), it had an inertial UI: you tapped the sides to control its functions.
Made my day to see us rediscovering the virtues of banging on stuff to make it work.
Where's the downmod button when you need it?
Just upmod everything else.
Funny, but that would be a horrible way of downmodding.
The commenter is cluelesss. Any substantial project either has certain patterns embodied as part of a library or has such code that's repeated cut & paste style and has such a library begging to be factored out of it.
Also, programmer cycles are going to be a lot more valuable than computer cycles in the very beginning, and whenever you have a competitor. If you are not well factored and you can't develop rapidly, you will eventually pay. Bad code is a debt! This isn't just a slogan. I've seen it in person again and again.
Also, programmer cycles are going to be a lot more valuable than computer cycles in the very beginning, and whenever you have a competitor. If you are not well factored and you can't develop rapidly, you will eventually pay. Bad code is a debt! This isn't just a slogan. I've seen it in person again and again.
I understand that there are tradeoffs when you choose to build on a framework. I've written many applications from scratch (without frameworks) then I've written custom frameworks and CMSs for various projects and now I'm looking at existing frameworks as a way to bring in quality code, with features that I would be implementing by hand otherwise.
I've been impressed with CodeIgniter and now I'm working with Kohana because it's still fast, fairly low level and if I want to use the higher level stuff for prototyping I can and then I can refactor down to lower levels easily for performance later on when it's necessary.
There are things that I'd consider to be frameworkish components being built into PHP. For example the filter extension is something where prior to it's inception I had this functionality built into my framework. You could say it's a framework for filtering input.
When you use frameworks that have to use all of the frameworks 'magic' you do get a performance hit. It will almost always be faster to implement your own SQL statements instead of relying on an active record library, especially with complex logic.
You need to balance what you're trying to do with what you're options are. If you're writing a personal app that only you are using and you want it out as soon as possible then some of these frameworks like Ruby on Rails or Symfony would be great. Something to get the code out so you can start using it. If you are really concerned with performance then use something like the Zend Framework where you can reimplement parts for performance and do all your queries by hand.
I've been impressed with CodeIgniter and now I'm working with Kohana because it's still fast, fairly low level and if I want to use the higher level stuff for prototyping I can and then I can refactor down to lower levels easily for performance later on when it's necessary.
There are things that I'd consider to be frameworkish components being built into PHP. For example the filter extension is something where prior to it's inception I had this functionality built into my framework. You could say it's a framework for filtering input.
When you use frameworks that have to use all of the frameworks 'magic' you do get a performance hit. It will almost always be faster to implement your own SQL statements instead of relying on an active record library, especially with complex logic.
You need to balance what you're trying to do with what you're options are. If you're writing a personal app that only you are using and you want it out as soon as possible then some of these frameworks like Ruby on Rails or Symfony would be great. Something to get the code out so you can start using it. If you are really concerned with performance then use something like the Zend Framework where you can reimplement parts for performance and do all your queries by hand.
There is something to this argument depending on the application you are writing. Abstractions are good, but higher abstractions mean slower performance. For some applications, some frameworks may not offer significant performance degradation - but for others, it does. So, first question is - what % performance increase can you expect by removing frameworks and hardcoding things? If you can get a 10% performance boost, then that seems to imply 10% more requests per server and a reduction in overall operating costs -> increase in profit. MMMM profit...
The next question is, how good are you and your team at the root language? One poster scoffs at servlets, but I've been coding in java for over 10 years and doing work on servlets for several years now with no other web frameworks and there is not much barrier to entry there other than the annoyance of writing stuff by hand. It depends on how stable the features on your application are as well as your skill. If you are still rapidly iterating over different options, then working without a framework may be premature optimization. If your feature set is stable then maybe it makes sense to remove the framework before you go live to a slashdot article?
The next question is, how good are you and your team at the root language? One poster scoffs at servlets, but I've been coding in java for over 10 years and doing work on servlets for several years now with no other web frameworks and there is not much barrier to entry there other than the annoyance of writing stuff by hand. It depends on how stable the features on your application are as well as your skill. If you are still rapidly iterating over different options, then working without a framework may be premature optimization. If your feature set is stable then maybe it makes sense to remove the framework before you go live to a slashdot article?
To me this seems a bit like a deliberate link/traffic bait.
He seems to argue that you can build a more robust application from the ground up. In my limited experience it's the hand rolled applications that are and out hand and unstable. A major advantage of a good framework is that it does force you to stick to it's conventions which typically follow best practices.
As for the barrier of entry I found that learning a framework is like learning a new programming language to a certain extent and to really take full advantage of the framework you need to know the underlying language as well. It seems the barrier of entry is actually raised by frameworks.
As for the barrier of entry I found that learning a framework is like learning a new programming language to a certain extent and to really take full advantage of the framework you need to know the underlying language as well. It seems the barrier of entry is actually raised by frameworks.
If you are lucky enough to have performance issues with a framework, just add more web hosts. Your bottleneck is most likely going to be the database. It wouldn't even matter if your framework was a fraction as fast as it is now, just make is service less requests.
Ending with a positive note - this misconception is a easy way to screen new employees.
Ending with a positive note - this misconception is a easy way to screen new employees.
Real programmers also don't use libraries. Hell, they don't even use subroutines unless they absolutely have to!
"After all, frameworks, as we know them now, are just a few years old and the web is about 15 years old."
I stopped reading there. I know he means mvc web frameworks but I'm not sure if he knows that their exist others. Why is this bullshit on place 2?
I stopped reading there. I know he means mvc web frameworks but I'm not sure if he knows that their exist others. Why is this bullshit on place 2?
Real experts don't use linkbait.
It's fine to use a framework, just make sure that ideally it's a framework you wrote yourself.
The worrying thing is programmers who learn a 'framework' instead of the language - eg prototype instead of javascript.
The worrying thing is programmers who learn a 'framework' instead of the language - eg prototype instead of javascript.
Real men don't cry.
Don't forget that every programming language is a framework itself. There maybe good ones and bad ones, simple ones, useless ones, some may fit or not fit in your context.
All I can say is this guy is an idiot that likes to waste his time.
Real programmers only program in hexdecimal.
SMART programmers do use frameworks!
Ever heard of libraries, people?
[deleted]
How is this guy on the front page of HN???? I hope this isn't turning proggit :(
real programmers code in assembly and debug in opcode
[deleted](1)
Real programmers create powerful software.
The "how" is meaningless.
The "how" is meaningless.
Steve Yegge had the best story in this regard. His old company built mobile software in assembly. The app was huge - like several million lines of code - but they were convinced it must be fast, because it was in assembly. But then Microsoft came out with a competitor, written in a higher-level language, that was way faster. Why? The assembly app was full of inefficiencies that they couldn't see because they were working at such a low level.
Frameworks aren't about "lowering the barriers of entry to programming". They're about allowing a developer to focus on what's new and original and important, and not worry about things that have already been solved a thousand times. They're just libraries! Why rewrite an email sending library or a unit testing library or a database connection library for every app? Or deployment automation, or ORM, or web request handling, etc. Arrange a few of these and you've got a framework.
If your framework isn't responsive, stable, and simple, then you need a different framework, not no framework.