LWN: Comments on "The Grumpy Editor's guide to 2009"

The Grumpy Editor's guide to 2009

renox — Thu, 15 Jan 2009 10:23:22 +0000

[[While I'm not a Perl apologist, I just can't see it ever becoming "legacy".]]

I consider that there's two Perl language: Perl5 which is 'legacy'/'stable' as it won't change much now and Perl6 which is very different from Perl5.

Perl6 as a new language will have to compete against Python3, Ruby and Perl5, so I wouldn't bet on it..

The Grumpy Editor's guide to 2009

paulmfoster — Tue, 13 Jan 2009 03:14:00 +0000

Unless you know something we don't, linux.com is not "demised". According to their announcement on 1 Jan, it appears they are merging with or being bought out by someone. (For "legal reasons" they can't detail things right now.) I imagine they will emerge with a different paradigm. As I recall sometime in 2008, the parent company changed its name to SoureForge and asserted its ownership over linux.com and other assets.

If you hear something before we do, please let us know.

make-or-break year for Perl

nicku — Mon, 12 Jan 2009 02:12:17 +0000

It will be a make-or-break year for Perl. If the Perl developers cannot either bring new life to Perl 5 or turn Perl 6 into something real, this language will, by the end of the year, have moved well down the road to "legacy" status.

It's mainly a problem of perception. If Sun owned Perl, then 5.10 would have been released as version 10 and the waffle in Slashdot about Perl 6 would be irrelevant.

At Optus Internet Services Engineering, we write our code productively in Perl and occasionally in C. New projects are written in Perl. My team enjoys writing Perl. Perl simply need some better marketing.

'make' year for Perl

dlang — Sun, 11 Jan 2009 02:49:05 +0000

compiled vs interpreted languages are a perfect example of what Linus has said about git, performance is a feature in and of itself, and at some point performance isn't just about doing things a in less time, but it fundamentally changes how you do things.

the speed of the edit-compile-test loop is the key difference between languages.

for traditional compiled languages the compile step takes a significant amount of time, so you do more work between compile steps.

