On Jan 6, 2015, at 11:43 AM, Les Mikesell <lesmikesell at gmail.com> wrote: > On Mon, Jan 5, 2015 at 9:22 PM, Warren Young <wyml at etr-usa.com> wrote: > > So, after you've spent at least 10 years rolling out machines to do > things as fast as you can, and teaching the others in your > organization to spell 'chkconfig' and use 'system ...' commands, > wouldn't you rather continue to be productive and do more instead of > having to start over and re-do the same set of things over again just > to keep the old stuff working? Having been through a bunch of these transitions already (SysV -> Linux bingo -> BSD -> OS X…) it doesn’t greatly bother me. Given that I’ve spent more time on Red Hattish Linuxes than any other *ix, I suppose I’m more surprised it’s lasted as long as it has than I am upset that it’s changing again. >> There are more JavaScript interpreters in the world than Dalvik, ART,[2] and Java ® VMs combined. Perhaps we should rewrite everything in JavaScript instead? > > I'm counting the running/useful instances of actual program code, I rather doubt you’ve done anything like actual research on this. If you’re just buying Oracle’s bogus “3 billion” number uncritically, there are a bunch of problems with that, but I’d have to drag us off topic to discuss them. In any case, *ix falls into the noise floor if this is the scale you’re using to gauge the success of Java. If you’re trying to say that there’s more CPU-hours of JVM use on *ix than JS in browsers, that sort of elitist argument has been repeatedly defeated. Big Iron vs minicomputers, Unix workstations vs the PC, “real” Unix vs Linux, the PC vs the smartphone… Time and time again, the forces driving the end-user market end up taking over the hrumph hrumph serious computing market. This has already happened with JS vs Java in the “3 billion” space Oracle wants to claim, and I see no reason why it can’t eventually steamroll the *ix world, too, via node.js. Even if you wave a magic wand and get the JVM onto every *ix box — which is currently very much *not* the case — you’re ignoring the Tiobe numbers I posted in the previous reply. There’s plenty to argue about when it comes to Tiobe’s methodology, but not so much that you can scrape together anything like a majority for any single language. I think the real difference we have on this point is that I’m not actually serious when I propose that the whole world rewrite all software in My Favorite Language just to make my job easier. > JavaScript > is on the rise mostly because the interpreters upgrade transparently > and the hassle is somewhat hidden. No, JavaScript is on the rise because the web is on the rise, and it managed to secure the spot as the web’s scripting language through an accident of history. That is all. > Otherwise we would pretty quickly have all of the programs anyone > needs completed. "There is nothing new to be discovered in physics now. All that remains is more and more precise measurement.” — William Thomson, Lord Kelvin, 1900 Yes, *that* Kelvin. > I thought CPAN was approaching that long ago, or at > least getting to the point where the new code you have to write to do > about anything would take about half a page of calls to existing > modules. Ah yes, the ever-near future where everyone will plug a few Lego-like software blocks together and thereby construct any useful program they wish, while lacking any clue about what’s going on. That future’s been 5 years away for the past 5 decades. It’s as likely today as ever — which is to say, “not” — and it isn’t the Fedora development community’s fault that we have not yet achieved this nirvana. Even in electronics, where you have physics to constrain the set of possible realizations, we haven’t even approached this level of nirvana. For every Arduino success story, you have ten stories of cluebies who burned up their H bridge motor driver because they didn’t understand that P=I²R, and that R is almost never zero. (If R is zero, you’re dealing with cryogenics, so all you’ve done is shifted into a different class of cluebie errors that’s more likely to leave said cluebie injured.) Software is “pure thought-stuff,” to quote Fred Brooks. We have very little constraint on the scope and range of things we can create in software. Any attempt to package software up into a usefully-small set of precisely-characterized little black boxes is a Quixotic dream. >> Why even bother with ksh or Bash extensions, for that matter? The original Bourne shell achieved Turing-completeness in 1977. There is literally nothing we can ask a computer to do that we cannot cause to happen via a shell script. (Except run fast.) > > Well, Bourne didn't deal with sockets. BSD Sockets didn’t exist in 1977. In any case, you’re willfully ignoring the nature of *ix type shell script programming. A shell script’s “function library” is the set of all programs in the PATH. Drop nc/ncat/netcat/socat in the PATH, and suddenly your shell script knows how to talk to BSD sockets. It’s really no different than installing libnsl on a Solaris box. No nc-alike here? Okay, echo the machine code to disk for an ELF binary that makes the necessary syscalls, using octal escapes. No, don’t cheat and echo out a C or assembly language program, go straight to the metal, you softie. > My opinion is that you'd be > better off switching to perl at the first hint of needing > arrays/sockets or any library modules that already exist in CPAN > instead of extending a shell beyond the basic shell-ish stuff. And there you are, foot on the slippery slope; down you go. Perl is even less widely deployed than Java. It isn’t even on all *ixes by default. The BSDs, Cygwin, and Arch (at least) all leave it out of the stock install. POSIX doesn’t require it, so it also isn’t in most small embedded *ix systems, where you at least find a POSIX shell. If you were to try to get Perl into POSIX, I think you’d fail. Perl 5 is just too big and hairy. No one is going to try to reimplement the whole thing. Python has been reimplemented several times, but I think it’s still got a smaller installed base than Perl, simply due to getting popular later. Lua’s small enough to reimplement relatively easily, but not powerful enough on its own to rival the POSIX shell as a general-purpose *ix programming system. It needs to be embedded into something else, which provides a richer function library. Ruby and Scheme are powerful and small enough to make it as a stepping stone in POSIX between shell and C, but not popular enough to win the war a champion for either would have to fight to accomplish it. There you have the mess. There is no universally-installed language today that fills the gap between shell and C, and there’s no likely prospect for such a thing. You can’t just wish it away by telling everyone to switch to Java, or JavaScript, or whatever else. All you’re going to do is create another “standard” in the XKCD sense: https://xkcd.com/927/ > pretty much anything you ever wrote in perl will still work. That’s becoming less true as Perl becomes stricter. A lot of old code won’t run without warnings any more, and if you turn on things like “use strict,” as Perl books have been recommending for over a decade, a huge amount of old code won’t even run. Then you have the Modern Perl movement, which is responsible for the increase of CPAN modules that only work on Perl 5.10+. http://www.josetteorama.com/what-is-modern-perl/ Since the capacity of the Perl developers is not infinite, this movement will cause more and more old Perl mechanisms to be deprecated, so that they can eventually be removed. Perl 6 was an attempt to achieve this in one big jump. Perl 5 is in the process of slowly accreting some of Perl 6’s features. Eventually, I think the jump to Perl 6 won’t look so big, and Perl 6 will finally get off the ground. Perhaps even soon. > holding off on python and ruby until they have a similar history of > not breaking your existing work with incompatible updates. Those counters both got reset relatively recently: the Python 3 (neé 3000) and Ruby 1.9 transitions were fairly traumatic. I’m sure Oracle wishes Java 6 would disappear finally, too. There is no sanctuary, Les. Change is everywhere in computing. >> Or were you planning on demanding that EL5 be supported forever, with no changes, except for magical cost-free features? > > No, what I wish is that every change would be vetted by people > actively managing large sets of systems EL7 had a long beta period. Where were you? Yeah, I know, not your job. But since you’re choking throats over here on the CentOS ML instead of choking Red Hat’s throat via a RHEL support contract, I think that puts the responsibility on your shoulders. You can’t expect someone else to scratch your itch just because you loudly demand it on the Internet. You either have to pay for it somehow, or hope that someone else also has your itch *and* wishes to pay for it themselves. Is that all this is? Trying to get someone else riled up enough that they’ll fork EL6 for you?