Is bash a programming language?

[Turbo-FB]

Is bash a prgramming language suitable for use in education, or does it just make kids lazy?

 

"...Bash is fantastically powerful but I would never introduce it to my students,

unless of course they already have programming experience and they have a need for it.

Even then I would choose C over bash scripting... "

 

Bash - Programming | Educational applications | Forum | Raspberry Pi

[localzuk]

Bash isn't a programming language. It is a scripting language.

 

Scripting is not a good place to start programming IMO, it teaches bad habits from the off.

[PiqueABoo]

The key point for all these threads: What does the curriculum look like? No point suggesting [whatever] languages that: a) don't support the programming concepts that are in it, b) languages that aren't one of the official list.

 

--

 

Ignoring that, script v. programming language is not always clear-cut e.g. I've written one or two jscripts (*.js) that are simultaneously JScript.Net programming language i.e. they will compile via jsc.exe into an *.exe.

[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.

[pcstru]

Bash isn't a programming language. It is a scripting language.

 

And the difference is ... ?

[jinnantonnixx]

And the difference is ... ?

 

I don't think there is one. You could wheel out some definitions, but it the differences would still be hazy to me.

 

Anyway, I can't see anything wrong with using Bash on the Pi. It's tied closely to the underlying OS, so you can do file level tasks natively, and it permits a reasonable amount of logic rudiments (if, case, for, while, and so on). Provided tools like awk and sed are to hand, you can do string handling.

 

Horses for courses and transferable skills.

 

The logical next level is Perl or Python, but Bash is a good enough place to start.

 

I cut my teeth on ZX Basic, but (GOTO aside) the logical principles were there.

 

In all cases, the zeitgeist will move on. Languages fall in and out of fashion, but the underlying principles, if taught correctly, will be transferable.

 

As an example, I did some stuff in the early '90s using C++ and Borland OWL framework. I wouldn't dream of using this now, but the principles are still sound, even though it's obsolete.

Edited March 19, 2012 by jinnantonnixx

[localzuk]

The line between them is somewhat blurred now, due to languages such as python existing.

 

It used to be basically a case of having to pre-compile your code to run it (eg. C, Java, Basic etc...), compared to those which simply operate within their own program environment (eg. Bash executes bash script).

 

However, with the advent of so many JIT compilers and languages, this distinction isn't so clear.

 

Bash is not a programming language, just like batch files on windows are not programs, or vba scripts in Excel aren't.

 

Using Bash, as Morgaine says, can and will lead to sloppy programming practices later on. The biggest problem at uni was those students who had previous coding/scripting experience who had picked up bad habits early on and had to have them untrained.

[jinnantonnixx]

Using Bash, as Morgaine says, can and will lead to sloppy programming practices later on. The biggest problem at uni was those students who had previous coding/scripting experience who had picked up bad habits early on and had to have them untrained.

 

I hear what you're saying, but there's no need for this. You could teach crap techniques in any language and be in the same boat. I'm convinced that you can teach Bash properly and impart the rudiments of programming. That's not to say that you'd use it to write a financial system, that would be silly, but it could be a useful part of a programming course on the Pi, as it's inextricably linked.

Edited March 19, 2012 by jinnantonnixx

[localzuk]

I hear what you're saying, but there's no need for this. You could teach crap techniques in any language and be in the same boat. I'm convinced that you can teach Bash properly and impart the rudiments of programming. That's not to say that you'd use it to write a financial system, that would be silly, but it could be a cornerstone of a programming course.

 

OK, Bash is not a strongly typed language for a start, so that's an instant issue with using it for teaching.

[mac_shinobi]

OK, Bash is not a strongly typed language for a start, so that's an instant issue with using it for teaching.

 

I remember doing VB 6 but that was at Uni. Think times have moved on to .NET stuff ie vb .net or C# .net

[pcstru]

The line between them is somewhat blurred now, due to languages such as python existing.

 

It used to be basically a case of having to pre-compile your code to run it (eg. C, Java, Basic etc...), compared to those which simply operate within their own program environment (eg. Bash executes bash script).

BASIC was seldom 'complied'. And even C, these days, can be tokenised rather than truly compiled to machine code. 'Bash executes bash' script seems a bit of a tautology to be useful - a C++ compiler compiles C++ code - not perhaps unexpectedly.

 

However, with the advent of so many JIT compilers and languages, this distinction isn't so clear.

 

Bash is not a programming language, just like batch files on windows are not programs, or vba scripts in Excel aren't.

I don't think there is a distinction in the languages as such. Scripting tends to refer to chaining OS functions together and scripting 'languages' seem to have developed from adding into shells/monitors commands which are only useful as string rather than direct manipulation of the machine state or file system. But as soon as you have some basic branching, methods of iteration and variables then you essentially have a fully fledged programming language. There is no difference. I'd probably use the term 'bash script' but I don't think there is any rational distinction I can make that distinguishes it from a programming language.

 

Using Bash, as Morgaine says, can and will lead to sloppy programming practices later on. The biggest problem at uni was those students who had previous coding/scripting experience who had picked up bad habits early on and had to have them untrained.

 

Any language is capable of being used badly and there are few languages that can't be used to teach good programming practice - even bash.

[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.

[tom_newton]

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.

 

Great post. One of the most influential bits of "learning" I ever did as a developer was to read a book on assembly - I actually never bothered with the later chapters, and never went on to write anything non-trivial in assembly, but the improvement in understanding that then rippled through my use of memory allocation in C, for example was immense.

 

I would say understanding how the machine works at a low level (and proving it by making the machine work, however trivially, at that level), and understanding data structures and their properties are fundamental building blocks.

 

To address part of the original question - yes, bash is a programming language, no it is not useful as a teaching aid because it lacks the necessary tools to produce decent data structures, and it has no advantages over, say, python. I would even say bash scripting is in may ways harder than many other languages to get started in.

[PiqueABoo]

"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.

I would say understanding how the machine works at a low level (and proving it by making the machine work, however trivially, at that level), and understanding data structures and their properties are fundamental building blocks.

 

Uh huh.. on one of the earlier 'What Programming...?' threads I mused: I think I'm missing DOS & serial ports. Reason: You could get a minute amount of x86 assembly to send data out of a serial port and if the other end of that is something shiny that does pixels then you've covered a lot of fundamental territory at a nearly direct level, which might be a good thing to do *before* diving into the relatively abstract-from-computer high-level stuff.

 

It's the spirit, not my specific and possibly flawed example that counts... and I wouldn't do that until after the basic theory (binary, text encoding, image representation, recipe=algorithm etc.) had been covered in whatever entertaining ways you can without hitting the computers.

 

PS: Just did some more musing while doing the washing-up the old-fashioned way and have decided you've just got to have some crypto in there early on.. Simon Singh-style stuff with history and some basic puzzle type stuff (as opposed to hard maths).

Edited March 19, 2012 by PiqueABoo
PS:

[pcstru]

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.

'low level implementation' is an interesting distinction to make when fundamentally, at the lowest level, the machine is flipping logic gates to a timing signal.

 

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.

 

I don't think that "when you type in" is ... entirely accurate. I think folks are on the wrong track with this.

 

Scripting has it's roots with what were termed 'Job Control Languages', perhaps more as a way of distinguishing between the programs and the means of running the programs and controlling things like the sequencing of the running of the programs and the readiness of computer resources (card readers, tape drives or the teletype terminal but most importantly the processor).

 

If I had to make a rational difference between a 'programming language' and a 'scripting language', the job control roots might lead me to say it's got nothing to do with language semantics, syntax or even features. It's economic. We will charge the punter for time on the mainframe to run their program, a script we will knock up in CMS EXEC (or worse) so we can maximise the throughput of programs on the computer but we don't care about the output of the script (as such). These days we will use a 'script' to automate a task (IT string tying stuff together) to maximise our use of resources but the 'script' isn't directly providing end user output and is not the point of the provisioning the systems, running the programs is. Programs provide end user output and income, scripts can never provide income, but they can help to maximise the income by providing efficiency. As a distinction between 'scripting' and 'programming' I think that holds today just as it did back in the days of CMS EXEC.

 

Maybe ... or something...

[PiqueABoo]

Programs provide end user output and income, scripts can never provide income

 

Possibly not the best time to say that e.g. JavaScript+HTML5 being that 'first class citizen" re. WinRT & Metro Apps.

[Morgaine]

One of the most influential bits of "learning" I ever did as a developer was to read a book on assembly - I actually never bothered with the later chapters, and never went on to write anything non-trivial in assembly, but the improvement in understanding that then rippled through my use of memory allocation in C, for example was immense.

 

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.

[CyberNerd]

If I had to make a rational difference between a 'programming language' and a 'scripting language', the job control roots might lead me to say it's got nothing to do with language semantics, syntax or even features. It's economic. We will charge the punter for time on the mainframe to run their program, a script we will knock up in CMS EXEC (or worse) so we can maximise the throughput of programs on the computer but we don't care about the output of the script (as such). These days we will use a 'script' to automate a task (IT string tying stuff together) to maximise our use of resources but the 'script' isn't directly providing end user output and is not the point of the provisioning the systems, running the programs is. Programs provide end user output and income, scripts can never provide income, but they can help to maximise the income by providing efficiency. As a distinction between 'scripting' and 'programming' I think that holds today just as it did back in the days of CMS EXEC.

 

Maybe ... or something...

 

I'm not following this at all. You can't seriously be suggesting that you can't monetise a program written in a scripted language like php,python,ruby?

[Soulfish]

Great post. One of the most influential bits of "learning" I ever did as a developer was to read a book on assembly - I actually never bothered with the later chapters, and never went on to write anything non-trivial in assembly, but the improvement in understanding that then rippled through my use of memory allocation in C, for example was immense.

 

I would say understanding how the machine works at a low level (and proving it by making the machine work, however trivially, at that level), and understanding data structures and their properties are fundamental building blocks.

 

One of the reasons I loved the CS course at York Uni was that a large part of the first year theory, and second year practical/theory and then third year practical/theory was based around assembly and compiler design/construction. Building AI-network controlled battleships games in assembly (and building the hardware the assembly is being run on from scratch!) is...fun...in a crazy sort of way

 

But I'd fully agree what everyone is saying. Bash and other scripting languages just aren't comparable to "proper" programming languages.

[Morgaine]

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.

Edited March 20, 2012 by Morgaine

[tom_newton]

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.

[pcstru]

I'm not following this at all. You can't seriously be suggesting that you can't monetise a program written in a scripted language like php,python,ruby?

 

I'm in a camp that says there is no real distinction between a "scripting language" and a "programming language" in terms of the potential they offer programmers to control a state system (a computer). I could use bash to produce a C compiler or of course, I could use C to produce a bash shell. So when Localzuk stated "Bash isn't a programming language. It is a scripting language." I was interested in what someone who makes that claim might bring to the table as a rational and distinctive difference between the two. The 'concensus' then seemed to shift to say - "ah well, there is no real difference these days, any differences have largely disappeared". But the claimed differences that existed in the past (interpreted/compiled etc) still seem to me to be ... wrong (in that examples always seem to spring to mind that break those 'rules').

 

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.

[pcstru]

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.

 

I don't think that is true. JCL's certainly started out simple - they were just the 'command interpreter' accepting input and when your machine has 256 bytes to play with, that will naturally be limited. But they quickly added control "if the last job failed then don't run this job run that one" or "run this job again and again until " as a means of maximising the throughput - maximising the time the processor spent earning money from running jobs.

 

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.

[pcstru]

Possibly not the best time to say that e.g. JavaScript+HTML5 being that 'first class citizen" re. WinRT & Metro Apps.

 

Well, Javascript is definitely a programming language - the fact that it has script in it's name is perhaps misleading but then Python is not a snake and the wife would not be impressed if I gave her perl for a wedding anniversary.

[PiqueABoo]

Well, Javascript is definitely a programming language

 

Probably, but the standard (EMCAScript) javascript and jscript mostly implement definitely calls itself a Scripting Language.