for interpreted languages the 'compile' step is invisable to the user (it exists to some extent, but it's part of the run), so the tendancy becomes to tweak one thing, test it, then go to the next.

depending on what the testing steps require a project may fit better into one model than the other. small projects or projects that are generally stateless (many web projects for example) are much faster to develop with an interpreted language, projects that take a long time to test (it may be that they have a lot of state in them and so take many steps to test the change) don't benifit from the interitive approach of interpreted languages, and so the compile step doesn't hurt as much, and the other advantages in traditional compiled langages like strong typing and faster run-time performance are still there, so they tend to be better done using a 'compiled' language

now, in many cases the langugage is not selected based on what's best for the project, and many cases where the project has shifted over time (what started as a quick and simple program grew to be a monster), so you see a lot of projects written and maintained in inappropriate langugaes

it would be nice if there were interpreters and compilers for the same language so that development could take advantage of the strengths of the interpreted approach and production could take advantage of the compiled approach, but such situations are very rare.

A formerly friendly company may pull an SCO

jordanb — Sat, 10 Jan 2009 23:35:21 +0000

Sun has far too much legitimate business left to pull a SCO. Companies that still have substantial business in this industry don't become IP trolls because they're still exposed to counter-suits. IP trolling is what you do as a last ditch effort to pay off your creditors when you have nothing left. SCO was essentially an IP troll -- albeit backed by Microsoft and more directed at FUD than most of them, for political reasons.

While one could see Schwartz deposed and Sun redirected away from OSS, patent trolling isn't what they'd be directed towards in the near term.

To be honest if I had my guess it'd be one of the little bottom feeders like Xandros, either that or one of the un-dead fossils that are already mostly employ lawyers, like SGI.

Of the big guys the most likely suspect is Novell.

The Grumpy Editor's guide to 2009

jospoortvliet — Sat, 10 Jan 2009 17:06:59 +0000

I just hope some company with serious resources will realize the OO.o
codebase is a dead end, rewriting it is a waste of time and there is a
better solution out there: KOffice. Sure, they don't have the features, but
they DO have the infrastructure to surpass OO.o within a very short time,
given the resources.

'make' year for Perl

epa — Sat, 10 Jan 2009 13:24:59 +0000

Whereas Perl 6 runs all existing Perl 5 code, no branching required.

Huh? You seem to be comparing an existing, working program (Python 3) with something that does not exist yet. Or have I missed something, and a Perl 6 implementation that 'runs all existing Perl 5 code' has been released without anyone noticing?

I am aware that the Parrot and Rakudo developers have been making good progress. That is not the same as saying that Perl 6 has been released in anything like a usable state, or will be in the next 12 months. According to the current road map there are a couple of years to wait.

'make' year for Perl

Ze — Sat, 10 Jan 2009 06:30:13 +0000

>>As I understand it, one of the advantages of increased dynamism in one's language environment is that one can write code with a reduced number of paths through it.
Whoever said that lied to you. A dynamic language has just as many paths through it. Just some of them are generated by the compiler/interpreter. The downside is since you give it less constraints it can do less optimisation and more importantly less error checking.
>>Ultimately - even truistically - the only way to write code with fewer bugs is to write less code.
Yes but that means less functionality.

>>The ideal for a compiler (or a language, maybe?) is that it is able to separate, as far as is possible, those bits of the program which can be precomputed (eg. type information) and precompute them, leaving only those bits which actually depend on real-time input for runtime. However, it's not readily apparent to me that languages such as Haskell - which impose a strict separation between compilation and execution, with the aim of doing as much reduction as possible in the former - are more capable of doing that than languages such as Lisp - which effectively abolish the distinction between the two, allowing the full power of the execution environment to be present at compilation;

The languages which separate compilation and execution (which btw isn't a restriction of the language but rather of the tools we choose to write , we could write an interpreter for c++ if we wanted).

The power that some languages have is they can create code on the fly. Ironically this was something that assembly had but when it came to write 'c' it was stripped out. It's a feature that's rarely needed or desirable. It's far more often misused than it used correctly.

If one wished , one could add an 'eval' to compiled languages by seperately compiling the extra code as needed and having a few constraints on optimisations for the original code. One particular optimisation that we would need to be very careful with is where instead of having two variables 'foo' and 'bar' we instead alias 'bar' to 'foo' since our analysis shows that 'foo' and 'bar' always have the same value.

>>I suspect that the relative power of the two approaches comes down purely to personal preference, or "which confuses/annoys me less", and that there's no inherent superiority in either approach.
I honestly don't understand why people like 'untyped' languages. It's no hassle to compile and run the code , and you could get the same speed as an untyped language out of a compiled language if you wanted to sacrifice optimisation and error checking to the same extent as an untyped one.

Consider the wasted time spent reanalysing a program every time you run it? and consider that you need to run it anyway to test it. Why not trade some of that reanalysis time for better optimisation? or time you could spend doing other things?

IMHO that was one of the things that scripting has historically got wrong but that's due to the fact that historically they didn't create an intermediate format but rather put the code into an 'abstract syntax tree' and interpreted it from that. That has changed though since a lot of them convert the AST into an intermediate form that is more linear and then interpret that.

Unfortunately it's one of the things that history has landed in our laps and it's not something we'll rid ourselves of soon.

'make' year for Perl

dlang — Fri, 09 Jan 2009 19:10:18 +0000

no problem. I've just seen too many people who believe the letter of your initial statement that I didn't want to leave it sit.

I agree with the rest of your statements as well.

'make' year for Perl

lysse — Fri, 09 Jan 2009 17:27:58 +0000

> even the statement that less code => fewer bugs is only true if all else remains equal. not all lines of code are the same. 100 lines of simple commands can be substantially less buggy than 5 lines of library calls with 50 options to each call.

I realised after I'd posted that what I'd written was a bit ambiguous on precisely this point - so for the record, I am in complete agreement with you on this point. Indeed, in some ways libraries offer the worst of both worlds - they are neither designed to be specific to the task at hand, nor necessarily as well-debugged as their generality would necessitate - but that's a rant for another day. Please don't think I'm lending support to the "if there's a library for it, use the library" school of coding! Rather, I regard using a library as outsourcing; you're still responsible for every line of code in that library connected with the parts of it you're using, even though you delegated the authorship of the code you're using to the library's authors.

But I'm going to abandon this conversation at this point, anyway, because the one thing that's become more apparent to me than anything else over the 15 years I've been paying attention is that whatever anyone says about programming, and however anodynely they seek to express it, someone will come along and disagree with it in the violent and unshakeable conviction that they Know the Truth about it and have a Duty to Correct the Evil Lies - and if (but only if) you're really really lucky, they haven't misunderstood the first half of the second sentence to which they're replying and gone off half cocked. Worse, I've been that person way too often myself. So forgive me if I skip the whole damn sideshow this time; it's old and tedious and does absolutely nothing for anyone, and it disproportionately upsets me.

'make' year for Perl

dlang — Fri, 09 Jan 2009 01:42:45 +0000

while I agree that writing less code tends to generate fewer bugs, I adamantly disagree with the statement that the only way to write code with fewer bugs is to write less code.

even the statement that less code => fewer bugs is only true if all else remains equal. not all lines of code are the same. 100 lines of simple commands can be substantially less buggy than 5 lines of library calls with 50 options to each call.

using the language that best matches the abstraction of your code both decreases the lines of code needed, and decreases the errors. but the big win is in the fit, not in the lines of code.

A formerly friendly company may pull an SCO

lysse — Fri, 09 Jan 2009 00:32:54 +0000

Thanks. ;)

'make' year for Perl

lysse — Fri, 09 Jan 2009 00:32:08 +0000

As I understand it, one of the advantages of increased dynamism in one's language environment is that one can write code with a reduced number of paths through it. Ultimately - even truistically - the only way to write code with fewer bugs is to write less code.

The ideal for a compiler (or a language, maybe?) is that it is able to separate, as far as is possible, those bits of the program which can be precomputed (eg. type information) and precompute them, leaving only those bits which actually depend on real-time input for runtime. However, it's not readily apparent to me that languages such as Haskell - which impose a strict separation between compilation and execution, with the aim of doing as much reduction as possible in the former - are more capable of doing that than languages such as Lisp - which effectively abolish the distinction between the two, allowing the full power of the execution environment to be present at compilation; I suspect that the relative power of the two approaches comes down purely to personal preference, or "which confuses/annoys me less", and that there's no inherent superiority in either approach.

Perl

chromatic — Thu, 08 Jan 2009 20:53:58 +0000

That the language hasn't been updated in the last decade is also a sign of maturity....

That's not true in the case of Perl, though. Perl 5.10 has great improvements in the regex engine, some of which include user-visible improvements. In particular, I find named captures tremendously useful. given/when is also a powerful simplifying force.

You also shouldn't discount language evolution in the form of CPAN distributions. I won't give up Mouse/Moose, and I want to see them as core language features. They didn't exist ten years ago.

'make' year for Perl

chromatic — Thu, 08 Jan 2009 20:49:28 +0000

We have Debian packages for Parrot and a spec file for RPM-based distributions. Our milestones for the next couple of Parrot releases include the ability to run Rakudo from an installed Parrot, so we should be able to provide Rakudo packages to free software operating systems within the next couple of months.

3D Graphics

tzafrir — Thu, 08 Jan 2009 20:20:16 +0000

Via also made some progress.

nVidia's devices will be more expensive (= take more work to use properly) for OEMs.

Depose is correct

pr1268 — Thu, 08 Jan 2009 20:13:30 +0000

I stand corrected. I was thinking of the 2nd definition of depose at Dictionary.com.

Regardless, it'd be unfortunate if it happened (at Sun or any other company).

Although, I'd like to think that Linux and Open Source would prevail yet again should this occur.

A formerly friendly company may pull an SCO

knobunc — Thu, 08 Jan 2009 19:47:54 +0000

No. Depose is right.

"To remove (a monarch or political leader) from power, particularly without violence."

http://en.wiktionary.org/wiki/depose

A formerly friendly company may pull an SCO

pr1268 — Thu, 08 Jan 2009 18:36:30 +0000

Do you mean dispose Schwartz?

'make' year for Perl

rwmj — Thu, 08 Jan 2009 17:59:15 +0000

Well, I'd certainly like the compiler to identify some of the bugs for me earlier, instead of me having to try in vain to test every path through the code. My time is valuable, and wasting in tracking bugs and testing things that can be easily found by the compiler is just stupid. But hey, most people are still writing C that lets you stomp all over memory (when, that is, you're not sitting there worrying about who owns that bit of memory and who is responsible for freeing it).

