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.

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

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

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

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

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