On Tue, Jan 6, 2015 at 5:07 PM, Warren Young <w...@etr-usa.com> wrote: > >>> 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.
Not really, but start with the number of running android devices - and I think it is reasonable to assume that they are running something, checking gmail, etc. It's safe enough to say that's a big number. > 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… No, I'm saying it pretty much owns the phone/tablet space and the examples of elasticsearch (and other lucene-based stuff), jenkins, etc. show it scales to the other end as well. > 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. node.js seems like the worst of all worlds - a language designed _not_ to speak to the OS directly with an OS library glued in. But it is a good example of how programmers think - if one says you shouldn't do something, it pretty much guarantees that someone else will. > 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. I'd settle for just not changing the languages in ways that break already written software. But even that seems too much to expect. >> 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. I think you are underestimating the way the working interpreters get to the users. And the way the code libraries mask the differences. If users were exposed to version incompatibilities the popularity would vanish. In fact, being able to actively detect and work around incompatibilities is a large part of the reason it is used at all. >> 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. Not it the sense that there's nothing new to invent, but that every sysadmin in every organization and every home user should not need to invent new processes to manage their machines. > 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. Really? How have they made it any easier to manage your 2nd machine than your first? > 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. It is also purely reproducible. Do something right once and no one should ever have to waste that thought again. >>> 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. Precisely. Once there was close to a 1-1 mapping of shell and external commands to system calls. Now there isn't. > 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. I wasn't ignoring it. I just was avoiding another rant about how those have not been maintained in a backwards compatible way either. Even though shell syntax is stable, the programs are usually just glue around an assortment of tools that no longer match section 1 of the unix manuals. > 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. I might have done that for 8-bit z80 code, but I've since learned that it is rarely worth getting that intimate with the hardware. > 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/ Well no, at this point you can't say that java is yet another new thing - probably not even groovy since that's mix/match with java. Maybe scala. > > 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. I think everyone involved with perl is sane enough to know that perl 6 is not a replacement for perl 5. It's something different. I just hope the Fedora people get it. >> 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. Well, I've avoided a couple of traumas then. But those transitions don't seem to have completed. And they probably won't until all distros ship multiple versions so programs can co-exist long enough to fix the broken parts. > Is that all this is? Trying to get someone else riled up enough that they’ll > fork EL6 for you? No - mostly hoping someone would point out something I had overlooked that makes the transition easy. I thought the computers were supposed to work for us instead of the other way around. -- Les Mikesell lesmikes...@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