Rich.

A formerly friendly company may pull an SCO

lysse — Thu, 08 Jan 2009 17:52:16 +0000

Yes, but consider that Sun's shareholders might depose Schwartz and install a more bottom-line-friendly CEO.

'make' year for Perl

lysse — Thu, 08 Jan 2009 17:50:47 +0000

"Better quality" surely remains an unproven assertion in this context - possibly even an unproveable one.

A formerly friendly company may pull an SCO

felixfix — Thu, 08 Jan 2009 17:30:24 +0000

Indeed. SCO used to be a linux friendly company, albeit not very successful, which may have been why they changed. Desperation and greed can be quite surprising when mixed together.

The Grumpy Editor's guide to 2009

cine — Thu, 08 Jan 2009 17:06:15 +0000

Renewed my subscription a few months ago for another 2 years, extending the already 6 years of continuous reading. Very much enjoy your work :)

3D Graphics

xav — Thu, 08 Jan 2009 16:26:00 +0000

Obviously he meant "with Free Software" as long as one buys ATi or Intel hardware.
That say I don't hold my breath (I've waited for so long). I think we'll probably have basic 3D this year (i.e. Compiz working on all current radeons by june), but having the drivers match the proprietary NVIDIA one in terms of features and performance is far away.

A formerly friendly company may pull an SCO

pr1268 — Thu, 08 Jan 2009 14:53:32 +0000

That's. Just. Scary.

