Real programmers don't use frameworks
vertonghen.wordpress.com
vertonghen.wordpress.com
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.
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.
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!
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.
Maybe because he blogs like he codes.
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.
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.
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.
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?
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.
The site gets a ton of concurrent users. The framework provides some caching mechanisms at multiple levels that makes handing that very easy.
Real programmers don't write about real programmers. Real programmers write code and get on with their fucking lives.
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.
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.
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'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.
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?
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.
Ending with a positive note - this misconception is a easy way to screen new employees.
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?
The worrying thing is programmers who learn a 'framework' instead of the language - eg prototype instead of javascript.
The "how" is meaningless.