Reminds me of chicken little in The Space Merchants. http://en.wikipedia.org/wiki/The_Space_Merchants. A major source of protein for an over-populated world was this vast mass of growing tissue, which advertising convinced people that it tasted good.
Re:For me Perl is alive and well.
on
Perl 5.14 Released
·
· Score: 4, Interesting
I agree completely. As a UNIX sysadmin I frequently write scripts. For short and simple things, shell is preferred. But if I anticipate any complexity, I reach for Perl. I've had the experience of getting deeply into a shell script and thinking "I should have used Perl". Perl has never let me down, although I confess at times the programs have that write-only, line-noise appearance. But that's just because I've learned to use the idioms, and I comment on the complex stuff for the benefit of those who follow me--which could include myself six months later.
I'd write Ruby if I could. The syntax is cleaner, and objects are built-in, not bolted on. But Ruby is just not available where I need it. Does anybody know of an AIX LPP package for Ruby?
Also, I've been deeply disappointed at the progress of Perl 6--but Perl 5 does everything I need, so I really don't miss it. Of all sad words of tongue or pen, the saddest are these--it might have been.
I don't see where anyone has yet mentioned Doug Crockford's excellent videos on JavaScript. These are all on YUI theater. http://developer.yahoo.com/yui/theater/ All the criticisms mentioned here are discussed in depth. Crockford deals with the good and bad parts of JavaScript from the perspective of years of detailed research on it. And like it or no, JS is available in a useful, common subset on all modern browsers. The whole HTML, CSS, DOM, JavaScript ball of wax is a kludge that happened by the chaos of historic accident. But we are stuck with them, and Crockford's notions of how to do JS right are worth your time in viewing the videos.
I know this is/., but seriously now....Real-time collection and reporting of blood pressure, heart rate (or not!), glucose, cholesterol, liver enzymes, O2 and PSA levels, all relayed via your cellphone/base station to your trusted medical service. These are right around the corner, awaiting only the right transducers. I, for one, welcome our new medical capabilities.
The System z hardware is no more EBCDIC than you are. z/Linux uses ASCII for messages, commands, and utilities, just as z/OS uses EBCDIC. The z/Linux choices include ports of RedHat and Suse. The port does not include translating these to EBCDIC.
Now, the old native Unix for z/OS, Unix System Services, *was* an EBCDIC Unix. Nothing ever said Unix had to be based on ASCII. Porting programs to USS was a challenge because too many programs made assumptions about the binary value of characters. Usually the fixes were simple, but sometimes the defects were hard to find. But if an assumption was made about the collating sequence, the problem was harder.
If by "program" you mean a stored program on what is conventionally meant by a computer today, I have a candidate. IEFBR14 was used on the earliest version of OS/360 in 1964 as a do-nothing program. It is still in use today, unchanged on the latest version of z/OS. Its function is to execute a JCL step which does nothing, but in the process of doing nothing, the job scheduler is invoked. This is one method of creating and deleting datasets (files). It is also the shortest valid OS/360 (and z/OS) program, containing two executable assembler statements and two assembler directives. The comments are mine.
IEFBR14 CSECT START PROGRAM SECTION SR 15,15 SET EXIT CODE TO 0 BR 14 RETURN AND EXIT END TELL ASSEMBLER END OF PROGRAM
Interestingly, the first version of this program had a bug, which was subsequently corrected by doubling the program length. It omitted the SR 15,15 statement, which meant that at program exit register 15 had an unpredictable value -- and the program exit code was therefore unpredictable. Since a zero exit code is used to guide the conditional execution of subsequent steps, a failure could be indicated when there was none.
And contrary to another post, I believe there are a lot of people with computer experience predating 1970 who read Slashdot. But I don't want to start a flame war over that.
Slashdot Mirror
What this technology is missing is a tie-in to blockchain. If they can find that, it will close the hype loop.
It was a great book. Now I know why the movies stank.
Bird cuisinarts. http://ireport.cnn.com/docs/DO....
Reminds me of chicken little in The Space Merchants. http://en.wikipedia.org/wiki/The_Space_Merchants. A major source of protein for an over-populated world was this vast mass of growing tissue, which advertising convinced people that it tasted good.
Yes, Khan Academy is on Roku.
http://www.roku-channels.com/
http://www.rokuguide.com/channels/khan-academy
More at:
http://hiddenchannel.com/
I smell a patent application coming on....
I agree completely. As a UNIX sysadmin I frequently write scripts. For short and simple things, shell is preferred. But if I anticipate any complexity, I reach for Perl. I've had the experience of getting deeply into a shell script and thinking "I should have used Perl". Perl has never let me down, although I confess at times the programs have that write-only, line-noise appearance. But that's just because I've learned to use the idioms, and I comment on the complex stuff for the benefit of those who follow me--which could include myself six months later.
I'd write Ruby if I could. The syntax is cleaner, and objects are built-in, not bolted on. But Ruby is just not available where I need it. Does anybody know of an AIX LPP package for Ruby?
Also, I've been deeply disappointed at the progress of Perl 6--but Perl 5 does everything I need, so I really don't miss it. Of all sad words of tongue or pen, the saddest are these--it might have been.
I don't see where anyone has yet mentioned Doug Crockford's excellent videos on JavaScript. These are all on YUI theater. http://developer.yahoo.com/yui/theater/ All the criticisms mentioned here are discussed in depth. Crockford deals with the good and bad parts of JavaScript from the perspective of years of detailed research on it. And like it or no, JS is available in a useful, common subset on all modern browsers. The whole HTML, CSS, DOM, JavaScript ball of wax is a kludge that happened by the chaos of historic accident. But we are stuck with them, and Crockford's notions of how to do JS right are worth your time in viewing the videos.
I know this is /., but seriously now....Real-time collection and reporting of blood pressure, heart rate (or not!), glucose, cholesterol, liver enzymes, O2 and PSA levels, all relayed via your cellphone/base station to your trusted medical service. These are right around the corner, awaiting only the right transducers. I, for one, welcome our new medical capabilities.
To say nothing of the Power 7 795, which scales to 256 cores with 4-way SMT, for 1024 hardware threads.
http://www-03.ibm.com/systems/power/hardware/795/index.html
And AIX 7 will handle this in a single-system image:
http://www-03.ibm.com/systems/power/software/aix/v71/preview.html
Desktop operating systems, indeed.
Pfft. That site doesn't work with Firefox 3.6, only IE.
The System z hardware is no more EBCDIC than you are. z/Linux uses ASCII for messages, commands, and utilities, just as z/OS uses EBCDIC. The z/Linux choices include ports of RedHat and Suse. The port does not include translating these to EBCDIC.
Now, the old native Unix for z/OS, Unix System Services, *was* an EBCDIC Unix. Nothing ever said Unix had to be based on ASCII. Porting programs to USS was a challenge because too many programs made assumptions about the binary value of characters. Usually the fixes were simple, but sometimes the defects were hard to find. But if an assumption was made about the collating sequence, the problem was harder.
If by "program" you mean a stored program on what is conventionally meant by a computer today, I have a candidate. IEFBR14 was used on the earliest version of OS/360 in 1964 as a do-nothing program. It is still in use today, unchanged on the latest version of z/OS. Its function is to execute a JCL step which does nothing, but in the process of doing nothing, the job scheduler is invoked. This is one method of creating and deleting datasets (files). It is also the shortest valid OS/360 (and z/OS) program, containing two executable assembler statements and two assembler directives. The comments are mine.
IEFBR14 CSECT START PROGRAM SECTION
SR 15,15 SET EXIT CODE TO 0
BR 14 RETURN AND EXIT
END TELL ASSEMBLER END OF PROGRAM
Interestingly, the first version of this program had a bug, which was subsequently corrected by doubling the program length. It omitted the SR 15,15 statement, which meant that at program exit register 15 had an unpredictable value -- and the program exit code was therefore unpredictable. Since a zero exit code is used to guide the conditional execution of subsequent steps, a failure could be indicated when there was none.
And contrary to another post, I believe there are a lot of people with computer experience predating 1970 who read Slashdot. But I don't want to start a flame war over that.