Why I Hate Frameworks(discuss.joelonsoftware.com)
discuss.joelonsoftware.com
Why I Hate Frameworks
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12
126 comments
http://web.archive.org/web/20180924092925/http://discuss.joe...
An oldie (2005) but goodie.
Although it is less about frameworks and more about a disease which was largely contained to Java enterprise-y architecture stuff. (I say as a practitioner in that field... remind me why we are using the Factory pattern here, again?)
Although it is less about frameworks and more about a disease which was largely contained to Java enterprise-y architecture stuff. (I say as a practitioner in that field... remind me why we are using the Factory pattern here, again?)
It made its way into the .NET space also many years ago. Working on a pretty big application now with a big team. We have two sets of Factories, with interfaces between them so that nobody ever sees an actual class. Egads!
> remind me why we are using the Factory pattern here, again?
Because everything in J2EE, including design patterns, is driven by salivating greed, megalomania-level egos and lemming mentality (I have a similar comment in the original thread).
Because everything in J2EE, including design patterns, is driven by salivating greed, megalomania-level egos and lemming mentality (I have a similar comment in the original thread).
In fairness, the Factory pattern is useful when you want to unit test classes with mocks. In dynamic languages, this is easy, but more static languages require jumping through hoops.
Alternately, you could use something like Google Guice, but that's (sorta) a factory-factory.
Basically, no one likes the situation, but they've chosen their tradeoffs, which they see as the lesser of N evils.
Alternately, you could use something like Google Guice, but that's (sorta) a factory-factory.
Basically, no one likes the situation, but they've chosen their tradeoffs, which they see as the lesser of N evils.
Rails: Here's a kick-ass hammer, a kick-ass saw, a kick-ass measure tape, etc...
Oh, and if you need them to be different from the default, you can modify them as you want, but we think the default works for most people.
Oh, and if you need them to be different from the default, you can modify them as you want, but we think the default works for most people.
But don't bother checking for the spring mechanism that retracts the measure tape in case it breaks or the power supply connection point on the saw if it stops working.
Those bits just magically work!
:)
Those bits just magically work!
:)
There must be hole in the spring mechanism testing procedure
They don't magically work. You'll understand the mechanism when you know a bit more about how to build a measure tape and a saw. Also, all the so-called magic is extensively and automatically tested, and so an order of magnitude more reliable than your own custom-rolled spring mechanisms.
Exactly. This is why the article is such a bad analogy - frameworks makes things simpler by handling things you'd already do without them.
If you're making a spice rack:
Without framework: DIY shed filled with tools
Framework: IKEA
If you're making a spice rack:
Without framework: DIY shed filled with tools
Framework: IKEA
Well, not quite... that's a bad analogy too, actually... Rails isn't IKEA - and most java frameworks are definitely not IKEA.
Frameworks are tools, not end products.
Frameworks are tools, not end products.
Have you tried assembling an Ikea flat-pack?
Many times, and I can't for the life of me understand why anyone would struggle at it.
IKEA provides flat-packed products. You never buy a wardrobe at IKEA and then turn it into a couch instead. It will always be a wardrobe, and nothing else.
On the other hand, if you buy a set of tools and environment (aka framework) to build furniture, you can use it to build whatever furniture you want/can.
IKEA provides flat-packed products. You never buy a wardrobe at IKEA and then turn it into a couch instead. It will always be a wardrobe, and nothing else.
On the other hand, if you buy a set of tools and environment (aka framework) to build furniture, you can use it to build whatever furniture you want/can.
Things from IKEA are not end products. However all the cutting, planing, and much of the other work has already been done, in the same way that the method of talking to the database and the webserver have been done in the framework.
Things from IKEA are flat-packed end-products.
End products are finished. If something requires assembly, it is not an end product.
I think the issue is, a spice rack from IKEA may work, but it's not going to look great, or last long.
Any flat pack spice rack, will be shoddy quality, and probably break.
You don't get good furniture by mass producing it like that. Same with software.
What if I want a custom spice rack, with some secret compartment, in solid oak.
Any flat pack spice rack, will be shoddy quality, and probably break.
You don't get good furniture by mass producing it like that. Same with software.
What if I want a custom spice rack, with some secret compartment, in solid oak.
The idea that using well tested, widely spread open source software is somehow less reliable than writing your own is the kind of baseless FUD I wouldn't expect from you, axod.
Next, you'll be suggesting that people write their own web server instead of using Apache? Or perhaps they can trust other people's code so long as they pay for it, so you'll send them towards IIS?
Come on, now.
Next, you'll be suggesting that people write their own web server instead of using Apache? Or perhaps they can trust other people's code so long as they pay for it, so you'll send them towards IIS?
Come on, now.
"Next, you'll be suggesting that people write their own web server instead of using Apache?"
If the webserver is a key component in your success, then definitely. Write a webserver. It was for me, which is why I wrote my own (After I found others lacking).
If it really matters, and the existing stuff isn't good enough for your use-case, write it yourself.
If the webserver is a key component in your success, then definitely. Write a webserver. It was for me, which is why I wrote my own (After I found others lacking).
If it really matters, and the existing stuff isn't good enough for your use-case, write it yourself.
That's a bad example to bring up, considering how Apache httpd is such a massive pile of shit.
If Rails were a toolbox, all of its tools would break under duress. Regarding Ruby:
"And furthermore, for me, programming languages and their runtimes are tools. I think they are for a lot of us. You wouldn’t continue to use a hammer whose head keeps flying off when you take a swift backswing, would you?"
Good read: http://cbcg.net/2007/04/22/python-up-ruby-down-if-that-runti...
"And furthermore, for me, programming languages and their runtimes are tools. I think they are for a lot of us. You wouldn’t continue to use a hammer whose head keeps flying off when you take a swift backswing, would you?"
Good read: http://cbcg.net/2007/04/22/python-up-ruby-down-if-that-runti...
He also goes on to say:
I am discounting Rails here: I think Rails is great for what it is and I’ve had nothing but good experiences with it precisely because it is so “opinionated”. Its a very productive environment and manages to successfully avoid the runtime problems that I’ve personally hit in the past.
So... are you trying to make a point about Ruby or about Rails? Dare I give out the clichéd "Rails != Ruby" response here?
I am discounting Rails here: I think Rails is great for what it is and I’ve had nothing but good experiences with it precisely because it is so “opinionated”. Its a very productive environment and manages to successfully avoid the runtime problems that I’ve personally hit in the past.
So... are you trying to make a point about Ruby or about Rails? Dare I give out the clichéd "Rails != Ruby" response here?
No, that mistake typically is a result of somebody faulting Ruby for Rails' problems. As the parent to my comment said,
Rails: Here's a kick-ass hammer, a kick-ass saw, a kick-ass measure tape, etc...
My point is that those kick-ass tools may be made of balsa. The editorial that I linked immediately came to mind because it too used tools as an analogy.
Rails: Here's a kick-ass hammer, a kick-ass saw, a kick-ass measure tape, etc...
My point is that those kick-ass tools may be made of balsa. The editorial that I linked immediately came to mind because it too used tools as an analogy.
http://rubyonrails.com/applications says you're wrong.
About?
Suggesting that rails is a kick-ass tool made of balsa.
Not "is a," but rather, "may be." This is because I never personally experienced the problems noted in the link I posted, but they are coming from what appears to be a credible source. You mistook a suggestion of problems for a personal conviction.
> If Rails were a toolbox, all of its tools would break under duress.
That sure sounds like personal conviction to me.
That sure sounds like personal conviction to me.
I'm starting to see why a lot of people say all software development analogies suck. What does it mean to say its tools would break under duress, or they're made of balsa wood? You can interpret those analogies any way you want.
The bottom line is the Ruby runtime has some serious flaws, but they are not so pervasive as to make everything in Ruby total crap. There's a good chance you could write an application in half the time it would take in Java and experience no problems ever. It's also possible you'll hit a memory leak and have to face an ugly workaround, partial rewrite or even scrap the whole Ruby project. Finally, you may have a memory leak and find an easy workaround, and then one day the problem is magically solved by Rubinius.
Those are concrete scenarios to consider. I don't see how a physical materials analogy has any value in analyzing your options. The pros and cons of languages don't align AT ALL with physical properties. Thoughts like, "Java is more like cast iron, and Python is more like hardwood" is just one-dimensional mental masturbation. In the end the reason to choose a language like Java because you are willing to tolerate more overhead for less risk.
The bottom line is the Ruby runtime has some serious flaws, but they are not so pervasive as to make everything in Ruby total crap. There's a good chance you could write an application in half the time it would take in Java and experience no problems ever. It's also possible you'll hit a memory leak and have to face an ugly workaround, partial rewrite or even scrap the whole Ruby project. Finally, you may have a memory leak and find an easy workaround, and then one day the problem is magically solved by Rubinius.
Those are concrete scenarios to consider. I don't see how a physical materials analogy has any value in analyzing your options. The pros and cons of languages don't align AT ALL with physical properties. Thoughts like, "Java is more like cast iron, and Python is more like hardwood" is just one-dimensional mental masturbation. In the end the reason to choose a language like Java because you are willing to tolerate more overhead for less risk.
Frameworks can sometimes be annoying. It's like learning a new sub-language on top of the programming language as there is a certain amount of familiarity you need with a framework's calls (ex. to program in Python, it goes a lot faster if you know that it's len(list) not list.length() and similarly if you're using Rails it's important to know that there is no validates_is_number, but there is validates_numericality_of). So, you start learning all these things that may or may not apply to your project - the language of the framework. And in some places it slows you down and you feel like there's abstraction just for the sake of abstraction, but in the end I think it's worth it.
I also think Joel misses something: most programmers are bad programmers. They'll dig you into holes, write lots of spaghetti string code, etc. At least when they're using a framework there's some constraint on their madness. Frameworks (generally) make it a tad difficult to work outside of their constraints and so the default becomes to work in that standard way. So, you don't get people doing weird things as often - like building a string that is the page that they'll echo out like the piece of PHP I'm working on today does (guess they didn't realize that you could simply go out of PHP mode to do that).
I also think Joel misses something: most programmers are bad programmers. They'll dig you into holes, write lots of spaghetti string code, etc. At least when they're using a framework there's some constraint on their madness. Frameworks (generally) make it a tad difficult to work outside of their constraints and so the default becomes to work in that standard way. So, you don't get people doing weird things as often - like building a string that is the page that they'll echo out like the piece of PHP I'm working on today does (guess they didn't realize that you could simply go out of PHP mode to do that).
I guess I'm one of those bad programmers who does "weird things" , I often create a string with my entire page and then output it. I thought it made more sense since I now have a string that I can run regexes on or find/replace if necessary. Also it makes it easy if I decide I want to cache the page somewhere, I think I must be "dumb and gets things done."
I think there's a wee bit of differnece between creating a string with a whole page because you don't know that you can jump in and out of PHP mode and creating a string with a whole page in order to do regex'es on the string
:-)
:-)
PHP (I assume we're still talking about PHP) has had output buffering for about a decade. So yeah that is a weird thing. ;)
I've done this before. If you're the sole owner of something, and especially if there will never be a designer in the mix, I think it makes sense to stick with what you are (and more importantly will be) familiar with. I once used python string substitution as a poor man's template system, because I knew that when I came back to that code months/years later, I'd still know how string formatting works w/o having to refer back to documentation.
Nothing really wrong with that per se. The problem is if at one point you decide that's just the way to do things and you never learn new approaches. If you want to be a good programmer you have to try different things and learn the pros and cons for yourself. Best practices are a decent jumping off point, but developers often overestimate their own best practices that they've learned while working on certain types of projects. It's especially insidious among very smart developers who work in a narrow field, because their reputation causes their wisdom to be mis-applied by junior developers and cargo-culters.
> I also think Joel misses something
Just FYI. This was post on the "Joel on Sofware" discussion group but the author is Benji Smith.
http://benjismith.net/
I like his blog. He used to post a lot more but he's been busy with a new project. (and a HD crash as of this morning.)
Just FYI. This was post on the "Joel on Sofware" discussion group but the author is Benji Smith.
http://benjismith.net/
I like his blog. He used to post a lot more but he's been busy with a new project. (and a HD crash as of this morning.)
"most programmers are bad programmers"
You should hang around better programmers.
You should hang around better programmers.
A friend convinced me to try AppFuse once. I have a burning, probably un-justified hatred of Eclipse, so I tried the AppFuse + NetBeans tutorial.
That may be the most unproductive I have felt in my entire life. I made a damn login form and it took like 12 pages of tutorial, tons of setup, generating a whole bunch of files that seemed like they could have been done algorithmically because they are always the same, editing like nine different XML files with little bits of glue, and eventually like one or maybe two lines of code.
Then, I got to wait for the WAR to compile each time I wanted to test a change, because the tutorial didn't seem to know about a developer mode which probably exists.
I hate to sound all ranty and partisan, but I could find no way in which that process could be efficient and couldn't imagine anyone doing it voluntarily unless they were ordered or just had no exposure to the rest of the world.
Also, I sort of object to having code stuffed in an eight-folder deep hierarchy where the preceding seven folders contain nothing at all. That's a lot of wasted navigation and clicking time and distraction.
That may be the most unproductive I have felt in my entire life. I made a damn login form and it took like 12 pages of tutorial, tons of setup, generating a whole bunch of files that seemed like they could have been done algorithmically because they are always the same, editing like nine different XML files with little bits of glue, and eventually like one or maybe two lines of code.
Then, I got to wait for the WAR to compile each time I wanted to test a change, because the tutorial didn't seem to know about a developer mode which probably exists.
I hate to sound all ranty and partisan, but I could find no way in which that process could be efficient and couldn't imagine anyone doing it voluntarily unless they were ordered or just had no exposure to the rest of the world.
Also, I sort of object to having code stuffed in an eight-folder deep hierarchy where the preceding seven folders contain nothing at all. That's a lot of wasted navigation and clicking time and distraction.
There's most likely a developer mode, but that's only good for reloading a change to a Java class file. Reloading an xml file will still take a restart of the servlet container. I agree with you that there is basically nothing efficient about the entire process.
[deleted]
On a related note, I saw this on reddit this morning: http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server...
What's sad is that I have no idea if this is a joke or not.
What's sad is that I have no idea if this is a joke or not.
Perfect thing to show people, when they want to know if Java is a good fit for their problem. Even a Pointy Haired Boss, shown this, might understand why Rails or Django or something might be a better way to go than dealing with this.
EDIT: OK, so instead of Java, that should read "to know if enterprisey Java frameworks are a good fit for their problem." The irony is, that I just was IM'ing a friend about how this isn't the fault of Java the Language, but the "enterprise architecture" community that write Java frameworks like this.
EDIT: OK, so instead of Java, that should read "to know if enterprisey Java frameworks are a good fit for their problem." The irony is, that I just was IM'ing a friend about how this isn't the fault of Java the Language, but the "enterprise architecture" community that write Java frameworks like this.
Java is not the problem, the architecture is the problem. If you try hard enough, you can make something unwieldy and atrocious in ANY language. That's why enterprise architects get the big bucks.
That may be true, but it's a hell of a lot easier to make fugly spaghetti in something statically typed like Java (or C#, C++, and so on).
After 8 years of Java, I personally found it really refreshing to build stuff in Python and Ruby.
After 8 years of Java, I personally found it really refreshing to build stuff in Python and Ruby.
I don't know. After seeing some pretty unbelievable crap in VB, php, and javascript, I bet it's more a matter of numbers. The kinds of people who program in Python or Ruby aren't off the assembly line because the industry demand isn't as high. If one of those languages manages to become as widely used as Java, plan on seeing fugly spaghetti.
And if you try even harder, you can make something that is compact, but elegant and functional. It is still architecture, but it is good architecture. It's not the architecture that is the problem, it is the architect. Or specifically the motivations provided to the architect based on the compensation they are given. Unwieldy and atrocious looks like it took longer to the untrained eye, even if it probably didn't, so they face less grilling about the claimed effort involved. Simple to use is, in my experience, rarely simple to build. But it is simple to understand, and there is a unreasonable cognitive bias that simple to understand means simple to conceive. If that point can become more a part of everyone's collective wisdom, I suspect we would cure at least part of the motivation for creating these unwieldy systems.
The thing is, if you're writing a Ruby framework and there's a tiny chance someone will want to extend some part of it, they can do it without you needing layers of ClassFactoryFactory crud.
That's a ridiculous statement. Idiocy can be written in any language, including Java.
The Apache XML-RPC framework is a complete joke. It is completely over-engineered with crazy patterns and stupid extensibility hooks that nobody is waiting for.
When Polar Rose still used XML-RPC we rolled our own framework that integrates well with Spring. You basically expose your POJO and be done with it ...
http://code.google.com/p/polarrose-spring-xmlrpc
When Polar Rose still used XML-RPC we rolled our own framework that integrates well with Spring. You basically expose your POJO and be done with it ...
http://code.google.com/p/polarrose-spring-xmlrpc
It's funnier with the Xzibit reference.
On a similar note, the code parse an XML document in Java:
Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse("test.xml");
I bet they were looking for extensibility.
I wonder if they ever thought of providing two interfaces.
1. The first is the common case.
I wonder if they ever thought of providing two interfaces.
1. The first is the common case.
Document doc = new DocumentBuilder().parse("test.xml");
Document doc = DocumentBuilderFactory.newInstance(opts).newDocumentBuilder(opts2).parse("test.xml");This is the facade pattern :) If you need it, this means you are overengineering. Applying it is even more overengineering.
I think the common case could be even simpler
Document doc = DocumentBuilder.parse("test.xml");
You can lay for that in the gang of four book which recommended things like "abstract factory" - the odd thing was, I thought most of those authors were ex smalltalkers?
I've seen good frameworks (OWL, Nitrogen + Powerplant, maybe 1 or 2 more), and I've seen a crap-ton of bad frameworks (any web framework on java, minus maybe WebObjects).
They're necessary, but they're hard to do right. The man who did Powerplant said he went through about a dozen different designs before getting one he liked. That's why it was often so useful. Most times, people say "hey, let's take these APIs and let people subclass! yay!"
And that's how you end up with crap like doGet(), doPost(), etc.
They're necessary, but they're hard to do right. The man who did Powerplant said he went through about a dozen different designs before getting one he liked. That's why it was often so useful. Most times, people say "hey, let's take these APIs and let people subclass! yay!"
And that's how you end up with crap like doGet(), doPost(), etc.
"minus maybe WebObjects"
What made WO great were the tools. There was still complexity there, but WOBuilder and EOModeler made the whole process very productive. You could think of your data model, your interface, and your business logic independently of each other, and then use the tools to hook them together in a way that made sense. Because of the way the tools were designed, they actually made using good design for your application easier than using bad design.
That's the main thing missing from all the frameworks I see today, integrated tools that automate the tedious parts and encourage good design practices.
To me, the WO tools go on the heap with the Lisp Machine, the Xerox Park Smalltalk environment and HyperCard, as old development technologies that are still ahead of today's state of the art.
EDIT: spelling correction
What made WO great were the tools. There was still complexity there, but WOBuilder and EOModeler made the whole process very productive. You could think of your data model, your interface, and your business logic independently of each other, and then use the tools to hook them together in a way that made sense. Because of the way the tools were designed, they actually made using good design for your application easier than using bad design.
That's the main thing missing from all the frameworks I see today, integrated tools that automate the tedious parts and encourage good design practices.
To me, the WO tools go on the heap with the Lisp Machine, the Xerox Park Smalltalk environment and HyperCard, as old development technologies that are still ahead of today's state of the art.
EDIT: spelling correction
That would be Smalltalk not SmallTalk, and some of us still use it, daily, for web apps. It might not be in wide use, but it isn't on the scrap heap.
People still use WebObjects everyday too (I used to be one of them), but not very many. I'd say WebObjects is basically on the scrap heap.
I would agree with you, apart from the remarks about "the (scrap) heap" :-) . I still use two of those technologies (WebObjects and Hypercard) almost every day, and I never used either of them until about 5 years ago. For what they do, they are peerless. For information about using WebObjects I'd suggest people visit http://www.wocommunity.org, and if anyone's interested in Hypercard, try http://www.runrev.com (a modern cross-platform hypercard).
Over-complexity is common in the Java space. I was aghast at using JMS. You make a Context so that you can tell it to make a ConnectionFactory, so that you can then ask that thing for a Connection, then you finally get to login. You can then instantiate Producers and Consumers and finally get messages.
Why do I need to have 5 different objects when one would do? Having 5 different objects did absolutely nothing for the client code except make it more complex. (And this actually complicates good coding for the user experience. When we notify the user of network problems, I have to add additional code to see if objects exist in the first place just to prevent exceptions.)
It would've made no difference if there was just one Object. (Except for shorter code.) I could use it to login to a server. I could use it to register interest in a topic then ask for messages on that topic. If I want to connect to a different server, then I could instantiate a second object. Why do I need 5 freaking instances to do the most basic thing possible?
Why do I need to have 5 different objects when one would do? Having 5 different objects did absolutely nothing for the client code except make it more complex. (And this actually complicates good coding for the user experience. When we notify the user of network problems, I have to add additional code to see if objects exist in the first place just to prevent exceptions.)
It would've made no difference if there was just one Object. (Except for shorter code.) I could use it to login to a server. I could use it to register interest in a topic then ask for messages on that topic. If I want to connect to a different server, then I could instantiate a second object. Why do I need 5 freaking instances to do the most basic thing possible?
This also makes unit testing extremely diffcult since you have the joy of creating mock objects for your Context, ConnectionFactory and Connection. I have all but given up writing test code at work. The various j2ee frameworks I have to use make it almost impossible.
Drop Classic J2EE and learn Spring. It will make things sooo much easier and manageable.
It definitely does make the above more manageable, but it doesn't solve the core problem which is that the whole design pattern is built for complete configurability, but without sensible defaults. In some sense, Spring only exists to manage the massive configurability of Java design patterns, but by adding it's own configurations to the mix. It's definitely a cool idea, but the better solution is to just avoid factory/context patterns. It's solving a problem most of us don't have.
"""It's solving a problem most of us don't have."""
I think that is because a lot of people simply don't know what good design is. I've seen many projects where people think they don't need Spring but where it made 100% sense. And made the project simpler and easier to manage and test.
Even in small projects it makes a lot of sense to have a good seperation in layers or services and to use a mostly invisible helper to glue things together.
Modern Spring can configure your app with a very minimal amount of XML. If you don't like XML then use annotation based configuration.
I totally disagree with your statement that Spring only exists to manage the 'massive configurability of Java design patterns'. The only patterns that the foundation of Spring introduces are IoC and 'configuration by convention'. Those have been proven to be extremely powerful patterns that simply allow you to burn half of the 'J2EE Design Patterns' books.
I think that is because a lot of people simply don't know what good design is. I've seen many projects where people think they don't need Spring but where it made 100% sense. And made the project simpler and easier to manage and test.
Even in small projects it makes a lot of sense to have a good seperation in layers or services and to use a mostly invisible helper to glue things together.
Modern Spring can configure your app with a very minimal amount of XML. If you don't like XML then use annotation based configuration.
I totally disagree with your statement that Spring only exists to manage the 'massive configurability of Java design patterns'. The only patterns that the foundation of Spring introduces are IoC and 'configuration by convention'. Those have been proven to be extremely powerful patterns that simply allow you to burn half of the 'J2EE Design Patterns' books.
Spring is definitely an improvement, however we had a serious problem getting it up and running in our environment (it was a while ago so I can't remember what it was exactly) and had to give up on it.
It really does not help that all of our web projects are struts 1 and we have still have a fair amount of torque projects hanging around.
It really does not help that all of our web projects are struts 1 and we have still have a fair amount of torque projects hanging around.
No kidding. J2EE is an abomination, and is almost single-handedly responsible for destroying Java's reputation with a lot of programmers. Spring is a giant leap forward.
Grails is basically Spring MVC, wrapped in dynamic language goodness. I'm using it for a project right now, and it's shockingly terse and clean. It's also a lot of fun, which is something I never thought I'd say about a Java "Enterprise Framework".
Grails is basically Spring MVC, wrapped in dynamic language goodness. I'm using it for a project right now, and it's shockingly terse and clean. It's also a lot of fun, which is something I never thought I'd say about a Java "Enterprise Framework".
Spring's dependence on XML files always bugged the hell out of me. I like to be able to see what a piece of code does by looking at the code. Every time I tried to get excited about Spring I instead felt like at I was more and more at the mercy of my IDE.
"""Over-complexity is common in the Java space."""
Yes, in a SPECIFIC area of the Java space.
There is a huge group of people who believe that J2EE and its complexities are a major pain the ass. That is why great frameworks like Spring, Guice or Stripes exist.
Sun loves you when you use J2EE/JSF/EJB/JMS/JWHATEVER. But there are serious alternatives that are more lightweight, easier and less intrusive.
Of course you will not add value (read: buy into) to the Sun Enterprise Ecosystem :-)
Staying away from (most) 'Enterprise' Java standards has worked very well for me. I really enjoy working in Java.
Yes, in a SPECIFIC area of the Java space.
There is a huge group of people who believe that J2EE and its complexities are a major pain the ass. That is why great frameworks like Spring, Guice or Stripes exist.
Sun loves you when you use J2EE/JSF/EJB/JMS/JWHATEVER. But there are serious alternatives that are more lightweight, easier and less intrusive.
Of course you will not add value (read: buy into) to the Sun Enterprise Ecosystem :-)
Staying away from (most) 'Enterprise' Java standards has worked very well for me. I really enjoy working in Java.
Have you seen Spring lately? I'm not sure it's much of an improvement. Stripes is nice as far as Java web frameworks go, but it's fairly simple and this is where the problem lies.
Someone comes up with a tool that's great for a specific job. Later, someone else comes along with a slightly different problem and the tool changes a little to accomodate them. Then a few others. Before you know it every feature under the sun is added to handle every possible scenario.
Now you're stuck with crappy middleware. It does a decent enough job after you configure it properly and strip it down to only the modules that apply to your specific problem. It's not so bad because you've been using it for a while and you know it inside and out. Plus, it can be used to solve everything. It can probably even cure cancer with the right module and proper configuration.
But sooner or later someone else comes along, decides this nifty universal tool is a steaming pile of shit and sets out to invent something simpler and less bloated. And it will only be better because it doesn't have everything, including the kitchen sink, bolted onto it. It's focused and lean. But then someone comes along with a slightly different problem than what it was intended to solve and the hot new framework with all the buzz starts going bad just like the last one.
Look at Stripes. It's just a better version of Struts2 which was based on Webwork which was intended to be a better Struts 1. Eventually, more and more cruft will be added to Stripes so it becomes as bad as what it was designed to replace and someone will come along and invent a better Stripes.
In my opinion, this is the biggest problem with frameworks. Many developers prefer to have a universal tool instead of having several that are good for different jobs so we end up with this cycle of cruft.
Someone comes up with a tool that's great for a specific job. Later, someone else comes along with a slightly different problem and the tool changes a little to accomodate them. Then a few others. Before you know it every feature under the sun is added to handle every possible scenario.
Now you're stuck with crappy middleware. It does a decent enough job after you configure it properly and strip it down to only the modules that apply to your specific problem. It's not so bad because you've been using it for a while and you know it inside and out. Plus, it can be used to solve everything. It can probably even cure cancer with the right module and proper configuration.
But sooner or later someone else comes along, decides this nifty universal tool is a steaming pile of shit and sets out to invent something simpler and less bloated. And it will only be better because it doesn't have everything, including the kitchen sink, bolted onto it. It's focused and lean. But then someone comes along with a slightly different problem than what it was intended to solve and the hot new framework with all the buzz starts going bad just like the last one.
Look at Stripes. It's just a better version of Struts2 which was based on Webwork which was intended to be a better Struts 1. Eventually, more and more cruft will be added to Stripes so it becomes as bad as what it was designed to replace and someone will come along and invent a better Stripes.
In my opinion, this is the biggest problem with frameworks. Many developers prefer to have a universal tool instead of having several that are good for different jobs so we end up with this cycle of cruft.
Just finished a Struts 2/Spring app. Hey, I had to cover tuition somehow.
The biggest problem with the entire stack is that every piece would rather overengineer a solution to a small part of the problem, instead of giving us a simple solution for the whole thing.
Look, just have a stock web.xml, and don't touch interceptors. Instead, put together a single, coherent system for dispatching a URL to the right object, and the same for security requirements. If you need more, abstract once, there for the URL. That's it.
After months of reading through crap documentation (Hibernate, I'm looking at you), it's obvious that the frameworks are 90% of the problem, and your actual set of requirements are the last 10.
The biggest problem with the entire stack is that every piece would rather overengineer a solution to a small part of the problem, instead of giving us a simple solution for the whole thing.
Look, just have a stock web.xml, and don't touch interceptors. Instead, put together a single, coherent system for dispatching a URL to the right object, and the same for security requirements. If you need more, abstract once, there for the URL. That's it.
After months of reading through crap documentation (Hibernate, I'm looking at you), it's obvious that the frameworks are 90% of the problem, and your actual set of requirements are the last 10.
Here's the dirty little secret that no one wants to talk about...
The purpose of "assisters" like frameworks and higher level languages is NOT to make good progammers more efficient.
It's to make mediocre programmers more likely to produce something of value and to make poor programmers capable of producing anything at all.
And if the bell curve tells us anything at all, it's that these "tools" target 90% of all programmers.
But think about it, my fellow top 10% (lol), do you really need all this stuff? If you're working alone or on a small team with a clear objective, haven't you always had everything you needed with low level tools? If you need any higher level tools or reuseable components, haven't you already been building these all along?
Sure it's fun to play with new things and learn from others, but when it comes time to really produce, don't we all know how to (and need to) roll with what we know?
The need for frameworks and high level languages only becomes apparent when we grow so large that we can't find enough senior hackers. Only when you dip down into the mediocre masses do you need this help.
The purpose of "assisters" like frameworks and higher level languages is NOT to make good progammers more efficient.
It's to make mediocre programmers more likely to produce something of value and to make poor programmers capable of producing anything at all.
And if the bell curve tells us anything at all, it's that these "tools" target 90% of all programmers.
But think about it, my fellow top 10% (lol), do you really need all this stuff? If you're working alone or on a small team with a clear objective, haven't you always had everything you needed with low level tools? If you need any higher level tools or reuseable components, haven't you already been building these all along?
Sure it's fun to play with new things and learn from others, but when it comes time to really produce, don't we all know how to (and need to) roll with what we know?
The need for frameworks and high level languages only becomes apparent when we grow so large that we can't find enough senior hackers. Only when you dip down into the mediocre masses do you need this help.
I agree completely. Web frameworks add a layer of code bureaucracy that really doesn't need to be there in most cases. Reading and setting browser cookies is not that hard. Creating and reading web forms and validating inputs is not hard. Creating a relational database schema and objects that store themselves in that schema is not hard. You can do all of this directly in mod_python, essentialy by buildng your own framework, so you really don't need Django (I'm know, I'm a heretic for saying so) But doing all of these things directly mod_python takes time to learn how to do it reliably and efficiently. So I understand Django's appeal to people who picked up a Python book and asked "How do I create an event calendar web site in five mouse clicks?" and didn't see a direct answer to that question so they went with a framework. Personally I'd rather not toil under the tyranny of someone else's framework, especially when they suggest you need to create Factory for a Consumer then connect it to an Active Bridge connector... no thanks, I'll just use "mod_python import Cookie" instead.
"essentially by building your own framework"
Why build your own framework when there's one already there? Already well-used, well-tested, well-extended?
Sure it may be easy enough to do, but is it really worth it?
I, for one, would much prefer to be spending my coding time writing application logic than Yet Another Validation Library.
Why build your own framework when there's one already there? Already well-used, well-tested, well-extended?
Sure it may be easy enough to do, but is it really worth it?
I, for one, would much prefer to be spending my coding time writing application logic than Yet Another Validation Library.
Because frameworks aren't optimized to your use case.
Hell, programming languages (typically) aren't optimized to your use case. You modify them to make them so.
Good frameworks are the same way. I've already extended the hell out of Kohana to make it more useful to me. This is work I would have had to have done if I weren't using it, sure, but all the basic stuff is there all the same.
Good frameworks are the same way. I've already extended the hell out of Kohana to make it more useful to me. This is work I would have had to have done if I weren't using it, sure, but all the basic stuff is there all the same.
Sure, it just depends. Quite often, I've found that modifying someone elses code takes orders of magnitude longer, than just writing it yourself.
the difficulty of modifying somebody else's code is proportional to your own programming skill.
Yeah I'm not sure that's actually true :)
Would you rather build a porche, or try to convert a clapped out old volvo into a porche?
Tidying up rubbish, bad architecture choices, stupid coupling etc isn't fun. It's twice the work - fixing all the stuff they did stupidly, and then implementing it how it should be done.
Would you rather build a porche, or try to convert a clapped out old volvo into a porche?
Tidying up rubbish, bad architecture choices, stupid coupling etc isn't fun. It's twice the work - fixing all the stuff they did stupidly, and then implementing it how it should be done.
So, the popular theorem is that programmers who have been working for any amount of time already have the makings of their own frameworks. They've already written code to connect to or abstract a database. They've already written their authentication pieces. They've already written (or are using) something like Smarty for 'views' or display data.
For many developers who toil in the same language all the time, or who have spent many hours in whatever language they're currently in, that's the case.
For me, I avoid Rails because it makes me feel like a failure. ActiveRecord, for one reason or another, hates me. I like Rails, and I like the Framework concept (however limiting it might be) -- because I feel that it gets you started more quickly. At the end of any significant project, I feel like you will have likely massaged enough elements of the framework to make it work for you that it's hardly recognizable, but it still got you something to show people that much faster.
That said, ActiveRecord is the showstopper for me in Rails. It seems like I've either never properly wrapped my head around it, or there are fairly low limits to what you can do, or I'm doing everything wrong. What that's always meant for me is that instead of using ActiveRecord to its fullest, I'm building SQL queries manually. And if I'm deviating from the framework's toolset, why am I using this framework in the first place.
This is NOT a knock on Rails, I'm probably just doing it wrong. Rails and I can still be friends... just not in that way.
I've always liked the 'middle ground' that Zend offers, in that it abstracts away the connection and handle, and gives me a convenient place to start building the model code. It's not 100%, but it doesn't make me feel guilty in the morning either.
For many developers who toil in the same language all the time, or who have spent many hours in whatever language they're currently in, that's the case.
For me, I avoid Rails because it makes me feel like a failure. ActiveRecord, for one reason or another, hates me. I like Rails, and I like the Framework concept (however limiting it might be) -- because I feel that it gets you started more quickly. At the end of any significant project, I feel like you will have likely massaged enough elements of the framework to make it work for you that it's hardly recognizable, but it still got you something to show people that much faster.
That said, ActiveRecord is the showstopper for me in Rails. It seems like I've either never properly wrapped my head around it, or there are fairly low limits to what you can do, or I'm doing everything wrong. What that's always meant for me is that instead of using ActiveRecord to its fullest, I'm building SQL queries manually. And if I'm deviating from the framework's toolset, why am I using this framework in the first place.
This is NOT a knock on Rails, I'm probably just doing it wrong. Rails and I can still be friends... just not in that way.
I've always liked the 'middle ground' that Zend offers, in that it abstracts away the connection and handle, and gives me a convenient place to start building the model code. It's not 100%, but it doesn't make me feel guilty in the morning either.
I use Kohana myself, for exactly the reason that you mention you like Zend - it's a good starting point. And if I need to extend Kohana's model or rewrite it from the ground up, this is totally accepted and even encouraged by the framework.
I find it's just way, way easier to get up to speed with a framework as a base, and if your framework is any good, then it should be easy to shove aside later when you need to special-case things for performance or whatever.
I find it's just way, way easier to get up to speed with a framework as a base, and if your framework is any good, then it should be easy to shove aside later when you need to special-case things for performance or whatever.
There is a trade-off to using a Framework. For me, it depends on the complexity of the problem, and the difficulty of learning the framework.
Suppose someone is familiar with Java Servlets and JSP, basic JDBC and SQL, and the tomcat container (with connection pooling). If I have a simple database driven application, I can choose to hand code some of my application logic, or use a framework.
So I'm choosing between, say:
No framework: container managed security, hand coding my ORM layer, writing my own server side form validation, writing my own MVC (or just not bothering, if it is just a few pages).
Framework: Spring Security, Struts for form building and validation, Spring for the MVC tier, JPA and Hibernate for ORM.
These are slightly extreme - you don't have to use all those tools, of course.
But let's say we do get something out of the framework. The code really is easier to maintain and understand, provided someone has read a 300 page book on spring, another 300 page book on hibernate, and a 150 subsection of a book on Struts, along with doing all the exercises.
Even if the framework based code is better, that's not enough to justify the complexity. I need to justify taking an application out of the realm of someone who understands the basic servlet spec and putting it into the realm of only those who have read and digested an additional 600+ pages of Framework complexity.
Thing is, I like frameworks. You can read and digest 100 pages about Rails and really get going. So the bar for justifying the "added complexity" of a framework in the Ruby world is much lower than it is in the Java world. I don't use Python, but I'd imagine it's a similar situation - it's much easier to justify Django than the Java framework stack.
Suppose someone is familiar with Java Servlets and JSP, basic JDBC and SQL, and the tomcat container (with connection pooling). If I have a simple database driven application, I can choose to hand code some of my application logic, or use a framework.
So I'm choosing between, say:
No framework: container managed security, hand coding my ORM layer, writing my own server side form validation, writing my own MVC (or just not bothering, if it is just a few pages).
Framework: Spring Security, Struts for form building and validation, Spring for the MVC tier, JPA and Hibernate for ORM.
These are slightly extreme - you don't have to use all those tools, of course.
But let's say we do get something out of the framework. The code really is easier to maintain and understand, provided someone has read a 300 page book on spring, another 300 page book on hibernate, and a 150 subsection of a book on Struts, along with doing all the exercises.
Even if the framework based code is better, that's not enough to justify the complexity. I need to justify taking an application out of the realm of someone who understands the basic servlet spec and putting it into the realm of only those who have read and digested an additional 600+ pages of Framework complexity.
Thing is, I like frameworks. You can read and digest 100 pages about Rails and really get going. So the bar for justifying the "added complexity" of a framework in the Ruby world is much lower than it is in the Java world. I don't use Python, but I'd imagine it's a similar situation - it's much easier to justify Django than the Java framework stack.
"Why build your own framework when there's one already there?"
Why learn woodworking when you can buy furniture at Walmart? Some people like craftsmanship and others like frozen dinners.
Why learn woodworking when you can buy furniture at Walmart? Some people like craftsmanship and others like frozen dinners.
Code bureaucracy? A friend of mine managed an Extreme Programming project for the Department of Defense. When he first started out, the paper bureaucracy required to create a new class amounted to two full business days! He got that whittled down to two hours.
My biggest problem with frameworks is that, although they save you a lot of time upfront, you need to spend a lot of energy learning concepts that may not be necessary for your application. So, the time you save coding is partly spent in learning things you may or may not need.
If you do everything by yourself initially, at least you will know when it makes sense to use the framework. This is my approach with web development: Try to do whatever I need without the help of a framework. Then, I will know where a framework can help or not, and use it the next time I need a specific functionality.
this is no doubt tangential to your original point, but you should stay away from mod_python. You're walking into a version coordination nightmare (apache+DB+python). Debugging is a pain and your apache processes now load a python interpreter (each!). I suggest you take a look at wsgi.
"Only when you dip down into the mediocre masses do you need this help."
And what is wrong with that? Some of us aren't the programming gods you are. If it helps people why get so high and mighty about it? I know with your superior intellect us philistines might seem dumb to you, but maybe you should stop writing about how smart you are when you can't even spell "programmers" right.
And what is wrong with that? Some of us aren't the programming gods you are. If it helps people why get so high and mighty about it? I know with your superior intellect us philistines might seem dumb to you, but maybe you should stop writing about how smart you are when you can't even spell "programmers" right.
Amen. If the goal of programming is to liberate humanity from tedium, what's with this kind of elitism? Many of us live happy lives as programmers with zero formal training but relentless curiosity; having never cracked SICP or taken an electronics course but producing solid work -- often with the help of high level languages and frameworks. I mean shit, isn't that the whole point? To let anyone make something effective?
Struck a nerve, huh?
This was partially in jest (notice the lol), and I realize this is sometimes hard to convey in writing. Sorry.
But there's also a lot of truth in it, too.
No one is born a mediocre programmer. It's a choice.
Notice I didn't say a "junior" programmer. There's a difference. A junior programmer has less experience, but has a good attitude, is willing to learn, and practice his or her craft to get better. A mediocre programmer is just lazy and thinks he or she knows better.
This was directed at the thousands of lazy thoughtless programmers I've had to clean up after over the years. You know the ones. They refuse to follow accepted standards. They name their variables whatever they feel like at the moment. Good luck figuring out what "a" "aa" or "aaa" mean. Or locating them in a text editor. They use single entry, multiple exit. Good luck changing one line of code in the middle of that. They rewrite the same functions over and over, so I have to change all 14 versions. And spend the next 2 weeks regression testing.
I only wish these people were required to use a framework that forced them to conform to anything that would have made my life a little easier.
If "high and mighty" means "wants to get work done" or "cares about others", then thank you. Some of us choose to write clear, effective, easy to maintain code without a framework. If you ever have to maintain my code, perhaps you'll understand.
This was partially in jest (notice the lol), and I realize this is sometimes hard to convey in writing. Sorry.
But there's also a lot of truth in it, too.
No one is born a mediocre programmer. It's a choice.
Notice I didn't say a "junior" programmer. There's a difference. A junior programmer has less experience, but has a good attitude, is willing to learn, and practice his or her craft to get better. A mediocre programmer is just lazy and thinks he or she knows better.
This was directed at the thousands of lazy thoughtless programmers I've had to clean up after over the years. You know the ones. They refuse to follow accepted standards. They name their variables whatever they feel like at the moment. Good luck figuring out what "a" "aa" or "aaa" mean. Or locating them in a text editor. They use single entry, multiple exit. Good luck changing one line of code in the middle of that. They rewrite the same functions over and over, so I have to change all 14 versions. And spend the next 2 weeks regression testing.
I only wish these people were required to use a framework that forced them to conform to anything that would have made my life a little easier.
If "high and mighty" means "wants to get work done" or "cares about others", then thank you. Some of us choose to write clear, effective, easy to maintain code without a framework. If you ever have to maintain my code, perhaps you'll understand.
Personally I've found when a decent framework is used, there's a lot less crap; since a lot of choices have already been made
ex. for web apps it prevents people from putting everything on one page (DB calls, logic, HTML, ...)
ex. for web apps it prevents people from putting everything on one page (DB calls, logic, HTML, ...)
Unfortunately for the original article, the JSR-168 Portal standard is one of the worst things ever created that became horrifically popular for some mysterious reason.
I use a framework because I'm aware of the fact that I'm an inexperienced coder. I could work out every little detail by hand, but for me it's much easier to have something basic in place that I can tweak to my heart's content.
So I guess I'm just an ambitious junior programmer? Which is to say, I want to get better, but I also want to make my project production-ready as quickly as possible, so I use a frame and fill it out.
So I think it's a mistake to say that frameworks are only useful for making bad workers produce work. Better to say that there's a time and place for everything, and that while frameworks are overused, they're useful for certain people doing certain tasks.
So I guess I'm just an ambitious junior programmer? Which is to say, I want to get better, but I also want to make my project production-ready as quickly as possible, so I use a frame and fill it out.
So I think it's a mistake to say that frameworks are only useful for making bad workers produce work. Better to say that there's a time and place for everything, and that while frameworks are overused, they're useful for certain people doing certain tasks.
"Struck a nerve, huh?"
Yes. I am not a great programmer. I only started caring about it a couple of years ago and since I don't have a real education in it I am very behind in many areas. I am trying to get better, but it's not easy.
"No one is born a mediocre programmer. It's a choice."
I don't know if I agree with this. Some people are born with incredible talent in various areas. Some people are just born musicians, others athletes, others programmers. There is no substitute for hard work, but some people will never be able to grasp what others can do. No matter how long you play guitar, you're not going to be Jimi Hendrix.
I understand your sentiment, I really do. But I would be careful of calling misinformed people lazy. I would bet good money that there are "standards" I am breaking with my code that I don't even know exist. If the books I read or the sites I visit haven't told me about them, I wouldn't call myself lazy.
In the end, HN is a community of amazingly talented people who are, to me, beyond brilliant. I think it's easy to lose sight of the "real world" some times when there are so many smart people in one room. Just have a little bit more slack for people who are trying and not as good as you. I think you will find it explains a lot.
"Some of us choose to write clear, effective, easy to maintain code without a framework. If you ever have to maintain my code, perhaps you'll understand."
Do you "choose" to do that, or are you benefiting from the years of education and experience you have? It's not like I can wake up tomorrow and choose to be an expert programmer. I can only try to keep learning(which is why I hang around here). I completely understand your frustrations with work, it can be a pain in the ass to deal with people who make your work harder through their incompetence, but I don't think it's as deliberate as you are suggesting it is.
Yes. I am not a great programmer. I only started caring about it a couple of years ago and since I don't have a real education in it I am very behind in many areas. I am trying to get better, but it's not easy.
"No one is born a mediocre programmer. It's a choice."
I don't know if I agree with this. Some people are born with incredible talent in various areas. Some people are just born musicians, others athletes, others programmers. There is no substitute for hard work, but some people will never be able to grasp what others can do. No matter how long you play guitar, you're not going to be Jimi Hendrix.
I understand your sentiment, I really do. But I would be careful of calling misinformed people lazy. I would bet good money that there are "standards" I am breaking with my code that I don't even know exist. If the books I read or the sites I visit haven't told me about them, I wouldn't call myself lazy.
In the end, HN is a community of amazingly talented people who are, to me, beyond brilliant. I think it's easy to lose sight of the "real world" some times when there are so many smart people in one room. Just have a little bit more slack for people who are trying and not as good as you. I think you will find it explains a lot.
"Some of us choose to write clear, effective, easy to maintain code without a framework. If you ever have to maintain my code, perhaps you'll understand."
Do you "choose" to do that, or are you benefiting from the years of education and experience you have? It's not like I can wake up tomorrow and choose to be an expert programmer. I can only try to keep learning(which is why I hang around here). I completely understand your frustrations with work, it can be a pain in the ass to deal with people who make your work harder through their incompetence, but I don't think it's as deliberate as you are suggesting it is.
As my boss used to say, "the best people I've worked with have all been self taught." I've found this to be true myself. A college degree (especially (?) in CS) is not the cause of, nor (in my experience) even correlated with, great programming. I think even being aware of and caring about the issues that have been mentioned makes one above average, even if you don't (yet) have the experience to solve it all.
The humility in your attitude is the mark of a good programmer, not a bad one. If you really are learning and working hard at it, you'll do fine, and I'd rather have you on my team than a lot of the (apparently) super-smart guys you're feeling inferior to.
A nice thing about the programming world is that it's a sort of natural democracy. No one really knows how good they are.
A nice thing about the programming world is that it's a sort of natural democracy. No one really knows how good they are.
"The humility in your attitude is the mark of a good programmer, not a bad one. If you really are learning and working hard at it, you'll do fine, and I'd rather have you on my team than a lot of the (apparently) super-smart guys you're feeling inferior to."
I second that!
I second that!
...don't have a real education in it I am very behind in many areas...
Who isn't? Don't sell yourself short.
No matter how long you play guitar, you're not going to be Jimi Hendrix.
You don't have to code like Jimi Hendrix to be a great programmer. (Oddly, I suspect that if I had to maintain his code, I'd probably be going nuts.) You just have to get your job done, work well with others, and leave something maintainable behind. I have a feeling you're already there. I also have a feeling that everyone reading this has done something cool that neither one of us has ever even thought of. In our field, not knowing something isn't a problem, it's an opportunity.
I understand your sentiment, I really do. But I would be careful of calling misinformed people lazy. I would bet good money that there are "standards" I am breaking with my code that I don't even know exist. If the books I read or the sites I visit haven't told me about them, I wouldn't call myself lazy.
I agree completely. I'd give you an extra up vote for that response if I could.
...are you benefiting from the years of education and experience you have?
Of course. We all are. Not benefiting from any education or experience you have oughta be a crime.
It's not like I can wake up tomorrow and choose to be an expert programmer.
Right. Give it a week or two. If you code as well as you comment here, you're probably way better than you give yourself credit for.
In the back of my mind, I thought there was a chance my remarks would be controversial when I first entered them. Sometimes it's fun to push the envelope here. (Remember, I'm in the middle of Day 4 of regression testing someone else's crap.) You proved me right.
As far as OP is concerned, I still think of frameworks and 4th generation languages as "crutches" for a lot of us. So they serve their purpose. But at a cost many others have talked about here.
Thanks for the great discussion, chez17. I'll make a point to look for you in future posts.
Who isn't? Don't sell yourself short.
No matter how long you play guitar, you're not going to be Jimi Hendrix.
You don't have to code like Jimi Hendrix to be a great programmer. (Oddly, I suspect that if I had to maintain his code, I'd probably be going nuts.) You just have to get your job done, work well with others, and leave something maintainable behind. I have a feeling you're already there. I also have a feeling that everyone reading this has done something cool that neither one of us has ever even thought of. In our field, not knowing something isn't a problem, it's an opportunity.
I understand your sentiment, I really do. But I would be careful of calling misinformed people lazy. I would bet good money that there are "standards" I am breaking with my code that I don't even know exist. If the books I read or the sites I visit haven't told me about them, I wouldn't call myself lazy.
I agree completely. I'd give you an extra up vote for that response if I could.
...are you benefiting from the years of education and experience you have?
Of course. We all are. Not benefiting from any education or experience you have oughta be a crime.
It's not like I can wake up tomorrow and choose to be an expert programmer.
Right. Give it a week or two. If you code as well as you comment here, you're probably way better than you give yourself credit for.
In the back of my mind, I thought there was a chance my remarks would be controversial when I first entered them. Sometimes it's fun to push the envelope here. (Remember, I'm in the middle of Day 4 of regression testing someone else's crap.) You proved me right.
As far as OP is concerned, I still think of frameworks and 4th generation languages as "crutches" for a lot of us. So they serve their purpose. But at a cost many others have talked about here.
Thanks for the great discussion, chez17. I'll make a point to look for you in future posts.
I probably do sell myself a little short, but again hanging around here it's not that hard to do. In the end, I probably reacted a little strongly, this is a community of experts and you were venting. I doubt you go stomping around the office yelling at people when they make mistakes. Thank you for a good discussion as well.
"Yes. I am not a great programmer. I only started caring about it a couple of years ago and since I don't have a real education in it I am very behind in many areas. I am trying to get better, but it's not easy."
You've just put yourself ahead of 95% of the millenials here by saying that. The only way to become great at ANYTHING is to admit that you aren't, and work on improving yourself.
Being junior isn't a bad thing. Everyone starts at the beginning, even the prodigies. The bad ones are juniors that attempt to skip the learning process by claiming to be great, not the ones who do like you are and put in the effort to learn.
The difference between you and the typical millenial, at least the ones that I've had the misfortune of working with over the years, is that they think they're good, and don't listen to the folks around them who've actually DONE the work before.
"I don't know if I agree with this. Some people are born with incredible talent in various areas."
The only talent humans are born with is the ability to construct their own future.
Those who lack talent and experience often believe that success is predicated on luck. They see spectacular photographs taken in times of perfect light, and say, "Wow, you were so lucky to get such gorgeous light right when you were there with your camera!"
The smart ones eventually come to realize that you make your own luck.
You've just put yourself ahead of 95% of the millenials here by saying that. The only way to become great at ANYTHING is to admit that you aren't, and work on improving yourself.
Being junior isn't a bad thing. Everyone starts at the beginning, even the prodigies. The bad ones are juniors that attempt to skip the learning process by claiming to be great, not the ones who do like you are and put in the effort to learn.
The difference between you and the typical millenial, at least the ones that I've had the misfortune of working with over the years, is that they think they're good, and don't listen to the folks around them who've actually DONE the work before.
"I don't know if I agree with this. Some people are born with incredible talent in various areas."
The only talent humans are born with is the ability to construct their own future.
Those who lack talent and experience often believe that success is predicated on luck. They see spectacular photographs taken in times of perfect light, and say, "Wow, you were so lucky to get such gorgeous light right when you were there with your camera!"
The smart ones eventually come to realize that you make your own luck.
Good for you, standing up for yourself.
I think if you hang out with "programmers" long enough, you'll learn that the worst ones spend the majority of their time complaining about the shortcomings of others' "programming" techniques or methodologies. In reality, there is no de facto standard modus operandi for the nirvana of any code, and if you want to learn, it's best to just keep an open mind.
I think if you hang out with "programmers" long enough, you'll learn that the worst ones spend the majority of their time complaining about the shortcomings of others' "programming" techniques or methodologies. In reality, there is no de facto standard modus operandi for the nirvana of any code, and if you want to learn, it's best to just keep an open mind.
"Good luck figuring out what "a" "aa" or "aaa" mean."
It is the slow scream of death march.
It is the slow scream of death march.
Fundamentally, you need to learn your craft. I have just inherited a large project based on Hibernate. I dislike it because there is all this crap between me and the database. I am proficient in SQL as well as Java and I don't like masking a very powerful language with a weaker Java-centric abstraction. If you are going to develop backends you need to understand databases and SQL. If you don't you will end up with an application that doesn't scale and is difficult to maintain.
Sorry to hear that you don't like Hibernate. I'm using it for a project right now, and I greatly prefer it to ActiveRecord. The trick is to use a framework (yes, a framework!) like Grails to autogenerate a lot of the configuration crap for you.
I suspect that your large project was built by "Java Engineers" who tried to stuff way too much into the ORM layer. That's an abuse of the tool, not an indictment of the tool itself.
I suspect that your large project was built by "Java Engineers" who tried to stuff way too much into the ORM layer. That's an abuse of the tool, not an indictment of the tool itself.
It was definitely done by "Java Engineers", but the ORM layer is pretty clean. My problem is that the Java way is very class-centric, not really OO. Why use a class at all, if all you have are getters and setters? It makes sense to me for the ORM layer just to build a list or hash from the result set. A class has no intrinsic benefit, because it's just a struct with extra baggage. One way to get the SQL complexity out of the way is to use a stored procedure, but as far as I can tell Hibernate doesn't support them.
Lets see I can use Rails and build something or I can spend my time building something like Rails from scratch. Not a tough choice. The top ten percent probably don't reinvent the wheel when they don't have to. Do you write all your own libraries too? Maybe your situation doesn't fit the mold but your claims about efficiency and programming prowess are a bit absurd.
> The top ten percent probably don't reinvent the wheel when they don't have to.
True, but they can invent the wheel because there isn't one, and they can do so in a way that others will find it useful as well. It is a different point than edw519 is making, but what he said made me think about where I disagreed and why. The purpose of code libraries, is to make everyone more efficient, by solving a problem so others don't have to. If that means a programmer can produce twice as much functionality within a given time frame, or is able to produce any functionality at all where he couldn't otherwise, there is still a net benefit for everyone. This should not be scoffed at; it is the reason why we are able to produce software as featureful and useful as we do. Imagine each of the XFCE, KDE, and GNOME teams having to rewrite X.org all over again, and how much less each of those desktops would have to offer right now if they did. I'm willing to trade useful functionality sooner for less machismo.
But libraries don't always achieve this, and the degree to which it doesn't determines which people will be motivated to create a replacement. If a framework solves a common problem, but does so in a painful, unwieldy, or hard to understand way, some hacker out there will probably think it a better, more efficient choice to just write and use a new solution. It might be a fork of or series of patches to the original framework, or it may be an entirely new codebase -- which of these routes to follow is a judgement call. Nevertheless, it requires what I think is an important distinction, which is the ability to not just understand what problem the framework solves, but how it solves that problem. And not understanding it just in following what each line of code does, but why what steps it takes work. At that point, you end up leveraging a framework far more that relying on it. If something tomorrow were to happen that required you leave it behind, it would be a pain in the ass, but not a brick wall.
There is also the question, more important that the above in my mind, of understanding if you actually have the problem the framework solves, or if you are attempting to shoe-horn. But I worry that might be a bit off-topic of this particular thread, and would probably warrant another 3-4 paragraphs of musing.
True, but they can invent the wheel because there isn't one, and they can do so in a way that others will find it useful as well. It is a different point than edw519 is making, but what he said made me think about where I disagreed and why. The purpose of code libraries, is to make everyone more efficient, by solving a problem so others don't have to. If that means a programmer can produce twice as much functionality within a given time frame, or is able to produce any functionality at all where he couldn't otherwise, there is still a net benefit for everyone. This should not be scoffed at; it is the reason why we are able to produce software as featureful and useful as we do. Imagine each of the XFCE, KDE, and GNOME teams having to rewrite X.org all over again, and how much less each of those desktops would have to offer right now if they did. I'm willing to trade useful functionality sooner for less machismo.
But libraries don't always achieve this, and the degree to which it doesn't determines which people will be motivated to create a replacement. If a framework solves a common problem, but does so in a painful, unwieldy, or hard to understand way, some hacker out there will probably think it a better, more efficient choice to just write and use a new solution. It might be a fork of or series of patches to the original framework, or it may be an entirely new codebase -- which of these routes to follow is a judgement call. Nevertheless, it requires what I think is an important distinction, which is the ability to not just understand what problem the framework solves, but how it solves that problem. And not understanding it just in following what each line of code does, but why what steps it takes work. At that point, you end up leveraging a framework far more that relying on it. If something tomorrow were to happen that required you leave it behind, it would be a pain in the ass, but not a brick wall.
There is also the question, more important that the above in my mind, of understanding if you actually have the problem the framework solves, or if you are attempting to shoe-horn. But I worry that might be a bit off-topic of this particular thread, and would probably warrant another 3-4 paragraphs of musing.
"""It's to make mediocre programmers more likely to produce something of value and to make poor programmers capable of producing anything at all."""
You make this sound as if you are the great programmer who does not use frameworks but instead reinvents the wheel every time.
Are you really sure you do not use frameworks or libraries in your own work?
You make this sound as if you are the great programmer who does not use frameworks but instead reinvents the wheel every time.
Are you really sure you do not use frameworks or libraries in your own work?
Okay great. Well, you go ahead and hack up your project in assembler, making sure to build everything (including the network stack) from scratch. Let's have a race. If only all of our competitors were as misled and arrogant as you. :)
Thinking outside the box, and doing things in the non-approved way, is what gives you a competitive edge over your competition.
If it makes sense to hack up a project in assembler, do it. It may give you a massive advantage.
If it makes sense to hack up a project in assembler, do it. It may give you a massive advantage.
Yes. That's true. But that's not what is being discussed. What is being discussed is whether or not frameworks and high level languages exist solely to make the bottom 90% more productive.
My comment illustrates the fact that criticizing those two things in particular is beyond silly. Essentially, I'm saying: Where is the limit? Unless you code everything, from scratch, every time, in assembler... You're using a high level language or a framework.
And you should be... The main point of them is to save time. They don't solve all problems obviously, but they solve the kinds of problems that you don't want to solve over and over and over.
My comment illustrates the fact that criticizing those two things in particular is beyond silly. Essentially, I'm saying: Where is the limit? Unless you code everything, from scratch, every time, in assembler... You're using a high level language or a framework.
And you should be... The main point of them is to save time. They don't solve all problems obviously, but they solve the kinds of problems that you don't want to solve over and over and over.
I once implemented CGI in Scheme. It's a long story involving trying to deploy to a shared hosting environment. I could implement CGI in most languages I know in under an hour, but if somebody already wrote a CGI library, I'll just use that.
If the details of passing data over HTTP and interacting with a database aren't a critical part of my project, I'm not going to do it by hand. I'll find some existing library or framework to do it for me. It's not that I can't produce something without help. It's that I have a problem I want to solve, and it isn't how to communicate over HTTP or store and fetch my data efficiently.
If the details of passing data over HTTP and interacting with a database aren't a critical part of my project, I'm not going to do it by hand. I'll find some existing library or framework to do it for me. It's not that I can't produce something without help. It's that I have a problem I want to solve, and it isn't how to communicate over HTTP or store and fetch my data efficiently.
The more people talk about J2EE, the more I think it was invented to give programmers busywork and multiply their workload with no increase in productivity.
Sort of reminds of project management software: it's just there to keep the project manager busy.
Frameworks - used properly - can be INCREDIBLY helpful.
Why develop my own routing code when there's already a robust, well-tested version available? Or validation code? Or payment authorization code?
Though it needs to be said that the number one thing a good framework does is GET OUT OF YOUR WAY. I've seen some Java frameworks that take an hour to put together a simple Hello World and that's just nonsense.
Currently I'm using Kohana, which is nice because it's really very simple and easy to extend. So far I've been able to spend so much more of my time actually writing business logic instead of routing logic and the like.
Why develop my own routing code when there's already a robust, well-tested version available? Or validation code? Or payment authorization code?
Though it needs to be said that the number one thing a good framework does is GET OUT OF YOUR WAY. I've seen some Java frameworks that take an hour to put together a simple Hello World and that's just nonsense.
Currently I'm using Kohana, which is nice because it's really very simple and easy to extend. So far I've been able to spend so much more of my time actually writing business logic instead of routing logic and the like.
Unfortunately, JSR-168 compliant portlets are perhaps the crowning example of horrible implementations of an insane standard.
Was anyone else put off by "And, if you want to kill your ex-girlfriend, there's really no substitute for a ball-peen hammer"?
I get it's a joke, but violence against women, when used in a semi-professional context in a community of software engineers is one of those things that keeps more women out of the field in the long run.
I'm not trying to be PC intentionally -- it just struck a raw nerve for me.
I get it's a joke, but violence against women, when used in a semi-professional context in a community of software engineers is one of those things that keeps more women out of the field in the long run.
I'm not trying to be PC intentionally -- it just struck a raw nerve for me.
That's just.... ridiculous. The main thing that keeps women out of the industry is the fact they don't want to be in the industry and for you to suggest otherwise, is sexist.
This is about as ridiculous as trying out one bad programming language and then writing an article titled "Why I Hate Programming Languages". Clearly the author has a problem with one particularly bad set of frameworks he's dealing with now, and one set of framework-making mentalities. Yes, there are bad frameworks. There are good frameworks too. I don't imagine anyone draws their own buttons on the screen anymore. To continue the discussion in any general format is useless, since there are countless examples of bad frameworks and countless counter-examples of good frameworks. A more compelling discussion would be one on what makes certain frameworks useful rather than trying to place a final value judgement on the idea entirely.
I feel the analogue here is a bit off.
I'd say a framework is more like a factory that produces a variety of fixed-size spice racks (among with other products). You have to learn what button to press to get the right ones, and the spice racks produced will never be exactly how you want them to be.
If you want to quickly generate lots of generic spice rack, then a spice rack factory is all you need. But if you want something really outstanding and unique, then a factory may be anti-productive, and you are better off building it with your own hands.
I'd say a framework is more like a factory that produces a variety of fixed-size spice racks (among with other products). You have to learn what button to press to get the right ones, and the spice racks produced will never be exactly how you want them to be.
If you want to quickly generate lots of generic spice rack, then a spice rack factory is all you need. But if you want something really outstanding and unique, then a factory may be anti-productive, and you are better off building it with your own hands.
The essay itself is funny and rings true, but then in the comments the author says:
"What I'd really like to find are some appropriate libraries that I can use to provide several kinds of functionality for my project."
And then lists a bunch of high-level website functionality requirements (user accounts, content management, etc). I realize that the J2EE landscape was drowning in complexity and was pretty dismal in 2005, but this guy doesn't understand the issues involved in developing web applications.
First, to suggest that individual libraries can provide re-usable high level web application code is completely ludicrous. It can't work for so many reasons:
* All those libraries will have to interact, and the interface between them will be complex. If they do work together they will end up being tightly coupled and before you know it you have a framework.
* High level functionality that includes data models, persistence, and presentation layers is not generic enough to effectively be a library. The complexity and configuration would quickly balloon out of control before it met even the requirements of 5% of web applications.
* Such libraries would end up being far more constricting than a traditional framework. A good example is Drupal, which is a very powerful framework/CMS with an impressive hook system, and an extremely high code to functionality ratio. Anything you might want to do with a website can probably be done in Drupal using a combination of existing modules, and you can write additional modules that access almost any part of the system and modify its behavior. The problem is that fine-tuning of the interface or certain kinds of customizations become very difficult under the crushing weight of the underlying assumptions that Drupal makes to enable it's magnificent generic-ness. The result is that all the various sites made with Drupal end up feeling very Drupal-y and there's a disincentive to really design your UI from the ground up and create a very optimized application.
What J2EE has blinded the author to is the fact that web frameworks exist to solve the most common problems that come up over and over again in web development. He needs to go write a few PHP applications to get a feel for the issues, then try something lighter-weight like Django or Rails that confronts those issues directly and then basically gets out of the way. In the first half of the decade it was hard to find a good lightweight framework because people were still wrapping their heads around the actual issues that needed to be solved. Nowadays, not so much.
"What I'd really like to find are some appropriate libraries that I can use to provide several kinds of functionality for my project."
And then lists a bunch of high-level website functionality requirements (user accounts, content management, etc). I realize that the J2EE landscape was drowning in complexity and was pretty dismal in 2005, but this guy doesn't understand the issues involved in developing web applications.
First, to suggest that individual libraries can provide re-usable high level web application code is completely ludicrous. It can't work for so many reasons:
* All those libraries will have to interact, and the interface between them will be complex. If they do work together they will end up being tightly coupled and before you know it you have a framework.
* High level functionality that includes data models, persistence, and presentation layers is not generic enough to effectively be a library. The complexity and configuration would quickly balloon out of control before it met even the requirements of 5% of web applications.
* Such libraries would end up being far more constricting than a traditional framework. A good example is Drupal, which is a very powerful framework/CMS with an impressive hook system, and an extremely high code to functionality ratio. Anything you might want to do with a website can probably be done in Drupal using a combination of existing modules, and you can write additional modules that access almost any part of the system and modify its behavior. The problem is that fine-tuning of the interface or certain kinds of customizations become very difficult under the crushing weight of the underlying assumptions that Drupal makes to enable it's magnificent generic-ness. The result is that all the various sites made with Drupal end up feeling very Drupal-y and there's a disincentive to really design your UI from the ground up and create a very optimized application.
What J2EE has blinded the author to is the fact that web frameworks exist to solve the most common problems that come up over and over again in web development. He needs to go write a few PHP applications to get a feel for the issues, then try something lighter-weight like Django or Rails that confronts those issues directly and then basically gets out of the way. In the first half of the decade it was hard to find a good lightweight framework because people were still wrapping their heads around the actual issues that needed to be solved. Nowadays, not so much.