From: Alvin Ryder Date: 2006-09-04T13:01:53+09:00 Subject: Re: Joel Spolsky on languages for web programming David Vallner wrote: > Utter pants. I mean, you used the word "bloat", which should make people > lose any debate by default. > I don't like bloated software, it is unnecessary. > Alvin Ryder wrote: > > Java and C# are no guarantee for success. > > Neither is Ruby / Rails. *No technology* is a guarantee for success, no > technology ever was, and I'll bet a gold bar against a plastic spoon no > technology ever will. Technology used is a very important decision to > make, but it never single-handedly moves you from doable to undoable or > vice versa. > There are many factors required for success and I don't believe any one factor guarantees it but interestingly it can take so much as one element gone wrong to ruin everything. > > you seem to need 10 instead of 3 people and 5 times as long. > > Pure, unadulterated shite. Give me numbers. Credible statistics and real > research, not random anectodal success stories that are too pathethic to > sell Herbalife diet pills. > The "10 to 3" ratio wasn't meant to be taken literally surely you don't think otherwise? And can you tell me where can I get such "credible statistics and real research" from? Are you saying all languages yield the same level of productivity? If they aren't equally productive then how much more productive is Java over C++ or VB over assembler? Do you need "credible statistics and research" to answer the question? > Also, initial development cost isn't a very important factor. Recalls > your uni software lifecycle charts about how much of a project's life is > maintenance. For a successful project, the numbers are very much true. > With a successful product comes the responsibility of supporting it and > keeping it successful, and in some cases this responsibility creates > ongoing costs that dwarf the initial development horribly. > I disagree, the initial cost is vital. Most projects get approved or not approved based on that initial cost and if that money is drained on developers trying to tame an unwieldly platform instead of building the actual system then we have a problem don't we? > > Ok, sure Java's OO may be nicer than Perl 5's but once you brew > > HTML/Javascript/JSP/JSTL/EL/tags/JSF or Struts together the result > > isn't exactly what I'd call pretty. Java is in no way a safe bet. > > Noone cares about pretty. It's also a completely irrelevant issue when > deciding on implementation language if you're at least remotely responsible. > I care about pretty. > > How about C#, well it runs in Windows and without serious and expensive > > firewalls you just can't go anywhere near the Internet. > > You need to tighten off Unix-based servers too. Heck, there are even > serious and expensive firewalls for Linux around too, because not > everyone has an in-house iptables guru. > True, no platform is 100% impervious to attack but some are less secure than others. > > Ruby and Rails just get straight to the point. They make common things > > easy and elegant. > > Sometimes things aren't so common. Ruby and Rails DO have faults. Just > google around, I'm not going to go namecall out of respect and out of a > sense of realism - every technology has flaws and any mudslinging would > only lead to a pointless flamewar. Sometimes they are uneducated rants > and / or whining, but some of them are valid. > Yes I know all platforms have faults and wish lists, I didn't think otherwise. > And if you do NOT go out and learn about these flaws, and what impact > they could have, and be fully aware of them when making the > implementation technology decision on a project to consider the severity > of their impact under the circumstances of your project, then your > decision may cause a lot of trouble. > Fair enough, I agree. I think software should be published with specifications and limits as they do in other industries. This is a 100 ohm resister +/- 2%, capable of running in these temperators, it handles this much power ... but in software its just "blah" you have to discover the limits yourself (ouch). > > If execution speed really is a problem then I reckon > > it'll get fixed. > > Speaking purely theorethically, Ruby can not be made as performant as > Java or C# could be made if they had ideally performing implementations. > Latent typing makes it almost impossible to do certain optimizations as > static typing does. That's pure fact. Of course, it's not saying Ruby > can't be fast enough - but there have been people with more experience > at the performance side of software development that talked much better > about that > I'm not sure how fast or slow Ruby is but if it's as fast as Perl I'll be happy enough. Yes I know C is faster but I need fast development times too. > > As for developing major sites with Rails, most managers don't have the > > balls. > > I advise you go on throught freshman year on a management school. It's > the managers' job to "not have balls" and risk when there's apparently > nothing to be had from taking it. If you want to be a Ruby advocate, you > need to be able to persuade them, not yourself, of the advantages or > using it. > I've worked with Harvard level managers, they seemed to think it *was their job to have balls*, which is the opposite of what your saying? I prefer to work with managers that have knowledge, intelligence, energy and conviction to back up their decisions. Besides that the choice of language is usually mine, that's why I gravitate to the more productive ones. In my experience run-time performance is rarely an issue but development time is. > > They'd rather pay millions to get a java solution, it isn't > > their money on the budget so they gutlessly pour it down the java hole > > and hope for the best. If the project fails they blame the team or > > throw more money and bodies at the problem, of course it's not java's > > fault or theirs. > > That's because it's not. Since projects never fail purely on a > technology solution - they fail on results of bad project planning more > often than not (assigning novice programmers to large projects that will > probably go over their heads), mistaken business objectives as whoever > contracted the software finds he isn't really interested in what the > tech demos had to show at all. > > And the stereotype of lazy management that never gets punished is good > to make Dilbert strips from - in real life, it probably doesn't hold No, I've seen it hold in real life too many times, the "pointy haired boss with the corner office" still brings a chuckle out of me. > true outside of a select few huge moloch companies, or on the opposite > side of the spectrum small short-lived hick-led shops where the bosses > kids and nephews gets all sort of crap assigned to get better allowance. > In a well-led company with working internal management processes, when > the shit hits the fan, everyone gets the stink. > > David Vallner Cheers ;-)