The Grumpy Editor's guide to 2009
Commercial
The net is full of guesses about what the currently-unfolding financial crisis will mean for free software; many of those are wildly optimistic. Your editor is a bit more guarded: the free software community will emerge from this mess stronger than ever, but it may well be a difficult ride. Much of the commercial Linux industry draws a fair amount of its income from the financial industry, and many players in that industry - there should still be one or two left - are likely to be looking to cut their expenses somewhat. So money for little things like critical infrastructure may be a little short until the bonus pool can be brought back to a satisfactory level. Other parts of the economy will be suffering similar pain. All told, economic trouble will make life harder for a number of free software companies - and the people they employ.
Still, the lower cost of free software, along with its flexibility, can only serve to make it more appealing to companies which are trying to develop a successful business strategy for difficult times. The commercial ecosystem around free software should continue to grow, but it may go through some interesting changes along the way.
One thing that will help is that open embedded systems will grow in appeal and become more successful. The iPhone showed what can be done with an interesting hardware platform; at the same time, it has spawned a steady industry devoted to opening up the device. Android-based platforms are quickly showing that it's possible to make an equally (or almost equally) nice device without locking it down in the same way. Awareness of the value of open gadgets will grow, and there will be more of them on the market by the end of 2009. These gadgets may not be as completely open as many LWN readers would like, but they will be a big step in the right direction.
As that happens, your editor thinks that Android will grow in popularity, perhaps to the point where it eclipses other Linux-based handset platforms. Android has no shortage of flaws, but it is a sufficiently well thought-out and developed system that it should be able to attract a real development community - especially if Google opens up its processes sufficiently. And if Google maintains an overly-firm hand on Android, we may well see forked versions aimed at the hardware devices which can run them.
Legal
The pace of GPL enforcement actions will drop as a result of two independent developments: more companies will figure out that free software licensing matters, and developers will decide that they do not want to be part of a high-profile lawsuit. That said, there will be some significant actions on this front in 2009. Meanwhile, the FSF's GPL-infringement lawsuit against Cisco will be settled in a flurry of "win-win" press releases.
GPLv3 migrations will slow, especially among projects that people have actually heard of.
A formerly friendly company may pull an SCO. The sad fact is that failing companies have a certain tendency to look toward their "IP portfolio" as a last-ditch source of revenue. 2009 is likely to see more than the usual number of failing companies; do not be surprised if one of them grasps at this particular straw.
Distributions
Debian Lenny will be released. Now that the ritual firmware flame war and general resolution obligations have been satisfied, it looks like even Debian would be hard put to not get a release out this year. Debian will also make a serious attempt to avoid a repeat of the recent general resolution mess. There will be changes to how resolutions find their way to a vote, and the scripture-like authority of the "foundation documents" may be eroded somewhat.
We still won't know about Fedora's "infrastructure issues". But they'll promise to fill us in as soon as they possibly can. In the mean time, Fedora will crank out two more solid releases, one of which will eventually show up (somewhat transformed) as the next RHEL release.
openSUSE will make it easier for outside developers to maintain packages in an attempt to bolster its relevance in the development community.
Development
The 2.6.33 kernel will be released. In other words, the kernel development cycle will continue at its fast pace, and the numbering scheme will not be changed.
The realtime patch set will be mostly merged by the end of the year. It really has to happen this time. What could possibly go wrong?
After many years of effort, 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 - at least, if you buy your video hardware from cooperative companies. Some of the code may still be working its way through the distribution system, but the work will be done.
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.
By the end of the year, KDE 4 will have stabilized, and most users will have forgotten what all of the flames were about. Meanwhile, the first pieces of GNOME 3 may be out, but they are likely to be received without great enthusiasm.
The distributed version control system debates will continue in full force through the year. A number of major projects will make the jump to a DVCS, and most of them will go to git. But Mercurial and Bzr (at least) will remain strong contenders.
As a result of declining contributions from Sun and frustration felt by outside developers, OpenOffice.org will be forked. The new project is likely to have some initial troubles - OpenOffice.org is a big program - but it will eventually become the focus of a much more dynamic, community-oriented system.
Conclusion
This article would not be complete without a prediction that free software will be stronger than ever at the end of 2009. Some predictions are easy to make; that has been the trend for many years, after all. Still, it is going to be interesting to see what we will be able to accomplish over the next twelve months. As always, it is going to be fun.
Finally, it will be a hard year for Linux-related media; we have
already seen a foreshadowing of the situation with Groklaw's shift
into maintenance mode and the recent demises of
LinuxWorld.com and Linux.com. It is a hard time to be in the media
business in general, and the free software realm offers challenges of its
own even in the best of times. That said, LWN appears to be holding steady
so far, thanks to thousands of readers who feel that this enterprise is
worth supporting. So your editor is able to confidently predict that we'll
still be here for the traditional mocking of these predictions in
December.
Posted Jan 8, 2009 2:33 UTC (Thu)
by pr1268 (guest, #24648)
[Link] (9 responses)
If some other company "pulls a SCO", then Groklaw will likely need to come out of maintenance mode to cover it. ;) While I'm not a Perl apologist, I just can't see it ever becoming "legacy". Or, if one considers it to be legacy already, then it'll join the ranks of FORTRAN and COBOL and such as one of those ancient languages that demands a lot of skilled programmers in perpetuity. 2.6.33 sounds mighty optimistic, given how the time interval between 3-number kernel releases continues to grow. We'll see... We still won't know about Fedora's "infrastructure issues". But they'll promise to fill us in as soon as they possibly can. I'm not holding my breath. Forgive me if I sound trollish, but I'm resigned to thinking that Fedora will quietly let sleeping dogs lie on this one (for legal reasons). Finally, it will be a hard year for Linux-related media; we have already seen a foreshadowing of the situation with Groklaw's shift into maintenance mode and the recent demises of LinuxWorld.com and Linux.com. Please, don't let LWN suffer the same fate as these! Thanks to LWN's editors for all the fine work. Here's to a fun and productive 2009!
Posted Jan 8, 2009 4:40 UTC (Thu)
by jordanb (guest, #45668)
[Link]
One thing that potentially makes Perl different than Fortran and COBOL is that the latter two survive and prosper (in their own way) by serving a particular niche very well.
To the extent that Perl has a niche it's being plowed into by other languages (Python for system scripting, and a grab bag of them for web scripting). To look at the lifecycle of a language that is attacked in its niche, it might do well to look at something like Pascal. Yes, there still is some Pascal/Delphi work being done in this industry, but it's highly anemic. There's just no sector anymore where Pascal is still the 'default' choice for doing anything.
Posted Jan 8, 2009 7:26 UTC (Thu)
by tajyrink (subscriber, #2750)
[Link]
Posted Jan 8, 2009 8:20 UTC (Thu)
by mlawren (guest, #10136)
[Link] (4 responses)
Posted Jan 8, 2009 13:43 UTC (Thu)
by roblucid (guest, #48964)
[Link] (1 responses)
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.
Posted Jan 8, 2009 13:44 UTC (Thu)
by roblucid (guest, #48964)
[Link]
Posted Jan 8, 2009 14:22 UTC (Thu)
by hummassa (subscriber, #307)
[Link]
Posted Jan 8, 2009 14:31 UTC (Thu)
by pr1268 (guest, #24648)
[Link]
"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. :)
Posted Jan 8, 2009 8:28 UTC (Thu)
by Ze (guest, #54182)
[Link]
I'm not holding my breath. Forgive me if I sound trollish, but I'm resigned to thinking that Fedora will quietly let sleeping dogs lie on this one (for legal reasons). What legal reasons? Honestly I reckon Fedora will try to sweep it under the carpet so they aren't further embarrassed. Now I'm going to take a completely uninformed wild guess and say the compromise was most likely due to incompetence in securing their own servers ,perhaps even someone not following the projects procedures for security. Sweeping it under the carpet is what they shouldn't do , as anybody who cares about security should be assuming the worst possibilities rather than ignoring it.Until you know what happened you can't know if the procedures in place are sufficient to fix further problems or even fix the current problem.
Posted Jan 15, 2009 10:23 UTC (Thu)
by renox (guest, #23785)
[Link]
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..
Posted Jan 8, 2009 2:38 UTC (Thu)
by miguelzinho (guest, #40535)
[Link] (2 responses)
Posted Jan 8, 2009 4:33 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Jan 10, 2009 17:06 UTC (Sat)
by jospoortvliet (guest, #33164)
[Link]
Posted Jan 8, 2009 4:20 UTC (Thu)
by vmlinuz (guest, #24)
[Link]
Thanks for the reminder! I've just upped my sub from 'starving hacker' - because I was one last year and I'm not now - and renewed for a year. Keep up the great work!
Posted Jan 8, 2009 6:39 UTC (Thu)
by ChrisDolan (guest, #41017)
[Link] (14 responses)
Posted Jan 8, 2009 8:15 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (12 responses)
Posted Jan 8, 2009 10:33 UTC (Thu)
by rwmj (subscriber, #5474)
[Link] (9 responses)
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.
Posted Jan 8, 2009 17:50 UTC (Thu)
by lysse (guest, #3190)
[Link] (7 responses)
Posted Jan 8, 2009 17:59 UTC (Thu)
by rwmj (subscriber, #5474)
[Link] (6 responses)
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.
Posted Jan 9, 2009 0:32 UTC (Fri)
by lysse (guest, #3190)
[Link] (5 responses)
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.
Posted Jan 9, 2009 1:42 UTC (Fri)
by dlang (guest, #313)
[Link] (2 responses)
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.
Posted Jan 9, 2009 17:27 UTC (Fri)
by lysse (guest, #3190)
[Link] (1 responses)
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.
Posted Jan 9, 2009 19:10 UTC (Fri)
by dlang (guest, #313)
[Link]
I agree with the rest of your statements as well.
Posted Jan 10, 2009 6:30 UTC (Sat)
by Ze (guest, #54182)
[Link] (1 responses)
>>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.
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.
Posted Jan 11, 2009 2:49 UTC (Sun)
by dlang (guest, #313)
[Link]
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.
Posted Jan 10, 2009 13:24 UTC (Sat)
by epa (subscriber, #39769)
[Link]
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.
Posted Jan 8, 2009 14:52 UTC (Thu)
by tetromino (guest, #33846)
[Link]
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.
Posted Jan 8, 2009 20:49 UTC (Thu)
by chromatic (guest, #26207)
[Link]
Posted Jan 8, 2009 9:34 UTC (Thu)
by Ze (guest, #54182)
[Link]
Personally I'm not a huge fan of any of them , but for some reason I've got an irrational hatred of python. I do like using tabs/leading line space as block delimiters rather than {} or begin/end though. I'd still keep () for function calls and control statements though.
Posted Jan 8, 2009 10:17 UTC (Thu)
by pjm (guest, #2080)
[Link] (2 responses)
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.
Posted Jan 8, 2009 16:26 UTC (Thu)
by xav (guest, #18536)
[Link] (1 responses)
Posted Jan 8, 2009 20:20 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link]
nVidia's devices will be more expensive (= take more work to use properly) for OEMs.
Posted Jan 8, 2009 10:26 UTC (Thu)
by rwmj (subscriber, #5474)
[Link] (9 responses)
Posted Jan 8, 2009 14:04 UTC (Thu)
by corbet (editor, #1)
[Link] (1 responses)
Posted Jan 8, 2009 17:30 UTC (Thu)
by felixfix (subscriber, #242)
[Link]
Posted Jan 8, 2009 14:53 UTC (Thu)
by pr1268 (guest, #24648)
[Link] (5 responses)
That's. Just. Scary. Especially given how hypocritical Jonathan Schwartz would look after his "Innovate, not Litigate" blog entry.
Posted Jan 8, 2009 17:52 UTC (Thu)
by lysse (guest, #3190)
[Link] (4 responses)
Posted Jan 8, 2009 18:36 UTC (Thu)
by pr1268 (guest, #24648)
[Link] (3 responses)
Do you mean dispose Schwartz?
Posted Jan 8, 2009 19:47 UTC (Thu)
by knobunc (guest, #4678)
[Link] (2 responses)
"To remove (a monarch or political leader) from power, particularly without violence."
Posted Jan 8, 2009 20:13 UTC (Thu)
by pr1268 (guest, #24648)
[Link]
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.
Posted Jan 9, 2009 0:32 UTC (Fri)
by lysse (guest, #3190)
[Link]
Posted Jan 10, 2009 23:35 UTC (Sat)
by jordanb (guest, #45668)
[Link]
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.
Posted Jan 8, 2009 10:55 UTC (Thu)
by job (guest, #670)
[Link] (1 responses)
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.
Posted Jan 8, 2009 20:53 UTC (Thu)
by chromatic (guest, #26207)
[Link]
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.
Posted Jan 8, 2009 12:42 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link] (1 responses)
jump?
Posted Jan 8, 2009 14:11 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
> > 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 ;-)
Posted Jan 8, 2009 12:55 UTC (Thu)
by cde (guest, #46554)
[Link] (1 responses)
Posted Jan 8, 2009 14:33 UTC (Thu)
by hmh (subscriber, #3838)
[Link]
Well, maybe the mess with the firmware GR might have satisfied Eris enough, for once. Who knows...
Posted Jan 8, 2009 17:06 UTC (Thu)
by cine (guest, #5597)
[Link]
Posted Jan 12, 2009 2:12 UTC (Mon)
by nicku (guest, #777)
[Link]
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.
Posted Jan 13, 2009 3:14 UTC (Tue)
by paulmfoster (guest, #17313)
[Link]
If you hear something before we do, please let us know.
The Grumpy Editor's guide to 2009
The Grumpy Editor's guide to 2009
> becoming "legacy". Or, if one considers it to be legacy
> already, then it'll join the ranks of FORTRAN and COBOL
> and such as one of those ancient languages that demands
> a lot of skilled programmers in perpetuity.
The Grumpy Editor's guide to 2009
Small grammar fix?
Small grammar fix?
Small grammar fix?
Small grammar fix?
Small grammar fix?
The Grumpy Editor's guide to 2009
The Grumpy Editor's guide to 2009
The Grumpy Editor's guide to 2009
The Grumpy Editor's guide to 2009
The Grumpy Editor's guide to 2009
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.
The Grumpy Editor's guide to 2009
It is a hard time to be in the media business in general, and the free software realm offers challenges of its own even in the best of times. That said, LWN appears to be holding steady so far, thanks to thousands of readers who feel that this enterprise is worth supporting.
It's definitely starting out to be a 'make' rather than 'break' year for Perl 6. As chromatic says, there have been 14 on-time, monthly releases of the Rakudo implementation of Perl 6. I've been writing a PDF parser in Perl 6 as a way to learn the language. Already, I find the code more concise AND more readable than my Perl 5 implementation.
'make' year for Perl
'make' year for Perl
'make' year for Perl
'make' year for Perl
'make' year for Perl
'make' year for Perl
'make' year for Perl
'make' year for Perl
'make' year for Perl
'make' year for Perl
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.
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.
'make' year for Perl
'make' year for Perl
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?
'make' year for Perl
'make' year for Perl
'make' year for Perl
That will slow the flow of developers moving to other languages like python and ruby , however it won't reverse the trend. To reverse the trend it needs to be compelling to the people who left and to new developers.
3D Graphics
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
3D Graphics
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.
3D Graphics
A formerly friendly company may pull an SCO
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.
A formerly friendly company may pull an SCO
A formerly friendly company may pull an SCO
A formerly friendly company may pull an SCO
A formerly friendly company may pull an SCO
A formerly friendly company may pull an SCO
A formerly friendly company may pull an SCO
Depose is correct
A formerly friendly company may pull an SCO
A formerly friendly company may pull an SCO
Perl
Perl
That the language hasn't been updated in the last decade is also a sign of maturity....
Minor typo
Minor typo
The Grumpy Editor's guide to 2009
The Grumpy Editor's guide to 2009
The Grumpy Editor's guide to 2009
make-or-break year for Perl
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.
The Grumpy Editor's guide to 2009