While plowing through the comments on Bruce Eckel's The departure of the hyper-enthusiasts I found this piece of nonsense (not from Eckel):
Perl solved the problem of implementing a portable glue language for data processing. Then it was adapted to the initial web data processing mechanism using CGI. Its lack of scalability to build consistent and maintainable apps opened the field to newcomers like PHP.
Discussions like this are fascinating because you can see how much of themselves programmers wrap into the languages they use and the technology choices they make. It reminds me of that, "You are not your job. You are not the contents of your wallet" speech from Fight Club: You are not your language. (Right?)
Posted from cwinters.com; read original
Re:Funny
chromatic on 2005-12-21T19:36:41
How do you optimize to help novices without hobbling the experienced?
Re:Funny
ziggy on 2005-12-21T20:03:01
I dunno, exactly. But Rails looks like it's doing a good job. Maybe there are some lessons to take away from that...
Step away from the web, and Python did a better job than Perl in that particular respect. Zope is nothing if not a rat's nest of expert coding. Totally befuddling in its own right, but the Zope team wasn't overly hobbled by Python's help-the-newbies approach.
Haskell, on the other hand, goes to the opposite extreme: hobbling the novices and helping the experienced.;-) Re:Funny
chromatic on 2005-12-22T01:31:55
I'm starting to think people are learning the absolute wrong lessons from Rails.
The right lesson probably starts with "Extract frameworks -- don't build them." Of course, one probably right lesson that some people could learn from Rails is that a language with expressive abstractions can be easier to program in than one without.
Re:Funny
ziggy on 2005-12-22T15:34:27
Those are certainly two important lessons to learn.
Equally important is the Perl dictum that easy things should be easy, and hard things should be possible. Eckel's experiences with EJB and Zope highlight that big do-everything frameworks (especially when designed in advance) show are a lesson on how to optimize the simplicity out of a solution.
Abstraction is important, but not at the expense of simplicity. C++ and Lisp are proof that powerful but befuddling abstractions don't buy much value in the large (across the industry, that is). call/cc, operator overloading and y-combinators are great, but they don't help me add two numbers, or sprinkle logging statements for instrumenting a big system.
Interestingly, there are a couple of anti-lesson to take away from here. Python, Perl, Tcl and Ruby are all equally capable languages for development today. Tcl loses out because it optimizes for procedural programming, and interfacing with C/C++ at the expense of a single object model, or a coherent library of extensions. Python got something very important wrong, but I don't know precisely what; the fact that there are about three frameworks for any given problem domain is a symtom that something is prematurely optimized in the Python world.
Ruby, on the other hand, is deeply infused with XP and TDD. Perhaps the most important aspect of Ruby isn't the language design or implementation, but the community that has coalesced around it. If so, the reason why Rails was written in Ruby isn't a statement about Perl or Python, but a statement about the friendly microclimate surrounding Ruby that promotes agile development.Re:Funny
chromatic on 2005-12-22T20:08:47
Perhaps Python's problem is that perfect isn't better. I can only see it as a very reactionary language, despite a handful of nifty projects (Psyco, PyPy, py2exe, Iron Python, Jython) that make me jealous. Perhaps that's a failure of my imagination.
Perhaps part of Ruby's success was its obscurity, in that the type of people who go looking for a language such as Ruby when it doesn't have English documentation or libraries or a large English-speaking community are the kind of people who can write really good code in any language.
Re:Funny
perrin on 2005-12-22T16:10:42
They keep saying that, but then I wonder why anyone would build such a big framework with all the helper classes and code generation if it was just for one project (i.e. Basecamp). If I was on a project and we were building that much infrastructure, I'd consider it a big mistake. I think they either planned to make Rails a framework from the start (in which case the whole "extract, don't build" thing is highly suspect) or they massively overengineered the design of Basecamp.
