Re:Difficult to understand?
on
Perl Turns 25
·
· Score: 1
Context dependent interpretation of the meaning of operators combined with operator over-loading creates tremendous problems with reading code others of written with any certainty of correct understanding.
Having recently parsed huge pile of financial Java code (Java doesn't support operator overload) which uses arbitrary precision numbers, let me tell you that the other side of what you describe isn't particularly rosy. In fact, even simple financial formula, in language like Java, with arbitrary precision number library, degrades into a monstrous clusterfuck of code which can be barely understood even under debugger. Compare with C++ or Perl: the math formula can be expressed literally as on paper.
The truth is we must deal with middle of the road to lowest denominator programmers and their work constantly, and defenses of languages that they are easily understood when written by gurus (and read by other gurus) is really an indictment not a defense.
That is a bull. One of the weakest developers in my department is in fact seasoned Perl programmer who has no problems reading through my 1-3 liners. (Though he has problems writing his own analogue in any language.)
You can quote as a problem relative unpopularity of Perl and resulting unfamiliarity of majority of developers with it. But, please, not again the old bull that it is hard to read Perl programs.
And herein lies the problem - program maintenance, which is normally counted as 80% of the cost of software life cycle.
As long term support goes, programming language or coding styles do not really matter that much. That is small stuff. Misapplied (or simply outdated!) top level tactics and global strategies, and resulting from them faults, problems and design gaps, are independent from programming language and are the major problem of the long-term maintainability of the code. They easily account for 80% of time spent on maintenance(*): because you can't easily close (or occasionally even forbidden to) close design gap in stable product; have to resort to piles of workarounds all over the place and then spend disproportional amount of time fighting the side-effects of the workarounds.
(*) And that is 80% which come out after the larger 80%: lion share of work maintenance does is trying to figure out what precisely customer is complaining about.
but most Perl "developers" are scripters, not programmers
This is, quite possibly, the stupidest thing I've ever read -- and I've been known to read the comments section on World Net Daily articles.
Yet it is true. Most Perl programs are too short to be called programs and are called scripts instead.
That is also helpful sometimes. I once write a program to repair proprietary binary files. Management immediately shot it down: we do not provide to customers stuff like that. But then I rewrote it in Perl and called it a script - and alas there are no limitations what we can do with the scripts!
Great plans are great, but how about decent Unicode/utf-8 support first??
Modern Perl 5 has excellent Unicode and UTF-8 support. What about it do you find lacking?
The fact that other languages, built to modern standards, do it much better. E.g. Python.
Also, by Perl's own standards Unicode support in Perl sucks: one has to jump through many hops before it works as expected. While in other modern languages it is out-of-box.
And heck, 25 years on - and we still do not have standard UI toolkit.
I don't know of any other scripting language (except Tcl) that does have a standard UI toolkit.
And that's the reason why it shouldn't be done?
Ironically, Tcl still persists in many niches, in part thanks to the Tk. Seasoned pros can build a useful - and portable - GUI in matter of minutes.
Python automatically guesses encodings, automatically normalizes into the proper form, automatically casefolds, and automatically applies the correct collations especially respecting the sources and sinks of data?
Yes, it actually can guess encodings(*). But also it simply has sane default for the text files: utf-8 (and allows explicit encoding specification). Strings are always Unicode (even if only ASCII is stored there). Python also validly assumes that the source code is also Unicode. Casafolding, collations - have no idea what they are, but in my experience "it just works." One doesn't need to do any additional hand-waving to open input text, open output text file and run code/regexps/etc on it, all properly Unicode aware out of box.
(*) AFAIK it properly reacts to the BOM in the beginning of the files.
That is also aggravated in Perl because (unlike in Python) there are no string manipulation functions - there are only regexps. And regexps in Perl (unlike in Python) by default are not Unicode-aware.
You can't imagine how nice it is to have the \w to match ALL word characters - without reading tons of silly bickering and escapism of why it can't be done easily in Perl or what dozens of gotchas I have to be aware of.
Just think of it: a fully Unicode aware shell filter in Python is shorter than in Perl. And we are still talking about future of the Perl??
Great plans are great, but how about decent Unicode/utf-8 support first??
Perl has exceptional support for Unicode. The accepted answer on this SO question provides a pretty comprehensive list of the challenges that Unicode brings, and why there cannot possibly be a magic "switch."
I've seen and read all the whining and bickering about why it can't be done. Somehow in the past there were no bickering about hardcoding ASCII support - but now, adding proper Unicode support is suddenly such an impossible task.
The simple truth is that it is obviously possible - Python does it out of box.
Such a switch would surely break a lot of code, so pre-UTF-8 code that needs to support UTF-8 does need to be updated, but writing modern Perl programs that support Unicode is really easy.
Most of the hardware which ran the old scripts has being literally completely retired. There is no point of being 100% compatible to the scripts which are not used anymore. I know it because I have participated in a number of migrations. Effort should have went into making it as simple as possible to update such scripts to support Unicode. I was in the shoes - with rather pathetic results: ASCII still rules Perl. Neither `use locale` nor `use utf8`/`use Unicode` facilitate in the least porting of the old scripts to new *nix systems, all of which are fully utf-8 based.
Also writing new scripts with Unicode support is still non-trivial and akin to a walking over minefield. That was at least my experience. I've spent at least two full weeks digging through the perlmonk archives to no avail. There are only hard ways: do lots of silly shite all over the scripts OR change the language, because, for example, Python doesn't have the problem at all.
Nope. `-C` controls only the IO specific options. It doesn't do anything else. It doesn't even tell Perl that the script itself is written in Unicode. All `-C` does is to remove pile of `use`s from the script beginning.
Wow. And I was looking for it for years too - fruitlessly.
And what would be the magic option to make the regexps Unicode-aware? so that e.g. \w would really match all word characters, and \s all possible spaces, and so on and so forth? The `/u` is pretty useless because one has to add it to all regexps in the program - and occasionally it also behaves illogically depending on other options (`use locale` and similar).
Re:Difficult to understand?
on
Perl Turns 25
·
· Score: 2
I simply was never able to form a mental model of how to use it correctly.
Perl is a multi-paradigm language. It doesn't bundle or insist on a particular model - you are free to use whatever model you want.
Great plans are great, but how about decent Unicode/utf-8 support first??
And by decent I mean a single global flip switch to tell the Perl that the script runs in Unicode/utf-8 only environment, all regexes should be Unicode aware, all file and directory names are Unicode, all text files are Unicode and so on and so forth. Well, you know, a switch to tell Perl interpreter that it runs on a system made in 21st century.
Otherwise, Perl is a great thing. But the bastard Unicode (and locale) support already makes it way too crippled for modern tasks.
Well I don't have a crystal ball but I cannot see the language fading from usage in the next quarter century
One doesn't have to have a crystal ball to see that Perl is slowly fading into irrelevance. Most mobile platforms BTW, just like desktops and servers, are fully Unicode compatible - unlike Perl.
And heck, 25 years on - and we still do not have standard UI toolkit.
Well, I had seen this problem for very very long time with the ATIs. First with Rage 128 Pro (with Intel CPU) and later with the 4850 (with AMD CPU). That's why during the last upgrade I went with the nVidia instead.
Though of course I have never thought about it as a problem(*) nor investigated it thoroughly: I have simply seen that unless one keeps graphics at low settings, ATIs tend to occasionally drop to 10-20 FPS from the usual 40-60. Last game - and very dated at that - I have tested with ATI 4850 was the Doom 3 and there are several places in the game where it was possible to reproduce the problem reliably.
(*) I always thought that it was "price of admission" because comparable nVidias at the time costed at least twice more.
A tablet should focus in interactivity. The kernel should respond to events as quickly as possible, throughput be damned. A supercomputer is the exact opposite end of the raw performance interactivity spectrum: crunch those numbers first, and then (if you have a break) look at the events/input.
You are confusing many things. Actually, "raw performance" as you put it - letting processes run uninterrupted - is also priority for the mobile devices. Because sooner they finish workload, sooner they can switch to power saving mode. That's also happens to be a rather normal modus operandi for OS schedulers for very very very long time. Context switches hurt in HPC applications - but they hurt even more on the mobiles.
Yes, power savings apply to everybody. But not everybody has the same needs in their kernel.
That might have been true some time ago, but for at least one decade, schedulers have reached the point where they can combine effectively IO bound and CPU bound processes. (Admittedly, most of the problems were hardware related, e.g. IDE bus with fixed timing.) Recently, not in the least part, because the most popular application on enterprise Linux - Oracle RDBMS - also requires that: IO for read-ins/write-outs and CPU for PL/SQL.
I'm not idealizing here. There are trade-offs for sure - specialized solution would always outdo generic one. But the ability to run highly varied workloads indiscriminately - and without any noticeable performance penalties - is precisely why people pick Linux.
The really interesting opportunity is to unify all of these different kinds of computing. Let's make one OS that runs on the phone AND on your supercomputer.
That just sounds horribly efficient. The needs of the different types of computer platforms are all quite divergent. The small power saving OS on a tablet focused on user interactions has almost no relation to what is needed to run a petaflop computing platform. They may both be based off the same core kernel but to have the same code just seems daffy.
Your example is already wrong.
Second largish group of Linux kernel developers interested in the power saving features was the HPC folks. Think of it, if you have a petaflop cluster, every saved watt on one node quickly translates into saved kilo/mega watts across the cluster. And the reason for interest is obvious: price of electricity keeps climbing up.
It went similarly with the hot-plug functionality: it's the same code in kernel which is responsible for the plug/unpug of a HDD on the storage and a USB stick on the desktop.
I have seen as much data corruptions on HP-UX/ia64, AIX/POWER and Solaris/SPARC boxes as on cheaper Linux/x86 and Linux/x64 boxes with SUSE or RHEL. I'm pretty sure in long term Solaris/x64 would show the same results.
Cause of most corruptions were faulty power supply or faulty memory module (and dumb admins who had ignored the ECC errors).
The only memorable software-induced corruption I can recall right now was on HP-UX/ia64. Some weird admins have exported all local files systems via NFS. And then, to "unify" configuration across all servers, they have imported them locally too and ran everything on the imported NFS. Yes: local disk <- NFS server <- NFS client. That didn't work well and caused piles of corruptions which have stopped as soon as the NFS->NFS layers was bypassed with few symlinks. So you see, even the exhaustively tested HP-UX 11 v2 - which still lacks VFS and the quoted reasons for that that HP tests in depth the file systems and thus they have to be integrated into the kernel - can fail.
fsync() is waaaay too slow. You could have at least recommended the fdatasync(), which is less slow. Or even better: opening files with O_SYNC/O_DSYNC flag.
The experimental nature of Linux IO subsystem, its unpredictability, is one of the reasons why some actually pick *BSD instead. OK, disk IO is slower than that of Linux, but at least one has sensible IO guarantees: data are written probably not right away, but without any great delay. (The only major problem of *BSD is the lack of drivers for the storage devices.)
P.S. In the past I had run a server with ext3/journaling (with slightly problematic experimental H/W) where this script was running in the background:
while sleep 1; sync; done
I found it to be a good compromise. The often sync of whole FS wasn't causing as much interactivity problems as I have expected (first sync might be slow, but consequent ones have much less work to do). On the other side, that was magnitude faster than fsync()ing every write() in the application.
Actually, the softies are pretty OK people. Unlike us, users, they see the screw-ups developing literally in slow motion, resulting in sub par end products and services delivered. (What requires rather high pain tolerance threshold on their part. Few manage to survive there.)
It's the career management and sales who are total [censored], killing all the good from the inside.
May I suggest that you don't have enough ambient light?
I do have enough of ambient light. But no amount of ambient light can help for a several hour long coding session. It simply too much for the eyes. Basically, in my environment I can work for about the same length of time, as I can read a paper book. What IMO is pretty good result.
For work on computer, my recipe remained steady for the decade plus: sufficient ambient light, dark background, light-gray text color - and large contrasty screen fonts.
You are sort of making lots of sense. But all you wrote IME is valid for books, paper and such. Based on my experience, things are starkly different when eyes have to deal with backlit screen.
By going with dark background, I simply reduce amount of backlight flashing constantly into my eyes. And increase the effect of ambient lighting. So in a way my setup actually fits what you call "bright working environment."
You can make a simple test with a flashlight: turn it on and look into it. If all you say is true, then you should definitely enjoy the experience.:)
You are right that a white background is good for the eyes, as long as it's not too lit. Reading on white background and CRTs was painful, and black background was better when LCD were not common.
But even on LCD, backlight still hurts - at least my eyes. I have no problems with paper and e-Ink - but when something flashes into my eyes, it becomes tiresome quite quickly.
It's much less of a problem on laptops, where one can quickly adjust brightness with the dedicated buttons. On PCs it is rather cumbersome. Going with dark background + choosing programs which allow to minimize bright areas to reduce stress due to high contrast is the way I do it. (Sadly only few programs allow full controls over the color palette, most default to system defaults which are way too impractical to change (since some applications use themes relying on light background)).
... but is this really better than good ol' Courier?
Personally, I find san-serif fonts a bit of a strain to read for long periods of time. For a while Lucida typewriter was fine but I keep switching back to Courier.
I have tried the font for 5 minutes in gvim. Then I have tried to try it again.
They went WAY overboard with the anti-aliasing: it's like the whole code is GLOWING. (It might be better on light background. But then, no sane coder uses a light background for coding, right?)
Went back to the usual Courier New (and the occasional Andale Mono).
So no, you are not a dinosaur. You simply have the rare condition: you're allergic to fads.
Does it integrate with KDE? with GNOME? Does it allow to use any of the services offered by the DEs? like for example multimedia? VFS? local network services? web? file viewers? access to user preferences? to system settings?
Answer is highly likely "No" and to pretty much everything on the list.
Compare. M$VB provides you access to the whole Windows, including all the innards, via OLE/ActiveX - because M$ kindly went on and added OLE interface to *everything* in Windows.
And where is the Linux analog of that? Hey, I'm not saying Linux needs an OLE. But it definitely needs some easy way to integrate all the thousands and thousands of the Linux libraries together. So that to developer adding a capability to the application is akin to clicking a checkbox - NOT days of hacking Makefiles and/or fancy project files to fix up the include paths, headers, linking dependencies and so on and so forth.
For my IMHO why desktop Linux lags, watch this video.
Linux has no infrastructure to support desktop developers. There is no Linux as a development environment. And it all changes too fast and too often - and diversity of distros is a separate bag of hurt. On top of that there are still piles of gaps. Classical one is the multimedia. Another one is the DB interface. Basically, you need a big-sized well-coordinated community to have a concerted development and maintenance of a Linux as a development platform.
Most importantly, one shouldn't forget: most desktop developers are ex-users and ex-power-users.
Windows and Mac OS make it very easy to transition from a user to a developer (VB and VBA, AppleScript and Automator). They also provide moderate guarantees that experience and skill will not expire too fast so that the time invested into coding something up will not be wasted and can be reused after the OS update. (Linux version: user starts with shell scripting... but that's direction rather opposite of the desktop.)
I can name only Qt as something what came close. But then it does not completely cover everything. KDE - yes. But there is no dumb abomination like VB which allows to build something useful in very short time or from copy-pasted samples gathered on google.
GNOME's Vala comes closer (at least from my initial impression of it), but unfortunately, it is bound to rather unpredictable GNOME project.
"I do not think any sensible developer would subject its users to the horrors of AWT or Swing"
personally I disagree and find Swing to be one of the most powerful and productive rich client toolkits out there.
Being horrible and being powerful are two totally different orthogonal things. Being a Asm/C/C++/Perl guy, I did actually code with Java/Swing for several months. Oh, yeah it's very very powerful. But at the same time it is totally platform agnostic (making user of any OS feel out of place), it doesn't conform to behavioral standards of the OS it runs on, and lastly it is f***ing slow. Developing large interactive, stutter-free UI in Swing in the past (my past, something like 7 years ago) proved to be fruitless. (Eclipse UI toolkit is much much much better, but not portable.)
and the libraries change on each target platform
Now that is a good reason to pick Java.
I do it in C++ for ~5 platforms and yeah it can be PITA. C++'s Xerces alone cause about 30 person/days of problems per year. (But Xerces was self-inflicted pain: majority of developers wanted Xerces because it cool, while much more portable and robust libxml is too easy and thus not cool.) Orcale's C/C++ client is also pile of crap, causing constant portability grievances (e.g. Linux/x64 library exports public symbol "int count;" - and also about 40 symbols conflicting with the standard functions from libc; OK Oracle can be worked around nicely but most of our R&D don't even grasp in-depth what a dynamic-linked library is).
Sparing all the troubles by going with Java is a good technical reason.
Hence, I still see Java as the premier choice of platform for my project (which is what the parent of my original post disputed
I disputed not the choice of Java, but the reasons why Java is better.
As a C guy, I somehow managed to learn better than most Java guys the actual advantages of the Java. The "Java is the best!" and "OMG look at the $$$ Minecraft does", sorry, do not cut for technical reasons.
Though specifically for the games, I'm wondering about the Java choice - again for the interactivity reasons. We have a very fresh debacle where a Java application performance for no apparent reason degrades over time: after 6 hours of run-time, processing speed halves. Another older example is a latency-sensitive application which pretty often gets 1.5s latency spikes (== GC runs) what is about 30 times higher than allowed. (Googling for "Minecraft stutter" and "Minecraft lag" shows that the problem is not unique to our applications.)
Slashdot Mirror
Context dependent interpretation of the meaning of operators combined with operator over-loading creates tremendous problems with reading code others of written with any certainty of correct understanding.
Having recently parsed huge pile of financial Java code (Java doesn't support operator overload) which uses arbitrary precision numbers, let me tell you that the other side of what you describe isn't particularly rosy. In fact, even simple financial formula, in language like Java, with arbitrary precision number library, degrades into a monstrous clusterfuck of code which can be barely understood even under debugger. Compare with C++ or Perl: the math formula can be expressed literally as on paper.
The truth is we must deal with middle of the road to lowest denominator programmers and their work constantly, and defenses of languages that they are easily understood when written by gurus (and read by other gurus) is really an indictment not a defense.
That is a bull. One of the weakest developers in my department is in fact seasoned Perl programmer who has no problems reading through my 1-3 liners. (Though he has problems writing his own analogue in any language.)
You can quote as a problem relative unpopularity of Perl and resulting unfamiliarity of majority of developers with it. But, please, not again the old bull that it is hard to read Perl programs.
And herein lies the problem - program maintenance, which is normally counted as 80% of the cost of software life cycle.
As long term support goes, programming language or coding styles do not really matter that much. That is small stuff. Misapplied (or simply outdated!) top level tactics and global strategies, and resulting from them faults, problems and design gaps, are independent from programming language and are the major problem of the long-term maintainability of the code. They easily account for 80% of time spent on maintenance(*): because you can't easily close (or occasionally even forbidden to) close design gap in stable product; have to resort to piles of workarounds all over the place and then spend disproportional amount of time fighting the side-effects of the workarounds.
(*) And that is 80% which come out after the larger 80%: lion share of work maintenance does is trying to figure out what precisely customer is complaining about.
but most Perl "developers" are scripters, not programmers
This is, quite possibly, the stupidest thing I've ever read -- and I've been known to read the comments section on World Net Daily articles.
Yet it is true. Most Perl programs are too short to be called programs and are called scripts instead.
That is also helpful sometimes. I once write a program to repair proprietary binary files. Management immediately shot it down: we do not provide to customers stuff like that. But then I rewrote it in Perl and called it a script - and alas there are no limitations what we can do with the scripts!
Modern Perl 5 has excellent Unicode and UTF-8 support. What about it do you find lacking?
The fact that other languages, built to modern standards, do it much better. E.g. Python.
Also, by Perl's own standards Unicode support in Perl sucks: one has to jump through many hops before it works as expected. While in other modern languages it is out-of-box.
I don't know of any other scripting language (except Tcl) that does have a standard UI toolkit.
And that's the reason why it shouldn't be done?
Ironically, Tcl still persists in many niches, in part thanks to the Tk. Seasoned pros can build a useful - and portable - GUI in matter of minutes.
Python automatically guesses encodings, automatically normalizes into the proper form, automatically casefolds, and automatically applies the correct collations especially respecting the sources and sinks of data?
Yes, it actually can guess encodings(*). But also it simply has sane default for the text files: utf-8 (and allows explicit encoding specification). Strings are always Unicode (even if only ASCII is stored there). Python also validly assumes that the source code is also Unicode. Casafolding, collations - have no idea what they are, but in my experience "it just works." One doesn't need to do any additional hand-waving to open input text, open output text file and run code/regexps/etc on it, all properly Unicode aware out of box.
(*) AFAIK it properly reacts to the BOM in the beginning of the files.
That is also aggravated in Perl because (unlike in Python) there are no string manipulation functions - there are only regexps. And regexps in Perl (unlike in Python) by default are not Unicode-aware.
You can't imagine how nice it is to have the \w to match ALL word characters - without reading tons of silly bickering and escapism of why it can't be done easily in Perl or what dozens of gotchas I have to be aware of.
Just think of it: a fully Unicode aware shell filter in Python is shorter than in Perl. And we are still talking about future of the Perl??
Great plans are great, but how about decent Unicode/utf-8 support first??
Perl has exceptional support for Unicode. The accepted answer on this SO question provides a pretty comprehensive list of the challenges that Unicode brings, and why there cannot possibly be a magic "switch."
I've seen and read all the whining and bickering about why it can't be done. Somehow in the past there were no bickering about hardcoding ASCII support - but now, adding proper Unicode support is suddenly such an impossible task.
The simple truth is that it is obviously possible - Python does it out of box.
Such a switch would surely break a lot of code, so pre-UTF-8 code that needs to support UTF-8 does need to be updated, but writing modern Perl programs that support Unicode is really easy.
Most of the hardware which ran the old scripts has being literally completely retired. There is no point of being 100% compatible to the scripts which are not used anymore. I know it because I have participated in a number of migrations. Effort should have went into making it as simple as possible to update such scripts to support Unicode. I was in the shoes - with rather pathetic results: ASCII still rules Perl. Neither `use locale` nor `use utf8`/`use Unicode` facilitate in the least porting of the old scripts to new *nix systems, all of which are fully utf-8 based.
Also writing new scripts with Unicode support is still non-trivial and akin to a walking over minefield. That was at least my experience. I've spent at least two full weeks digging through the perlmonk archives to no avail. There are only hard ways: do lots of silly shite all over the scripts OR change the language, because, for example, Python doesn't have the problem at all.
Nope. `-C` controls only the IO specific options. It doesn't do anything else. It doesn't even tell Perl that the script itself is written in Unicode. All `-C` does is to remove pile of `use`s from the script beginning.
Wow. And I was looking for it for years too - fruitlessly.
And what would be the magic option to make the regexps Unicode-aware? so that e.g. \w would really match all word characters, and \s all possible spaces, and so on and so forth? The `/u` is pretty useless because one has to add it to all regexps in the program - and occasionally it also behaves illogically depending on other options (`use locale` and similar).
I simply was never able to form a mental model of how to use it correctly.
Perl is a multi-paradigm language. It doesn't bundle or insist on a particular model - you are free to use whatever model you want.
Great plans are great, but how about decent Unicode/utf-8 support first??
And by decent I mean a single global flip switch to tell the Perl that the script runs in Unicode/utf-8 only environment, all regexes should be Unicode aware, all file and directory names are Unicode, all text files are Unicode and so on and so forth. Well, you know, a switch to tell Perl interpreter that it runs on a system made in 21st century.
Otherwise, Perl is a great thing. But the bastard Unicode (and locale) support already makes it way too crippled for modern tasks.
Well I don't have a crystal ball but I cannot see the language fading from usage in the next quarter century
One doesn't have to have a crystal ball to see that Perl is slowly fading into irrelevance. Most mobile platforms BTW, just like desktops and servers, are fully Unicode compatible - unlike Perl.
And heck, 25 years on - and we still do not have standard UI toolkit.
Well, I had seen this problem for very very long time with the ATIs. First with Rage 128 Pro (with Intel CPU) and later with the 4850 (with AMD CPU). That's why during the last upgrade I went with the nVidia instead.
Though of course I have never thought about it as a problem(*) nor investigated it thoroughly: I have simply seen that unless one keeps graphics at low settings, ATIs tend to occasionally drop to 10-20 FPS from the usual 40-60. Last game - and very dated at that - I have tested with ATI 4850 was the Doom 3 and there are several places in the game where it was possible to reproduce the problem reliably.
(*) I always thought that it was "price of admission" because comparable nVidias at the time costed at least twice more.
A tablet should focus in interactivity. The kernel should respond to events as quickly as possible, throughput be damned. A supercomputer is the exact opposite end of the raw performance interactivity spectrum: crunch those numbers first, and then (if you have a break) look at the events/input.
You are confusing many things. Actually, "raw performance" as you put it - letting processes run uninterrupted - is also priority for the mobile devices. Because sooner they finish workload, sooner they can switch to power saving mode. That's also happens to be a rather normal modus operandi for OS schedulers for very very very long time. Context switches hurt in HPC applications - but they hurt even more on the mobiles.
Yes, power savings apply to everybody. But not everybody has the same needs in their kernel.
That might have been true some time ago, but for at least one decade, schedulers have reached the point where they can combine effectively IO bound and CPU bound processes. (Admittedly, most of the problems were hardware related, e.g. IDE bus with fixed timing.) Recently, not in the least part, because the most popular application on enterprise Linux - Oracle RDBMS - also requires that: IO for read-ins/write-outs and CPU for PL/SQL.
I'm not idealizing here. There are trade-offs for sure - specialized solution would always outdo generic one. But the ability to run highly varied workloads indiscriminately - and without any noticeable performance penalties - is precisely why people pick Linux.
The really interesting opportunity is to unify all of these different kinds of computing. Let's make one OS that runs on the phone AND on your supercomputer.
That just sounds horribly efficient. The needs of the different types of computer platforms are all quite divergent. The small power saving OS on a tablet focused on user interactions has almost no relation to what is needed to run a petaflop computing platform. They may both be based off the same core kernel but to have the same code just seems daffy.
Your example is already wrong.
Second largish group of Linux kernel developers interested in the power saving features was the HPC folks. Think of it, if you have a petaflop cluster, every saved watt on one node quickly translates into saved kilo/mega watts across the cluster. And the reason for interest is obvious: price of electricity keeps climbing up.
It went similarly with the hot-plug functionality: it's the same code in kernel which is responsible for the plug/unpug of a HDD on the storage and a USB stick on the desktop.
There is more to it than meets the eye.
Gamer activity generates more than 500 GB of structured data and over four TB of operational logs every day.
Fits in RAM of a single, well stocked server.
Just sayin'.
I have seen as much data corruptions on HP-UX/ia64, AIX/POWER and Solaris/SPARC boxes as on cheaper Linux/x86 and Linux/x64 boxes with SUSE or RHEL. I'm pretty sure in long term Solaris/x64 would show the same results.
Cause of most corruptions were faulty power supply or faulty memory module (and dumb admins who had ignored the ECC errors).
The only memorable software-induced corruption I can recall right now was on HP-UX/ia64. Some weird admins have exported all local files systems via NFS. And then, to "unify" configuration across all servers, they have imported them locally too and ran everything on the imported NFS. Yes: local disk <- NFS server <- NFS client. That didn't work well and caused piles of corruptions which have stopped as soon as the NFS->NFS layers was bypassed with few symlinks. So you see, even the exhaustively tested HP-UX 11 v2 - which still lacks VFS and the quoted reasons for that that HP tests in depth the file systems and thus they have to be integrated into the kernel - can fail.
fsync() is waaaay too slow. You could have at least recommended the fdatasync(), which is less slow. Or even better: opening files with O_SYNC/O_DSYNC flag.
The experimental nature of Linux IO subsystem, its unpredictability, is one of the reasons why some actually pick *BSD instead. OK, disk IO is slower than that of Linux, but at least one has sensible IO guarantees: data are written probably not right away, but without any great delay. (The only major problem of *BSD is the lack of drivers for the storage devices.)
P.S. In the past I had run a server with ext3/journaling (with slightly problematic experimental H/W) where this script was running in the background:
while sleep 1; sync; done
I found it to be a good compromise. The often sync of whole FS wasn't causing as much interactivity problems as I have expected (first sync might be slow, but consequent ones have much less work to do). On the other side, that was magnitude faster than fsync()ing every write() in the application.
I hereby officially announce George Carlin to be our prophet.
Actually, the softies are pretty OK people. Unlike us, users, they see the screw-ups developing literally in slow motion, resulting in sub par end products and services delivered. (What requires rather high pain tolerance threshold on their part. Few manage to survive there.)
It's the career management and sales who are total [censored], killing all the good from the inside.
if you took microsoft out of this story you would have no argument against it
If you took M$ out of this story, there would be no story. Programming languages are thousand a dime this days.
QED.
May I suggest that you don't have enough ambient light?
I do have enough of ambient light. But no amount of ambient light can help for a several hour long coding session. It simply too much for the eyes. Basically, in my environment I can work for about the same length of time, as I can read a paper book. What IMO is pretty good result.
For work on computer, my recipe remained steady for the decade plus: sufficient ambient light, dark background, light-gray text color - and large contrasty screen fonts.
You are sort of making lots of sense. But all you wrote IME is valid for books, paper and such. Based on my experience, things are starkly different when eyes have to deal with backlit screen.
By going with dark background, I simply reduce amount of backlight flashing constantly into my eyes. And increase the effect of ambient lighting. So in a way my setup actually fits what you call "bright working environment."
You can make a simple test with a flashlight: turn it on and look into it. If all you say is true, then you should definitely enjoy the experience. :)
You are right that a white background is good for the eyes, as long as it's not too lit. Reading on white background and CRTs was painful, and black background was better when LCD were not common.
But even on LCD, backlight still hurts - at least my eyes. I have no problems with paper and e-Ink - but when something flashes into my eyes, it becomes tiresome quite quickly.
It's much less of a problem on laptops, where one can quickly adjust brightness with the dedicated buttons. On PCs it is rather cumbersome. Going with dark background + choosing programs which allow to minimize bright areas to reduce stress due to high contrast is the way I do it. (Sadly only few programs allow full controls over the color palette, most default to system defaults which are way too impractical to change (since some applications use themes relying on light background)).
... but is this really better than good ol' Courier?
Personally, I find san-serif fonts a bit of a strain to read for long periods of time. For a while Lucida typewriter was fine but I keep switching back to Courier.
I have tried the font for 5 minutes in gvim. Then I have tried to try it again.
They went WAY overboard with the anti-aliasing: it's like the whole code is GLOWING. (It might be better on light background. But then, no sane coder uses a light background for coding, right?)
Went back to the usual Courier New (and the occasional Andale Mono).
So no, you are not a dinosaur. You simply have the rare condition: you're allergic to fads.
Does it integrate with KDE? with GNOME? Does it allow to use any of the services offered by the DEs? like for example multimedia? VFS? local network services? web? file viewers? access to user preferences? to system settings?
Answer is highly likely "No" and to pretty much everything on the list.
Compare. M$VB provides you access to the whole Windows, including all the innards, via OLE/ActiveX - because M$ kindly went on and added OLE interface to *everything* in Windows.
And where is the Linux analog of that? Hey, I'm not saying Linux needs an OLE. But it definitely needs some easy way to integrate all the thousands and thousands of the Linux libraries together. So that to developer adding a capability to the application is akin to clicking a checkbox - NOT days of hacking Makefiles and/or fancy project files to fix up the include paths, headers, linking dependencies and so on and so forth.
For my IMHO why desktop Linux lags, watch this video.
Linux has no infrastructure to support desktop developers. There is no Linux as a development environment. And it all changes too fast and too often - and diversity of distros is a separate bag of hurt. On top of that there are still piles of gaps. Classical one is the multimedia. Another one is the DB interface. Basically, you need a big-sized well-coordinated community to have a concerted development and maintenance of a Linux as a development platform.
Most importantly, one shouldn't forget: most desktop developers are ex-users and ex-power-users.
Windows and Mac OS make it very easy to transition from a user to a developer (VB and VBA, AppleScript and Automator). They also provide moderate guarantees that experience and skill will not expire too fast so that the time invested into coding something up will not be wasted and can be reused after the OS update. (Linux version: user starts with shell scripting ... but that's direction rather opposite of the desktop.)
I can name only Qt as something what came close. But then it does not completely cover everything. KDE - yes. But there is no dumb abomination like VB which allows to build something useful in very short time or from copy-pasted samples gathered on google.
GNOME's Vala comes closer (at least from my initial impression of it), but unfortunately, it is bound to rather unpredictable GNOME project.
"I do not think any sensible developer would subject its users to the horrors of AWT or Swing"
personally I disagree and find Swing to be one of the most powerful and productive rich client toolkits out there.
Being horrible and being powerful are two totally different orthogonal things. Being a Asm/C/C++/Perl guy, I did actually code with Java/Swing for several months. Oh, yeah it's very very powerful. But at the same time it is totally platform agnostic (making user of any OS feel out of place), it doesn't conform to behavioral standards of the OS it runs on, and lastly it is f***ing slow. Developing large interactive, stutter-free UI in Swing in the past (my past, something like 7 years ago) proved to be fruitless. (Eclipse UI toolkit is much much much better, but not portable.)
and the libraries change on each target platform
Now that is a good reason to pick Java.
I do it in C++ for ~5 platforms and yeah it can be PITA. C++'s Xerces alone cause about 30 person/days of problems per year. (But Xerces was self-inflicted pain: majority of developers wanted Xerces because it cool, while much more portable and robust libxml is too easy and thus not cool.) Orcale's C/C++ client is also pile of crap, causing constant portability grievances (e.g. Linux/x64 library exports public symbol "int count;" - and also about 40 symbols conflicting with the standard functions from libc; OK Oracle can be worked around nicely but most of our R&D don't even grasp in-depth what a dynamic-linked library is).
Sparing all the troubles by going with Java is a good technical reason.
Hence, I still see Java as the premier choice of platform for my project (which is what the parent of my original post disputed
I disputed not the choice of Java, but the reasons why Java is better.
As a C guy, I somehow managed to learn better than most Java guys the actual advantages of the Java. The "Java is the best!" and "OMG look at the $$$ Minecraft does", sorry, do not cut for technical reasons.
Though specifically for the games, I'm wondering about the Java choice - again for the interactivity reasons. We have a very fresh debacle where a Java application performance for no apparent reason degrades over time: after 6 hours of run-time, processing speed halves. Another older example is a latency-sensitive application which pretty often gets 1.5s latency spikes (== GC runs) what is about 30 times higher than allowed. (Googling for "Minecraft stutter" and "Minecraft lag" shows that the problem is not unique to our applications.)