Weekly Edition
Return to the Press pageSponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Technologies to Watch: A Look at Four That May Challenge Java's Development Dominance (O'ReillyNet)
(Log in to post comments)
Watch Perl 6.
Posted Oct 20, 2005 18:06 UTC (Thu) by cventers (subscriber, #31465) [Link]
After being so long in the making, the Pugs project is breathing *fire*into Perl 6. Perl 5 was pretty revolutionary, and Perl 6 is clearly
nothing but. There will still be a large crowd of Perl haters, I'm sure,
but what they always seem to miss is just how huge the market for Perl is
(and still is).
Personally, I won't be at all sad to see something as overweight,
restrictive and needlessly verbose as Java lose the limelight. I've been
waiting on that to happen for a long, long time.
Watch Perl 6.
Posted Oct 21, 2005 6:30 UTC (Fri) by beoba (guest, #16942) [Link]
"Needlessly verbose" - A Perl user on Java
Sorry :)
But it *is* verbose.
Posted Oct 21, 2005 16:14 UTC (Fri) by hummassa (subscriber, #307) [Link]
My current cheering project is Ruby on Rails. Do you know why? Because of the "Don't Repeat Yourself" philosphy. If you write something in Java, you have to write (and maintain!) three slightly different copies of everything. Ok, *some* code tools will make it easier on you, but they sometimes prevent the coder from doing some things that would be possible otherwise.I also happen to think "the less lines of code there are, a bug will have less places to hide." :-)
Pugs is a distraction
Posted Oct 22, 2005 5:05 UTC (Sat) by b7j0c (subscriber, #27559) [Link]
Its been frustrating to watch Pugs siphon off energy from the Perl6 project, which was already was a candidate for the most poorly-paced open source project in memory.
The Perl6 team should be working on release-candidate code only. Unless they plan to release Pugs as Perl6, they should stop wasting time on it. Its going to be difficult enough rolling out a new runtime and language syntax at once without the pointless distraction of dicking around with Haskell.
Pugs is a distraction
Posted Oct 22, 2005 18:05 UTC (Sat) by cventers (subscriber, #31465) [Link]
Well, how else do you suggest they go about writing Perl 6 in Perl 6?
Pugs is a distraction
Posted Oct 22, 2005 18:32 UTC (Sat) by b7j0c (subscriber, #27559) [Link]
Its fine to build a prototyping system - but a set of modules for doing this in Perl5 already existed. Also, the tenor of the discussions indicates to me that Pugs has moved beyond a prototyping system and is turning into a full-fledged project on its own, which is unfortunate since it is not the target platform for Perl6, it is slow, it does not utilize Parrot, and it requires a ghc installation.
Pugs is Useful
Posted Oct 25, 2005 4:07 UTC (Tue) by chromatic (subscriber, #26207) [Link]
The latest stable release of Pugs (6.2.10) does indeed target the latest stable release of Parrot (0.30) as a backend. Autrijus is working on a new intermediate language that targets Parrot more fully and effectively even now.
Hacks
Posted Oct 20, 2005 22:01 UTC (Thu) by ncm (subscriber, #165) [Link]
It doesn't take much insight to predict the demise of Java fads: they're all doomed, every one. Tate's skill has been in discerning precisely when each one's number is up.Abandoning type-safety for wild and woolly runtime-typed languages is a familiar pattern among language pundits. Before Bruce Tate went Bruce Eckel. In the toy programs used for teaching, any extra apparatus that only promises to ease maintenance is worse than useless. Such apparatus in Java programs is anyway far too weak to justify its finicky bulk.
Java's designers positively delighted in bolting on elaborate, obligatory apparatus, with a nod to intended function but with most actual usefulness trimmed away. Thus, use of Java exceptions makes code bigger and more complex, and its pervasive object orientation couples programs' components even more tightly. Java 1.5's "generics" relieve the worst demands for pervasive casting, but add no actual power. It's easy to compare almost any language favorably to Java (or, equivalently, to C#).
To build convenience and (immediate) power into a scripting language is easy when performance cost is no object. For a little program, any language will do. A big program needs linguistic structures to help organize it, and it needs to be able to rest most of its weight on those structures. Java has given structural features a bad name because those it provides are too weak to be useful.
The real measure of a language, and of a design philosophy, is not how quickly you can whip up another variation on a theme in one domain. Rather, it's how well it enables its users to package up conveniences and power tools so they may be composed and integrated into systems that haven't been built a thousand times before. Standard C++, for all its historical baggage, is still the only language that even addresses the problem. A well-crafted C++ library can equal the convenience and (immediate) power of a scripting language without sacrificing performance or maintainability.
Someday we will get a language that matches C++'s constructive power and efficiency, without its history or its ponderous build cycle. None has topped the horizon yet, and C++0x will raise the bar higher. In the meantime, we will see thousands of non-standard, barely portable, quick interpreted hacks that, while they do the job, cannot be fitted cleanly into a larger system, or used again even five years later.
Hacks
Posted Oct 20, 2005 23:33 UTC (Thu) by bronson (subscriber, #4806) [Link]
Java's designers positively delighted in bolting on elaborate, obligatory apparatus, with a nod to intended function but with most actual usefulness trimmed away.That is the single best description of Java I have ever heard.
Hacks
Posted Oct 21, 2005 1:02 UTC (Fri) by Richard_J_Neill (subscriber, #23093) [Link]
I prefer to think of Java as not so much "object-oriented" as "object-obsessed". I mean, why does a string have to be an object rather than a data type? Personally, I prefer writing Bash scripts to Java.
As far as I can understand, the "big deal" about Java is platform independence. Except that is isn't really. And if you have an open-source application, who cares about compatibility of *binaries*.
Hacks
Posted Oct 21, 2005 3:41 UTC (Fri) by mdaniel (guest, #33232) [Link]
As far as I can understand, the "big deal" about Java is platform independence. Except that is isn't really. And if you have an open-source application, who cares about compatibility of *binaries*.
The "big deal" about Java's "platform independence" is the common "processor" and libraries against which you code. You think OpenSource cured the notion of compatibility? Tell that to the autotools folks, who have built an empire stringing m4 macros and shell together to determine what kind of strcat you have on your flavor of *nix.
The funny thing is that I'm not a Java zealot; I agree with the ancestor's comment that Java is bloated and exceeeeeeeedingly verbose. That does not, however, compromise that Java provides a common vocabulary (I mean that in terms of the language and especially the libraries) for some of the most powerful and maintainable server-side software I've ever encountered.
Hacks
Posted Oct 21, 2005 8:05 UTC (Fri) by BrucePerens (subscriber, #2510) [Link]
Java was intended to be a language for developing client-side code. Perhaps part of the mis-fit we see is because its main occupation today is converse to the one for which it was designed.Bruce
Hacks
Posted Oct 21, 2005 15:12 UTC (Fri) by mdaniel (guest, #33232) [Link]
Java was intended to be a language for developing client-side code. Perhaps part of the mis-fit we see is because its main occupation today is converse to the one for which it was designed.
With all due respect, something like Jini is what Java was intended to do: network-transparent, device-independent, "roaming" code [think of your fridge telling your PDA that you're out of bread]. The fact that people used it for dancing monkeys when it first came out doesn't make James Gosling any happier than it makes you or I.
And I just said it's verbose, not that it's poor at doing its job. It enables a lot of strong software engineering practices very well. I use this example with my cow-orkers a lot: you have ten seconds to tell me what file contains the class com.foo.CoolClass. Where would you look? How would you solve the same problem in C++?
Hacks
Posted Oct 21, 2005 15:24 UTC (Fri) by doodaddy (guest, #10649) [Link]
"As far as I can understand, the "big deal" about Java is platform independence."
I have several Java coding friends and I've read a book on it twice (but had no need for it). I don't think platform independence matters now. Its a good seller up front, but I haven't heard anyone claim how nice it was to port from Sun to Windows or the like.
The biggest seller, at least by listening to the comments, is "no pointers." While they are there and ready to cause trouble, atleast there are no memory leaks (at least theoretically.) I think this is important because the coders I know that use Java did NOT make computer science a calling. They fell into it and it pays well. And it must be comforting to have a language that you can get hired using, for big bucks, without any deep knowledge of "scary things."
I think the next big seller is momentum. There are more jobs in Java (again, high-paid jobs) than in C++, for instance. Notice that almost all of them are IT projects at both big companies and start-ups. Most of which fail. But who cares about that? I think the failure rate is tied to lack of deeper understanding about software engineerings in general in this knee-jerk Java shops.
Then the next big seller is a forced, huge library. (Another friend always said that what people really want in a government is a benevolent dictator.) Java says that its libraries are complete, required, and beautiful. Many are fine, some are long winded. (There are some definite "collegiate"-type projects-turned-library in there, such as the io stream stuff.) But there is something to say for knowing which toolkit to memorize! You can't really say that C/C++ has a definite thread library, less alone an HTTP or XML library that is official. (Please avoid thinking about Java's GUI toolkit which has about 3 "official" versions.)
And finally, I agree that we have not just an "object obsessed" language (I like that name by the way), but an object obsessed programming culture!
Hacks
Posted Oct 28, 2005 3:05 UTC (Fri) by ttfkam (subscriber, #29791) [Link]
"...but I haven't heard anyone claim how nice it was to port from Sun to Windows or the like."
Most likely because the "port" only involved invoking the JVM on a different system. 99.9% of all programs, as long as they don't use native code, require little or no code changes at all. I know mine haven't. Talk to servlet and J2EE developers as to whether it matters to them what system their code runs on.
Not having (explicit) pointers is definitely a selling point. The C++ standard library is definitely an improvement, don't get me wrong, but the memory leaks and buffer overflows reported by SANS and CERT are a testament to the fact that it's not enough.
As for education, I know far more than a few C programmers that never took the CS/CE path. Hell, I've met more than a handful of CS graduates who can't code well at all. CS is an applied mathematics degree, not a programming degree.
Moving on, the "huge" standard library is indeed big, sure. I, for one, am glad of it. Where is the uniform API for XML and XSLT in C++ so that you can swap out implementations without having to refactor your whole project? JDBC long ago outstripped ODBC in the ease of use department. And it's not like bare CORBA is a fair match with a full, clustering J2EE suite. Are there warts? Sure. AWT/Swing comes to mind. The original I/O library was a big weak. However, having a single, easy to reference and use API for TCP/IP and data I/O should not be ignored.
Java wasn't popular because its APIs were perfect. It was popular because the better alternatives to many of its APIs were harder to use, more error-prone, or simply nonexistant.
Java didn't invent the automatic documentation from code generator Javadoc. That concept had been around for a while. But you must be blind if you didn't notice that the practice became commonplace after Java did it. You probably balk at the size of the API library represented at the following URL: http://java.sun.com/j2se/1.5.0/docs/api/
Me? I balk at those languages that lack it.
Hacks
Posted Oct 21, 2005 8:14 UTC (Fri) by micampe (guest, #4384) [Link]
This Java bashing is getting very very boring.
Hack Hackity Hack Hack
Posted Oct 21, 2005 16:51 UTC (Fri) by GreyWizard (subscriber, #1026) [Link]
This Java bashing bashing is getting very boring. Let's post opinions about the discussion itself without addressing the substantive issues at all. That'll liven things up.
Hacks
Posted Oct 21, 2005 15:26 UTC (Fri) by doodaddy (guest, #10649) [Link]
"Someday we will get a language that matches C++'s constructive power and efficiency, without its history or its ponderous build cycle."
Have you ever looked at D? (digitalmars.com/d/comparison.html) My opinion is still open, but they seem very serious. The newsgroups at the site go into pretty heavy detail picking over each feature.
Hacks
Posted Oct 21, 2005 17:34 UTC (Fri) by daledude (guest, #31448) [Link]
I like D. Im not comfortable using it for anything serious is production yet. I would love to see more momentum behind it. It seems like a great middle between C++ and Java.
Hacks
Posted Oct 21, 2005 23:59 UTC (Fri) by ncm (subscriber, #165) [Link]
A "middle between C++ and Java" is a step backwards. D offers some coding conveniences, but it also adopts some of the worst qualities of Java, and, worse, lacks precisely those features that make C++ uniquely useful.
Hacks
Posted Oct 23, 2005 22:41 UTC (Sun) by doodaddy (guest, #10649) [Link]
Can you be specific? It has gc, which you can start now, or turn off for a while. I think I remember you can work without it. It has "layovers" in the form of structs (while 'class' is more like Java.) It has arrays built in (not a class) with "slices." ...
It has been winning in coding shoot outs for speed, I think due to the slices.
I'm always ready to hear some interesting insights to these things as I fancy myself working on languages some day.
P.S. My last job was in C (with some C++) for a 4 million line code base. I finally see some of the light of Java (though I'm still bothered by it). With 20 years and new front lines of coders, the code was very good and yet... impossible to work with. So many programming paradigms, so many utility libraries, so much cross-platofrm ifdef and libraries, so many different ways to use it. So much control of errors, memory, everything. SO MANY "help" MACROS! Ugh! You could stare at a function and have no idea what it was doing. My point is that I can see why Java wanted to remove control of allocation issues, force libraries to be named the same as files and force a hierarchy of library files. Also, I can see why Java tries to have a standard set of cross-platform libraries and remove macros. To keep this on topic a bit, it seems "big systems" do hang themselves with some of these control structures and removing them might be the way to better real-world code.
Hacks
Posted Oct 22, 2005 5:36 UTC (Sat) by b7j0c (subscriber, #27559) [Link]
Good post, some comments:
>> For a little program, any language will do
Well said. I might add that in the case of "small" problems (and more problems are "small" than most people think), other issues, such as using the same language as your coworkers (as long as it is relatively appropriate) often outweigh a pure qualitative assessment.
>> Standard C++, for all its historical baggage, is still the only language
>> that even addresses the problem. A well-crafted C++ library can equal the
>> convenience and (immediate) power of a scripting language without
>> sacrificing performance or maintainability.
...and there are a lot of those libraries. C++ continues to be the language of "choice" for many large apps not just because of performance (I find the perfrommance of PyGtk apps or Eclipse, Jedit etc etc decent in most cases), but because
1. the language is stable,
2. is guided by standards,
3. has one dominant open implementation in gcc/g++ (even if this dominant implementation supports historically non-standard syntax).
I would argue that Java fails (1) as new features and libraries seemed to be tacked on endlessly as the marketing team attempts to repurpose the tool for a new audience (remember the Jini push?)
Clearly Java fails (2), although I don't think an ISO standard is that much of a big deal, not nearly as big a deal as (3). Look at perl or python...do you ever hear about compatibility issues across platforms? Never. This is because they are all addressing one runtime. In the Java world there will always be fragmentation because there will always be coders who will not accept a closed JRE.
Technologies to Watch: A Look at Four That May Challenge Java's Development Dominance (O'ReillyNet)
Posted Oct 21, 2005 8:14 UTC (Fri) by philips (guest, #937) [Link]
Another peice from Java people.
All of such pieces look the same: WOW!!! There is world outside of Java!!!! How might have guessed!!!!!!!
Just another confirmation that in long term languages like (God forgive me mentioning the cursed name) BASIC, Java & Python - from "There's Only One True Way To Do It" camp - always loosing to languages like Perl and Ruby - from "There's More Than One Way To Do It" camp.
BASIC, Java & Python are all good for beginners. They good for building theories. They are good at uniting people who do not know what they want. They good at sandboxing and restricting.
But when you come to age, when you start feeling confident in harnessing all computing power available - sandboxes are out of game. They are restricting - and why you need restrictions when you know what to do? Perl, Ruby & Assemblers are all coming back.
Preventing people from doing stupid things, will prevent people from doing smart things too. Do not forget that golden rule of Unix. Ever.
P.S. Probably I was one of few lucky whose first programming language was Assembler - I know how computers do work, I know all their powers. It is quite sad seeing people beeing taught sandbox languages - just for sake of making things look simple. People grow to think simple & rigid way. And later they become Java or - even worse - BASIC users. No wonder good programmers (especially system programmers) are still quite higly valued.
Python
Posted Oct 21, 2005 15:01 UTC (Fri) by mkc (guest, #2047) [Link]
Er, have you even tried Python? Like all languages, it has its downsides, but the ones you're speaking of are not among them...
Technologies to Watch: A Look at Four That May Challenge Java's Development Dominance (O'ReillyNet)
Posted Oct 21, 2005 15:42 UTC (Fri) by mdaniel (guest, #33232) [Link]
But when you come to age, when you start feeling confident in harnessing all computing power available - sandboxes are out of game. They are restricting - and why you need restrictions when you know what to do? Perl, Ruby & Assemblers are all coming back. Preventing people from doing stupid things, will prevent people from doing smart things too. Do not forget that golden rule of Unix. Ever.
I honestly do understand and agree with most of your point(s). But even the very first chapter of "The Mythical Man Month" discusses the gap between the cavalier attitude you describe and the concept of software engineering. There is such a thing as productivity, even for garage start-ups, and the combination of language and programmer determines how well that pair will achieve their goals.
My second point, and this is stongly tied to the first, is about dealing with the harsh realities of Corporate America (or Corporate anywhere). In the vast majority of my experience, you have a bunch of inexperienced and unmotivated workers in whom your are entrusting your business goals. The odds of any one of the twelve monkeys you hired from the University of Party being able to wield the light saber of assembler or even C [but I repeat myself] are very low. Even Perl6 is showing how much people just really don't like malloc/free when you have a more fastidious computer to handle the housekeeping for you. IIRC, moving away from "systems" programming was one of the goals COBOL was trying to achieve.
Um... no.
Posted Oct 21, 2005 17:16 UTC (Fri) by GreyWizard (subscriber, #1026) [Link]
But when you come to age, when you start feeling confident in harnessing all computing power available - sandboxes are out of game.
Perhaps when *you* come of age, in addition to mastering the rules of grammar and punctuation, you'll have a chance to participate in the development of a large piece of software. You won't be using Assembly or Perl. (I'm only casually familiar with Ruby, so I'll give it the benefit of the doubt with respect to your claim that it's as brain-damaged as Perl.) You'll learn that Python provides all the features and power Perl does without the multiple personality disorder. More to the point, you'll discover that having more than one way to do everything is not so much the opposite of programming in a sandbox as it is a reliable recipe for unmaintainable code.
This is a practices issue
Posted Oct 22, 2005 5:15 UTC (Sat) by b7j0c (subscriber, #27559) [Link]
I hear this lameo comment again and again, and not just with reference to perl, but with C++, PL/SQL etc etc etc
So lets turn this around and ask why no one in your organization is reading code multiple times prior to delivery. Coding cabals develop memes, and unreadabiliyt typically implies a violation of style, not correctness per se. If a new coder works outside of those memes and style guidelines, you correct them early and keep moving.
Many large perl systems later, I have no problem reading a coworker's perl.
This is a tool issue
Posted Oct 22, 2005 17:40 UTC (Sat) by GreyWizard (subscriber, #1026) [Link]
I hear these "lameo" comments again and again: one can write good or bad code in any language; it's a pracitces issue; style guidelines and discipline can work around the problem. All true but irrelevant. When they get to choose, smart programmers select the best tool available. They don't choose arbitrarily on the grounds that they can achieve the same result by applying extra discipline. The best tool is a programming language that makes the right thing to do simple and as obvious as possible -- not to protect poor programmers from their limitations but to free good programmers from distractions. Extra features have a cost in terms of environment complexity and comprehension that is worth paying only if they actually provide extra power.
Most programming languages have vestigal features but Perl is unusual because the culture around it elevates them to virtues. There may be more than one way to do it, but in fact there is only one appropriate way to do it in any particular circumstance. You implicitly acknowledge this by suggesting that there is a correct style for each "cabal" of programmers. Why should you have to enforce style guidelines? That's work the language should do for you.
No one is reading code multiple times prior to delivery in my organization because everyone is too busy solving actual customer problems. Rather than genuflecting to a priesthood of style or waxing eloquent about memes we choose tools that don't burden us with needless complexity. Because of that we can deliver the same quality of work faster or higher quality work on the same deadline compared to our competitors. If you work for one of them keep your resume up to date.
This is a tool issue
Posted Oct 22, 2005 18:51 UTC (Sat) by b7j0c (subscriber, #27559) [Link]
>> Most programming languages have vestigal features but Perl is unusual>> because the culture around it elevates them to virtues.
this talks well, but where's the beef? what are these vestigal features of perl? "TMTOWTDI" and "vestigal" should not be conflated.
>> but in fact there is only one appropriate way to do it in any particular
>> circumstance.
then java is for you.
>> Why should you have to enforce style guidelines? That's work the
>> language should do for you.
so following your line of reasoning the syntax should dictate the one true sequence of glyphs to describe each code segment....well, once gain, java is for you. its a bondage language. there are very strict rules, they sometimes don't make sense, but they are consistent to the point of obstinance, as opposed to c++, which is multi-paradigm by design and enforces paradigms only when it makes sense, and often at coder discretion (you-pay-for-only-what-you-use, another canon of c++ design).
>> No one is reading code multiple times prior to delivery in my
>> organization because everyone is too busy solving actual customer
>> problems.
no one cares why you ignore engineering practices. code review is an essential part of delivering quality. this is invariant. in a decade my engineering organization has gone from 10 to 4000. you don't get there by trusting everyone's code.
Reading Comprehension
Posted Oct 22, 2005 21:29 UTC (Sat) by GreyWizard (subscriber, #1026) [Link]
this talks well, but where's the beef? what are these vestigal features of perl? "TMTOWTDI" and "vestigal" should not be conflated.
Reading Perl Best Practices, which is chock full of descriptions of features the reader is advised never to use, might save you from making ignorant comments like this one in the future.
...well, once gain, java is for you.
Only poor reading comprehension skills could lead you to that conclusion. Let's review what I actually wrote: "Extra features have a cost in terms of environment complexity and comprehension that is worth paying only if they actually provide extra power." Does this address the issue of consistency across features in any way? No. Does it say features should impose a runtime cost even when they're not being used? No. Does it say features that provide extra power do not belong in the language? No. Quite the reverse in fact.
Take the time to read what you're responding to unless you enjoy making a fool of yourself.
no one cares why you ignore engineering practices. code review is an essential part of delivering quality. this is invariant.
While most code can benefit from peer review if the luxury of time is available, it is only actually essential for delivering high quality code when the skills of the programmers involved are weak, the tools are inferior or both. When you find your organization competing with one that puts emphasis on solving customer problems rather than dotting the i's and crossing the t's of some "engineering practices" checklist, you'll find reason to care quite a bit about why some people ignore them.
in a decade my engineering organization has gone from 10 to 4000.
That you seem to regard this as a good thing reveals much.
Reading Comprehension
Posted Oct 23, 2005 5:40 UTC (Sun) by b7j0c (subscriber, #27559) [Link]
>> Reading Perl Best Practices, which is chock full of descriptions of>> features the reader is advised never to use, might save you from making
>> ignorant comments like this one in the future.
no, you claimed VESTIGIAL features of perl. this is quite different than a best practice. still awaiting an example. see, i get "reading comprehension" just fine.
>> Let's review what I actually wrote: "Extra features have a cost in terms >> of environment complexity and comprehension that is worth paying only if >> they actually provide extra power."
TMTOWTDI **IS** the power of perl. its also why perl's backwards-compatibility is well-rgarded. its why you see things likes regexes and tr exists side-by-side - perl was born out of sysadmin prgramming and was designed to migrate sh programmers. you can tell me simple flow-control reodering is a vestigial artificat but every language provides that sugar. i cannot think of one feature of perl that is completely pointless.
>> While most code can benefit from peer review if the luxury of time is
>> available, it is only actually essential for delivering high quality
>> code when the skills of the programmers involved are weak, the tools are
>> inferior or both
don't you think it would be a good idea to know what people are coding should they quit, get hit by a cement truck, or go on vacation when an emergency strikes? this is a side-effect of code review. you should drop your position against peer review, it is untenable. the bridge you crossed today had its design peer reviewed. the structure and effects of the chemical compounds in your medicines were peer reviewed. its what engineers do.
>> >> in a decade my engineering organization has gone from 10 to 4000.
>> That you seem to regard this as a good thing reveals much.
it reveals a few things, like we built a service that has incredible demand (incidentally using a LOT of perl...gee, how did we do that? didn't we know perl was garbage?). and we were rewarded for it.
Reading Comprehension
Posted Oct 23, 2005 23:00 UTC (Sun) by ncm (subscriber, #165) [Link]
I'm afraid you guys are both wrong, albeit a little big right. Code review really is important, but it really isn't done where it's needed most -- not even, I'll bet, in b7j0c's organization. Perl really is a horrendous language for anything that's going to be looked at by somebody else (or, indeed, ever again). That b7j0c has put years into learning every nook and cranny of Perl doesn't change that any normal engineer probably can't read his code -- but probably could read GreyWizard's Python code.
Would b7j0c's employer get along with many fewer than 4000 IT staff if their code wasn't Perl? We don't get to do the experiment, but it would be hard to believe his employer's problems are bigger than Google's, and Google does. However, Python is only incrementally better than Perl for big projects. Like Perl, it's hundreds of times slower than need be, but more importantly, it offers little help in managing the complexity of a big project.
Python, Perl, PHP, and Ruby often beat Java anyway because (a) Java's notion of such help is actually a hindrance, (b) the culture around Java specifically encourages and rewards gross inefficiency and extravagant complexity, (c) because Java's runtime apparatus squanders its potential speed advantage compensating for lost cache locality, and (d) because most projects really aren't, or shouldn't be, as big as the Java Full Employment Policy leads people who use and manage Java development to pretend.
Reading Comprehension
Posted Oct 24, 2005 4:32 UTC (Mon) by b7j0c (subscriber, #27559) [Link]
>> Perl really is a horrendous language for anything that's going>> to be looked at by somebody else (or, indeed, ever again).
i am already dealing with one poster providing unsubstantiated claims about perl. if you want to chime in, provide something concrete, and don't go digging up perl golf results or obfuscation contests, every language is subject to willful syntax vandalism.
as it stands i also code daily in php (vastly inferior to perl, which it is trying to ape in many ways), and ruby (syntactically sweet, but lacking a CPAN equivalent), so i don't feel i'm speaking from a perl penalty box.
i'm not a complete fanboi though, as you will see from this thread i am highly critical of the perl6 process.
Clarification
Posted Oct 25, 2005 2:41 UTC (Tue) by GreyWizard (subscriber, #1026) [Link]
Code review really is important, but it really isn't done where it's needed most
Whether review is important depends on context. For example, when doing innovative work in a new market code quality is less important than rapid development. Customers are more willing to tolerate faults and aren't quite sure what they want so much of the code will need to be discarded as requirements become more clear. Time spent perfecting it before then is wasted. As a project matures the balance changes of course. Review is one effective tool among many for improving code quality. Nevertheless the claim that high quality code cannot be produced without review is false in general. (You didn't make that claim but it was what I was responding to.)
With regard to the complexity of big projects, what is it you believe Python lacks? Bruce Eckel seems to disagree: "Python [is] a language which can build large, complex systems [...]". Large, complex and successful projects such as Zope must also be explained away.
Reading Comprehension
Posted Oct 29, 2005 15:37 UTC (Sat) by rwmj (subscriber, #5474) [Link]
I suppose I ought to inject a bit of fact into this discussion.
I used to work in a Perl shop[1], and we did code reviews regularly -
I conducted them usually twice a week. We rarely had a problem
with the code: all code had warnings and tainting and "use strict"
turned on. People were discouraged from deliberately writing
obfuscated code - but that's just standard practice in any
organisation worth anything. Everyone there was to some degree
able or expert in Perl.
Reading and reviewing other peoples' Perl was not a problem I
can recall having. Figuring out logical bugs in the code was
the hard issue, and that'd be just the same in any language.
Rich.
[1] http://www.schoolmaster.net/ - many tens-to-hundreds of thousands of lines of Perl code.
Still no comprehension
Posted Oct 25, 2005 2:01 UTC (Tue) by GreyWizard (subscriber, #1026) [Link]
no, you claimed VESTIGIAL features of perl. this is quite different than a best practice. still awaiting an example. see, i get "reading comprehension" just fine.
Do you now? Then I suppose your inability to understand that aspects of a language best practices recommend avoiding entirely are vestigial almost by definition must stem from a stunning lack of common sense instead. And no, I'm not going to do your homework by giving examples. Educating yourself about Perl is your own responsibility and anyway I'm not interested in reading your dim witted excuses on a feature by feature basis.
its also why perl's backwards-compatibility is well-rgarded.
Backward compatibility is available in almost every language and is entirely irrelevant to this discussion.
don't you think it would be a good idea to know what people are coding should they quit, get hit by a cement truck, or go on vacation when an emergency strikes?
When working with a small team of skilled programmers using a language that facilitates clear code I have no trouble picking up where someone else left off.
you should drop your position against peer review, it is untenable.
What position against peer review would that be? I said, "While most code can benefit from peer review if the luxury of time is available, [...]" which is in fact praise of peer review. Your comments are more evidence of your lack of reading comprehension skills. Like many good things peer review has a cost in terms of developer attention that is often but not always worth paying. Choosing a cluttered programming language also has a cost but yields no benefit. Resources not spent compensating for a bad choice there can be applied to increasing code quality, shipping on a shorter deadline or some combination in between.
using a LOT of perl...gee, how did we do that?
By working harder, not smarter. A language less inclined to distract you would have allowed you to accomplish more. Also, you were lucky enough not to have competition wielding more effective tools. You say working with 3,999 like minded people is a reward? Clearly your lack of common sense serves you well as a defense mechanism.
Technologies to Watch: A Look at Four That May Challenge Java's Development Dominance (O'ReillyNet)
Posted Oct 21, 2005 23:10 UTC (Fri) by xtifr (subscriber, #143) [Link]
> P.S. Probably I was one of few lucky whose first programming language was Assembler [...]
Hmm, I"ve written several assemblers in my day, and I much prefer Python to Java or Perl, thankyouverymuch! :p ;)
Frankly, I like a language that's simple and makes sense, and is still flexible and powerful enough to do amazing things with. Python may have its "one True Way", but that way is powerful and flexible enough to handle just about anything I want it to do. And that, to me, is what distinguishes a good language from a bad one.
I have to admit, if I hadn't spent some time with Python, I probably would have agreed with you, but I did, so I don't! :)