Especially given how hypocritical Jonathan Schwartz would look after his "Innovate, not Litigate" blog entry.

'make' year for Perl

tetromino — Thu, 08 Jan 2009 14:52:17 +0000

None, for the obvious reason that perl6 is not yet finished.

Basically, during the second half of 2008, the Parrot virtual machine and the Rakudo Perl 6 compiler have made tremendous progress. You can now write useful programs in Perl 6, as long as you restrict yourself to the (large) subset of the language that Rakudo supports.

But the work is not yet finished; realistically, it will take a year to implement all the missing features. And even when 6.0 is released, it will take a while before distributions adopt it - just look at how many distros have made the switch to Python 3.

The Grumpy Editor's guide to 2009

hmh — Thu, 08 Jan 2009 14:33:19 +0000

But we didn't have the obServerCrash yet. There is one within one month of a new stable release, aways...

Well, maybe the mess with the firmware GR might have satisfied Eris enough, for once. Who knows...

Small grammar fix?

pr1268 — Thu, 08 Jan 2009 14:31:42 +0000

"pulls a SCO" - you wrote it that way, but didn't mention that the article has written it as "pulls an SCO" which doesn't read right, to my eyes.

I habitually pronounce SCO as a single-syllable word that rhymes with "snow" or "slow". It is an acronym, so saying it as "S-C-O" wouldn't be improper.

I perish the thought of our editor agonizing over whether to use "a" or "an" in that sentence. :)

Small grammar fix?

hummassa — Thu, 08 Jan 2009 14:22:52 +0000

"pulls _an_ ess-cee-oh" reads OK to me :-)

Minor typo

vonbrand — Thu, 08 Jan 2009 14:11:38 +0000

> > make the dump to a DVCS

> jump?

Nope, dump is right. Take the code out of the legacy system, dump it into the DVCS of your choice ;-)

A formerly friendly company may pull an SCO

corbet — Thu, 08 Jan 2009 14:04:06 +0000

I made a real point of not naming a company. Should this unfortunate prediction come to pass, it may well come from a direction which surprises almost everybody.

Small grammar fix?

roblucid — Thu, 08 Jan 2009 13:44:25 +0000

s/"skow" to rhyme with/& slow/p

Small grammar fix?

roblucid — Thu, 08 Jan 2009 13:43:23 +0000

> "pulls a SCO" - you wrote it that way, but didn't mention that the article > has written it as "pulls an SCO" which doesn't read right, to my eyes.

If I say "skow" to rhyme with then it's "pulls a SCO", but if I say ess-see-oh, then it's "pulls an SCO". What reads right, might depend on how you pronounce the acronym.

The Grumpy Editor's guide to 2009

cde — Thu, 08 Jan 2009 12:55:06 +0000

I have to say, it's high time to release Lenny. I've been using the di-beta2 for more than 6 months and it's rock stable. Of all the Debian version I've used since potato, it's by far the best.

Minor typo

smitty_one_each — Thu, 08 Jan 2009 12:42:06 +0000

>make the dump to a DVCS

jump?

Perl

job — Thu, 08 Jan 2009 10:55:27 +0000

Labeling Perl a legacy language is a bit harsh. That the language hasn't been updated in the last decade is also a sign of maturity, much as the Bourne shell which could hardly be described as legacy.

It still handles day to day problems such as Unicode better than Python/Ruby, and last time I checked it was faster too. Last time I needed to talk SOAP with a Microsoft environment Perl did what Python couldn't. That said, it's far from perfect, and I also would like to see Perl 6 succeed. But from that it will probably take many years until everyone has migrated to it.

'make' year for Perl

rwmj — Thu, 08 Jan 2009 10:33:10 +0000

Which Linux distribution has a working perl6 implementation?

You might also ask which distributions are using Python 3. I guess Debian have packaged it. Fedora have passed on Python 3 (for now at least). Python 3 isn't backwards compatible, in a way which means you have to maintain two branches of your code. Whereas Perl 6 runs all existing Perl 5 code, no branching required.

(Of course, I'm hoping that 2009 will be the year of the strongly-typed HM-based functional language, and we can finally give all dynamic languages the heave-ho in order to write better quality software).

Rich.

A formerly friendly company may pull an SCO

rwmj — Thu, 08 Jan 2009 10:26:02 +0000

Do we think Sun?

3D Graphics

pjm — Thu, 08 Jan 2009 10:17:53 +0000

3D graphics will be a solved problem on Linux systems. We will no longer be second to other systems with regard to functionality or performance

Just a clarification of the prediction: does on Linux systems mean/imply with Free Software ? I'm not a 3D user, but was under the impression that performance was already roughly the same as on other systems so long as one was prepared to use proprietary drivers and suffer the associated version incompatibilities and other upgrade difficulties.