Programs provide end user output and income, scripts can never provide income
Programs provide end user output and income, scripts can never provide income
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.
But I'd fully agree what everyone is saying. Bash and other scripting languages just aren't comparable to "proper" programming languages.
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. :D
For me, the 2 features of a scripting language: interpreted, and garbage collected. Neither of these is sufficient to be classed as "scripting" but both necessary IMO.
It is becoming a very blurred distinction though.
So, I'm suggesting that the difference between a script and a program has nothing to do with the language at all. You can't say language x is a scripting language as opposed to a programming language, there is no difference and never really has been as such (is machine code a programming language or a scripting language?). But you can perhaps say that a series of statements written in language x is either a script or a program and that the difference is predicated on the intended purpose rather than the chosen language. Extending that to income is perhaps going too far but ... hey, I is really just finking aloud. Take no notice and I'll drift away.
I'm just trying to determine where 'scripting' came from as opposed to 'programming' and I think the root of the difference lies with 'job control' as opposed to 'job'. That's a simple concept and IMO, better encapsulates what we mean by 'scripting' as opposed to 'programming'. The required skills are largely the same.
I would actually recommend teachers to do scripting languages as a primary. They are WAY more powerful than your average programming-language. Not only in terms of time to implement a rudimentary solution but in terms of stability. Bash is one of the best scripting-languages in the sense that it forces you to come to terms with what software is out there already, instead of trying to reinvent the wheel all the time. The filesystem is there - you won't reimplement a filesystem unless you really have to - so why would you reimplement reading or writing to a file? Makes absolutely no sense at all. You are killing the benefits of the fancy kernel if you do - and then guess what - you would be better of with a scripting language.
There are so many hours wasted on trying to teach everybody the virtues of LISP and object-oriented perfection that we are loosing track of what matters: employers want to see results - end-users are crazy and time is very expensive. If you cannot do something in a scripting language you are basically trying to do something so novel that you need to get your head looked at or you are approaching it the wrong way or maybe your end-users are asking the wrong questions.
I think that one of the major problems with accepting scripting languages as the most powerful languages is that we have grown accustomed to the thought that everybody is so special. Of course there will be people that excel in writing an algorithm for signal detection or people that love finding new ways to sort but those people are the exception. We are loosing a lot of people on the way - just trying to teach everybody to do everything but nothing at the same time. Using a scripting language like Perl you would write AI-laden SOAP-speaking twitter-bots in a couple of hours. Doing so in C would take hundreds of people or multiple years of nothing else.
What I hated most with doing computer science at the university was that every single problem they would throw at me could be solved in less than ten seconds using perl one-liners. What a joke. We were thought to think slowly and solve problems in inadequate and ridiculous ways in the event of those rare cases where nobody had even ventured into that domain before. That's like creating esperanto and trying to teach your kid that before moving on to real languages afterwards. It's bad pedagogy.. That's probably why only a few people from every class actually end up doing programming - it's a waste of time.
There will always be people who thrive in object-oriented perfection. Or people who dream in LISP. Great! But unless you are aware of what a scripting language can do for you: you will forever just be a moron .. Just think about the frameworks - frameworks in modern programming languages are basically scriptifying code. Why bother doing cell-tower triangulation in C when you can do a single line of objective-c CLLocationManager in some framework?
Btw: Python is a scripting language. Java is a scripting language. We just perceive them as programming languages because of the syntax. But they have the flaws of scripting-languages and none of the benefits of lighter scripting languages. I bet you I could do most anything faster (in terms of execution time and implementation) with #!/bin/sh than you could with python or java. If you want to be real crazy you could always try coding a scripting language in an objective manner to slow you down and teach kids something about the stuff the drones do at the major companies.. But unless you do algorithms or something that needs to be fast: Scripting languages are basically the next best thing to pure C (or objective-C, C++, etc) out there.. Python is a waste of time. Java is a waste of time. Knowing what an integer is - ok - fine. Knowing what object-oriented code is - fine. But give me a bloke that knows regular expressions, scripting in bash/perl/... there is no limit to what that person could accomplish.. And I bet you the kids will be thrilled by doing twitter-bots the first day of the course instead of just printing shitty strings to stdout in a complicated manner. Printing to stdout is done by echo. Maths is done by bc. Protocols are done with curl/wget/netcat. Listing files: ls. Outputting files: cat. Removing them: rm. How hard to you want to make it? Well that depends on the students more then the teacher doesn't it? Doesn't it?
There are two other problems with your philosophy of solution is packaging them up and throwing them at end users. The first is complexity - having your system dependent on multiple programs and systems involves more potential points of failure. You will need to be sure for instance that you control the underlying configuration otherwise an update to any of the subsystems you rely on could kill your workflow. The second is usability. If I tell one of our secretaries to open up a bash shell, cd to scripts and run ./mycelverscript ; I might be lucky to get out alive (or I will be calling an ambulance as their stress levels and anxiety overcome them). Of course, you could package your scripts up as CGI behind a web page or some such, at which point ... see complexity.
That said, I'd agree that scripting is important, especially in systems management. At a basic level it allows you to eliminate the tedium of often repeated tasks. At an advanced level it can be the string that allows you to tie systems together into a cohesive whole that is more than the sum of the parts.
No-one is denying the importance of scripting. None of us could do our jobs effectively in IT support without them IMO. But as pcstru says, university isn't about producing usable solutions, its about teaching the concepts of programming. Skills that you can transfer between languages, and aren't restricted to knowing Perl one liners (which even amongst system admins are often mind numbingly complex).
Sure, knowing Perl is a very useful skill for a linux admin, just like knowing VBS or Powershell (now) is in Windows, but it doesn't teach you about polymorphism, or inheritance, or any other programming techniques which someone who is training to be a programmer needs to know.
Not to mention, you do realise that Windows is the most commonly used OS in the world, and is the one they see in their homes and businesses. Linux for all its brilliance is not the software they will come across, and therefore learning bash is somewhat pointless and niche for kids starting out in the world of computing.
You have to draw a line about what is likely and what is niche. Bash, even though common in server, is niche.
Also, you can't say that about servers - there's no real usable metric to draw that conclusion, as most stats about it talk about web servers. If you look at hardware sales, then Windows beats Linux, but neither are really accurate.