On Tue, Jan 6, 2015 at 5:07 PM, Warren Young <wyml@xxxxxxxxxxx> 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
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
