*groan* no, not another blog referring to that stack trace as a reference for "Java Frameworks Suck". Sometimes I regret having posted that.
I completely agree with your final point, every abstraction does have a cost - and you need to be sure that you are getting the value you are comfortable with.
Also I have to say, that post is a little old and I got rid of three of the biggest offenders - so I use Jetty instead of Tomcat/JBoss and Acegi + Spring WebFlow are out. Also note that there is a Ruby on Rails stack trace linked from that blog post, and that makes for interesting reading. The point I try to make is that if you start using the size of a stack trace to compare frameworks - I mean, who knows, once you flesh out your OCaml framework and decide on some ORM or equivalent, security, page-state and other stuff - then run Dtrace or something and look at the results - you may be surprised.
You can find out more about the actual (open source) application "responsible" for that stack trace here: http://jtrac.info
jaked
· 2 years ago
You're right, the big stack trace is kind of a strawman. I'm not arguing specifically against Java frameworks, but rather against the thinking I characterize (caricature?) above.
As you say, the size of the stack trace isn't a perfect metric, but once we launch I'll post the deepest stack trace I can find.
andrey kartashov
· 2 years ago
Hey, Jake! As always, you bring up some interesting points, but I daresay that there *are* some details I don't have to think about. More than a few actually. Think about it, the stacktrace you quoted is just the tip of the iceberg, there is whole OS, many layers deep behind it. There is also hardware, a complicated beast all in itself. The simple reality is that today nobody really understands 'the whole thing', there are many layers of abstraction involved. So how do we deal with them? - We mostly don't;) We choose the set of tools/frameworks that solves the problem we are trying to solve. Nobody insists on using as many as possible, there is no 'standard' software stack either. It's like a toolbox, you pick and choose what you need. You try it, you measure performance, you identify the bottlenecks, only at that point do you start paying attention to details. But not to all details, just the ones that matter. You keep what works well and you replace or fix what doesn't. And, yes, you pretty much completely ignore the rest.... So, as you've pointed out, there is a cost, but do we avoid frameworks? - No. We simply choose them based on whether or not they solve our problem. Or to put it another way, if you can't clearly explain why you are using something, you probably shouldn't be using it.
Jake
· 2 years ago
Hi Andrey. I think we are in basic agreement: complexity has a cost which must be justified. You put it very well in your last sentence.
My argument is that too often we take on complexity without justification. Extremely abstract, extremely flexible frameworks are extremely complex, and yet hardly any application needs the flexibility they provide.
You make a good point that the stack includes everything from the hardware on up. Still, when something goes wrong (be it bug, security hole, or performance problem), it can go wrong anywhere in that stack. This means we have to keep the stack as shallow and as simple as possible in order to get our jobs done.
(A data point: check the Facebook job listings, where they have open positions for PHP internals and performance experts--this part of the stack, at least, is not a black box for them.)
Unnecessary complexity is a drain on resources, and a startup can't afford that. While we'd love to hire some OCaml internals and performance experts because they're probably great hackers, we hope that by keeping things simple we can spend most of our time at the top of the stack, writing the applications that are our business.
Michael Lee
· 2 years ago
Hey Jake
This is a rather odd set of posts. And not to belabor the point but Isn't what you're saying somewhat obvious? Who would disagree with the following statements: abstractions have costs directly and indirectly associated with them; introducing complexity into a computer system requires justification.
Your statement, "... we take on complexity without justification.," may be true but usually it is justified to some degree. It may be long or short sighted or just plain wrong--lack of imagination, experience, etc... Regardless, there's usually a justification.
Anyways, good luck with your startup.
Jake
· 2 years ago
Hi Michael. What I'm saying may be obvious to some, but it certainly bears repeating. As you point out, sometimes the "justification" for overly complex systems is mistaken.
Mike "Szii"
· 2 years ago
While it looks horrendous, the reusability is there. Rolling your own is great, if you have the QA staff and time (and time-to-market!) to back it up.
When you need to execute fast, prepackaged code is a great way to do it. While "fast and tight" is an awesome goal, sometimes you just have to say "you know, I just need it to WORK. I can optimize later if it's a huge problem." You can't be blind about it, but if you try to optimize everything, everywhere you'll optimize stuff that doesn't really need to be optimized.
If the run-time doesn't suffer, doesn't choke the hardware when you scale it...who cares how big the stack is? After all, you just scan right over it with the scroll bar. /shrug
In perspective, something like Gentoo is arguably the "fastest" linux distribution due to the compilation tweaking you can do. But, really, how many do it? Especially compared to the number of RH/Debian boxen that run quite well? And how many Gentoo "oopses" did you go through (rolling your own) to get some semblance of speed over a RH/D distro in which you didn't REALLY need that speed anyways?
IMHO, chase run-time and not stack-length. You can overthing/overengineer/overtweak anything. The skill/art/knowledge is not always what to tweak but what NOT to tweak. (Not that I know it myself! :)
Found this through a Craigslist posting. Haven't been in the web world in a number of years (re, CGI and PHP 1.0), so going to go check out this OCaml stuff. Good luck! Glad to see people are still doing startups here in the Valley! :)
Dave
· 2 years ago
I could not agree with you more. I have never been a fan of frameworks. I feel that in most cases they add unneeded complexity and abstraction for systems that have no need for it in the first place.
--Dave
Marc Conley
· 2 years ago
I am a senior J2EE developer (25 years experience in the field of software development...lots of paradigms/languages under my belt). I agree with your assessment of Java/J2EE community over-complicating things in an attempt to follow prevailing design/architectural wisdom. I personally feel that a good developer doesn't need near that much imposed structure to do the right thing. And someone is paying for all those extra layers and design work -- the customer. I personally prefer a language called newLisp over ocaml, although ocaml looks pretty cool as well (especially compared to Java). I am located in GA and can't move or really switch from my full-time gig currently -- it's too good an opp. But I am interested in startups and equity and those kinds of things. Been there, done that...wouldn't mind doing it again. :-) It can be a very exciting and creative and powerful environment where one can show their stuff and be rewarded for it accordingly.
Victor
· 2 years ago
I totally agree that the Java for Web is somewhat overcomplicated.
Once, I have written a small web-app in Python+Clearsilver+(Sqlite and PostgreSQL afterwards), as a CGI app, and then as a mod_python on Apache-HTTPD-2 one. This web-app processed user input, queried the DB, constructed the HTML on the fly (out of more than 300 rows of data fetched from the DB) faster than the Tomcat loads its default greetings page.
Next time I would like to try the OCamlnet, though, from my point of view, it lacks some features.
Paul
· 2 years ago
I'm curious, what do you use for generating html?
Raoul Duke
· 1 year ago
I wouldn't mind a framework if it were really honestly a good pay-as-you-go model. On the other hand, p-a-y-g taken too far means you are working in C++ with no garbage collection, yucky-poo.
All Comments
I completely agree with your final point, every abstraction does have a cost - and you need to be sure that you are getting the value you are comfortable with.
Also I have to say, that post is a little old and I got rid of three of the biggest offenders - so I use Jetty instead of Tomcat/JBoss and Acegi + Spring WebFlow are out. Also note that there is a Ruby on Rails stack trace linked from that blog post, and that makes for interesting reading. The point I try to make is that if you start using the size of a stack trace to compare frameworks - I mean, who knows, once you flesh out your OCaml framework and decide on some ORM or equivalent, security, page-state and other stuff - then run Dtrace or something and look at the results - you may be surprised.
You can find out more about the actual (open source) application "responsible" for that stack trace here: http://jtrac.info
As you say, the size of the stack trace isn't a perfect metric, but once we launch I'll post the deepest stack trace I can find.
As always, you bring up some interesting points, but I daresay that there *are* some details I don't have to think about. More than a few actually. Think about it, the stacktrace you quoted is just the tip of the iceberg, there is whole OS, many layers deep behind it. There is also hardware, a complicated beast all in itself. The simple reality is that today nobody really understands 'the whole thing', there are many layers of abstraction involved.
So how do we deal with them? - We mostly don't;) We choose the set of tools/frameworks that solves the problem we are trying to solve. Nobody insists on using as many as possible, there is no 'standard' software stack either. It's like a toolbox, you pick and choose what you need. You try it, you measure performance, you identify the bottlenecks, only at that point do you start paying attention to details. But not to all details, just the ones that matter. You keep what works well and you replace or fix what doesn't. And, yes, you pretty much completely ignore the rest....
So, as you've pointed out, there is a cost, but do we avoid frameworks? - No. We simply choose them based on whether or not they solve our problem. Or to put it another way, if you can't clearly explain why you are using something, you probably shouldn't be using it.
My argument is that too often we take on complexity without justification. Extremely abstract, extremely flexible frameworks are extremely complex, and yet hardly any application needs the flexibility they provide.
You make a good point that the stack includes everything from the hardware on up. Still, when something goes wrong (be it bug, security hole, or performance problem), it can go wrong anywhere in that stack. This means we have to keep the stack as shallow and as simple as possible in order to get our jobs done.
(A data point: check the Facebook job listings, where they have open positions for PHP internals and performance experts--this part of the stack, at least, is not a black box for them.)
Unnecessary complexity is a drain on resources, and a startup can't afford that. While we'd love to hire some OCaml internals and performance experts because they're probably great hackers, we hope that by keeping things simple we can spend most of our time at the top of the stack, writing the applications that are our business.
This is a rather odd set of posts. And not to belabor the point but Isn't what you're saying somewhat obvious? Who would disagree with the following statements: abstractions have costs directly and indirectly associated with them; introducing complexity into a computer system requires justification.
Your statement, "... we take on complexity without justification.," may be true but usually it is justified to some degree. It may be long or short sighted or just plain wrong--lack of imagination, experience, etc... Regardless, there's usually a justification.
Anyways, good luck with your startup.
When you need to execute fast, prepackaged code is a great way to do it. While "fast and tight" is an awesome goal, sometimes you just have to say "you know, I just need it to WORK. I can optimize later if it's a huge problem." You can't be blind about it, but if you try to optimize everything, everywhere you'll optimize stuff that doesn't really need to be optimized.
If the run-time doesn't suffer, doesn't choke the hardware when you scale it...who cares how big the stack is? After all, you just scan right over it with the scroll bar. /shrug
In perspective, something like Gentoo is arguably the "fastest" linux distribution due to the compilation tweaking you can do. But, really, how many do it? Especially compared to the number of RH/Debian boxen that run quite well? And how many Gentoo "oopses" did you go through (rolling your own) to get some semblance of speed over a RH/D distro in which you didn't REALLY need that speed anyways?
IMHO, chase run-time and not stack-length. You can overthing/overengineer/overtweak anything. The skill/art/knowledge is not always what to tweak but what NOT to tweak. (Not that I know it myself! :)
Found this through a Craigslist posting. Haven't been in the web world in a number of years (re, CGI and PHP 1.0), so going to go check out this OCaml stuff. Good luck! Glad to see people are still doing startups here in the Valley! :)
--Dave
Once, I have written a small web-app in Python+Clearsilver+(Sqlite and PostgreSQL afterwards), as a CGI app, and then as a mod_python on Apache-HTTPD-2 one. This web-app processed user input, queried the DB, constructed the HTML on the fly (out of more than 300 rows of data fetched from the DB) faster than the Tomcat loads its default greetings page.
Next time I would like to try the OCamlnet, though, from my point of view, it lacks some features.