Morgaine

Unfortunately your post comes across as sheer Google fanboism, first because it cites no authoritative information in support of its claims, and second because it uses emotively loaded terms like "awful", "storm in a teacup", "spouting", "garbage", "teacup tsunami", and so on. In other words, sir, you have written a rant. The only support you can possibly get for such an article is from other Google fanbois, and not from someone expecting to read well reasoned and factually supported arguments from both sides in a calm and balanced write-up.

pcstru: I think you're focusing more on what the individual statements of a JCL used to do though, namely job control, rather than on how they combine. What they do is not really related to language issues at all, except in the minimalist sense that JCL commands usually have a formal syntax too, albeit a rather simple one. (Shell can be considered a JCL too, sequencing a series of external jobs, the Unix utilities. But thinking about it that way doesn't get you very far.) We're not really talking about what the component statements do here, but the nature of the syntactic GLUE that spans a large bunch of individual statements and binds them together into what we call a program or script, a cohesive entity that does one composite task. If it does a composite task of job control that manages the running of other programs, that's cool, but it's still a program in its own right even then. And whether that glue is implemented as a high-level interpreter or compiled to machine code or even to microcode makes no difference to the user at all. As long as that process of internal compilation is transparent, the user considers what she does to be scripting. That's why I suggested that the technical distinction is disappearing, and all that remains is a subjective distinction based on how it appears to the user externally. This change is easily visible historically. At the time that Perl appeared and became popular, everything you wrote in Perl was a "script" -- almost nobody referred to their code as a program. Although Python started brewing not long after, it didn't become popular until a decade after Perl, and by then it was already considered normal to refer to Python code as "programs", not scripts, despite there being no significant difference between the two languages as far as script-vs-program is concerned. And nowadays they're both used to write "programs", despite "Perl script" still rolling off the tongue slightly better because of historical usage. Be that as it may, there's no doubt that they're both scripting languages and they're both used to write programs and they're both interpreted and they're both compiled and they both run immediately without any compilation phase being visible ... and the same is true for pretty much every popular language that once upon a time was only interpreted or only compiled. "Interpreted languages" now use compilation internally, and "compiled languages" now often have a direct execution implementation for scripting and/or interpreted bytecode. So really these terms have lost their usefulness today, because they no longer split languages by their implementation.

Yes indeed Tom, that's very well put! Poking those hardware addresses and memory cells and registers and stack pointers became the real job you were doing in your mind, and the syntax of the assembler was largely incidental. Whatever higher level programming languages you ended up using later became immediately recognizable as just slight variations on the same concept, their differences almost immaterial, because at heart they poked the same bits underneath. It's what I've been calling "programming with insight", as opposed to mastering a language. And it's also the difference between real education and vocational training. Morgaine.

The difference between "scripting languages" and those that aren't used to be defined in terms of their low level implementation, but as others have pointed out, that no longer has any meaning. Nowadays the definition is merely empirical: "When you type in source code, is it immediately executable from the typist's perspective?" If the answer is Yes then it's a "scripting language", otherwise it isn't. It's not really surprising that it has turned out this way, when you think about it. Programming languages themselves are just grammars, and how they're used is not a property of the language at all. It's a property of the how they're implemented, so the labels "scripting language" or "compiled language" were pretty silly to begin with. Morgaine.

I started with Unix at the end of the 70's (from Bell Labs tapes) and have been using *nix ever since, so Bourne shell is as familiar to me as breathing. But ... As a university lecturer in the UK for several years, I taught engineering students practical programming in their earlier years and software engineering in their final one, and one thing became clear: damage done in early years is difficult to undo later. "Damage" comes in various forms, but for the purpose of this thread it's the sloppy thinking and lack of deep understanding that is inherent when your "learning" is on a very high level system that is totally divorced from the underlying machinery. Shell scripting falls into this category. You're not really learning much at all with shell. It's more a form of vocational training (how to get something useful done quickly) than education (discovering principles, understanding what is good or bad, and why). This doesn't apply only to shell scripting, unfortunately. It applies to all high level programming systems, and therein lies a quandary. The best vehicle for learning is not the best vehicle for being productive. It's really quite a problem, because both are required. It's useless being a very productive high level programmer who is mystified why her code drops the server to its knees because she has no idea about memory allocation or process switching. For as long as our systems are resource-constrained (and that's not disappearing any time soon), education must focus on low-level details alongside practical high level tools. If it doesn't do that, all it's turning out are monkeys for the programming shop floor, able to follow directions from the design authority but lacking in deep understanding of what they're really doing. And the bridges of the software world will continue to collapse. Morgaine.

As we (im)patiently wait for our Raspberry Pi boards, an interesting way to bridge the lack of hardware is to run one or more of the Rpi ARM distros under QEMU emulation. It's not hard to set this up on a Linux desktop for the Raspberry Pi Fedora 14 Remix distro, as CNXSoft has provided a very well written HOWTO with full details. I had no trouble at all getting it working as per those instructions on my Gentoo 32-bit system. I encountered the same error that he found on his Ubuntu machine with qemu-system-arm, but rebuilding qemu-system-arm from the Linaro Git sources as he described fixed mine as well. Here's the output from a few commands I ran on the emulated machine. I had to ssh into it from another box to be able to cut'n'paste. QEMU's native console appears not to provide that facility, and unfortunately the console mouse package "gpm" doesn't appear to be in the Fedora 14 Remix image. [root@raspi boot]# uname -a Linux raspi 3.0.4 #2 Mon Oct 17 17:39:42 ICT 2011 armv6l armv6l armv6l GNU/Linux [root@raspi boot]# cat /proc/cpuinfo Processor : ARMv6-compatible processor rev 7 (v6l) BogoMIPS : 225.68 Features : swp half thumb fastmult edsp java CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xb76 CPU revision : 7 Hardware : ARM-Versatile PB Revision : 0000 Serial : 0000000000000000 [root@raspi boot]# ip route ls default via 10.0.2.2 dev eth0 proto static 10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 1 [root@raspi boot]# ps -elf | wc -l 50 [root@raspi boot]# dmesg | perl -ne '/^(Linux)|(CPU)|(Memory)|(Console):/ && print' Linux version 3.0.4 (jaufranc@CNX-NETBOOK) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-42) ) #2 Mon Oct 17 17:39:42 ICT 2011 CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387f CPU: VIPT aliasing data cache, unknown instruction cache Memory policy: ECC disabled, Data cache writeback Memory: 192MB = 192MB total Memory: 190620k/190620k available, 5988k reserved, 0K highmem Console: colour dummy device 80x30 CPU: Testing write buffer coherency: ok Console: switching to colour frame buffer device 80x60 [root@raspi boot]# As I booted the kernel that CNXSoft suggested, it's actually Linux raspi 3.0.4 rather than the 3.1.9 that is on the Raspberry Pi Fedora 14 Remix SD image, so it's possible that the above information varies a little from what we'll see when we finally boot up our boards. Happy emulating! Morgaine.