Possible. Nathan Hamblen (Coderspiel) proves that there is life outside the IDE, using TextMate, Buildr, Jetty and JavaRebel:
A decentralized environment supports any underlying technology that the operating system supports. While IDEs struggle to keep up with the one or two alternative JDK languages to which they’ve decided to allocate resources, text editors support them all by default. As it turns out, languages that are less hindered by standards bodies incorporate exciting new features faster than IDEs can wrap them up in GUI packaging.
Too many lines. Speaking of IDEs, Steve Yegge has a long rant against them, more specifically the forests of code that prey on and feed them. I find it amusing that Steve, who can’t edit himself, rants against too many lines of code. Fortunately, Reg rewrites the entire rant in Ruby, so you only need to read the key points, and also reminds us of the real issue:
Instead, consider the cultural forces at work. Cultural problems cannot be solved with technology. If you are an advocate for change, ask yourself what sort of cultural change is needed, not what sort of technical problems need to be solved.
Minor correction. Discipline and Punish responds with a well made point:
And that’s when the ultimate reality of experience produces an even more terrifying truth: the failure space is much, much larger than the solution space. For every right way there are a thousand wrong ways that lead to doom. Mathematically, it’s hopeless.
Unfortunately:
Craftsmen are supposed to be different. They’re supposed to respect their tools and appreciate the great dangers that lie therein. They are, one might begin to naively hope, potentially the heroes who can slay the dragon of ignorance and save the day.
Craftsmen (gender non-specific) are different, they are responsible for finding the best tools, creating them when necessary. It’s the lay person who attempts to slay dragons by fixing their plumbing with a swiss army knife.
False dichotomy. Jeff Atwood: “Users couldn’t care less whether the underlying code is pretty.” Jeff cites as proof that ugly-as-hell Bugzilla is still being used by Apache. Except that it’s deprecated in favor of JIRA, new projects are set up to use JIRA and old ones allowed to choose their migration path. I would not approve any project I work on to use Bugzilla.
User’s don’t directly care what the underlying code looks like, but they do care that it meets their expectations. And if the only way to meet their expectations is make the code pretty, and therefore easy to maintain, so be it. The risk of assuming the user doesn’t care what the code looks like, is creating software the user doesn’t care to use. At all.
Like talking to a radio. JJD:
You probably noticed that the REST community has stopped talking with me. … These were the only two people that had the courage to go to the end of the discussion even though they saw some limitations to the REST approach. Others, have stopped all communication as soon as they understood the problems with REST.
Since I was named somewhere in that post, I may be one of those REST communitists. So let’s be cleared on why there are no substantial responses coming from my end. Until we can agree the Sun rises every day, there’s no point in us debating the, and I’m not denying there are, merits and drawbacks of DST, or what would be the most appropriate dates.
Photo, by christynski.