Real programmers don't use frameworks

Sounds to me like "Real programmers don't use a high-level language" or "Real programmers use Assembly".<p>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.<p>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.<p>If your framework isn't responsive, stable, and simple, then you need a different framework, not no framework.

Another utterly vacuous post knocking frameworks to whore some traffic.

<i>Frameworks were invented to lower the barriers of entry to programming</i><p>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.<p>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.<p>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.<p>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:<p><a href="http://pics.bestpicever.com/pics/pic_12174328608285.jpg" rel="nofollow">http://pics.bestpicever.com/pics/pic_12174328608285.jpg</a>

Real programmers understand the value of abstraction. End of discussion.

Real programmers ship.

Yeah, and real programmers don't use weblogging software like WordPress.

I kinda see the point, especially as someone who's used RoR quite heavily and is currently developing code with Django.<p>It's ultimately a tradeoff between rapid and optimised development. Both have their advantages and disadvantages.<p>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.<p>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.

Ah, another cock-stroking "Real programmer" post.<p>Real programmers don't write about real programmers. Real programmers write code and get on with their fucking lives.

Duh, real programmers program in binary, right?

Where's the downmod button when you need it?

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 &#38; paste style and has such a library begging to be factored out of it.<p>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.<p>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.<p>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.<p>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.<p>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 -&#62; increase in profit. MMMM profit...<p>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?

Obligatory: <a href="http://www.pbm.com/~lindahl/real.programmers.html" rel="nofollow">http://www.pbm.com/~lindahl/real.programmers.html</a>

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.<p>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.<p>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."<p>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.<p>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?

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

Real programmers create powerful software.<p>The "how" is meaningless.