91–100 of 127 posts
Earlier quoted context omitted.
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.
That sure sounds like personal conviction to me.
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 prog…
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. :)
If it makes sense to hack up a project in assembler, do it. It may give you a massive advantage.
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_…
You should hang around better programmers.
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 prog…
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 fra…
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.
Earlier quoted context omitted.
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 fra…
"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 learn woodworking when you can buy furniture at Walmart? Some people like craftsmanship and others like frozen dinners.
Earlier quoted context omitted.
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" re…
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.
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_…
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."
"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.