Raspberry Pi, Arduino & Other SBCs Thread, Is bash a programming language? in Technical; Programs provide end user output and income, scripts can never provide income
Possibly not the best time to say that ...
19th March 2012, 09:42 PM #16
Programs provide end user output and income, scripts can never provide income
19th March 2012, 10:17 PM #17
Yes indeed Tom, that's very well put!
Originally Posted by tom_newton
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.
Thanks to Morgaine from:
tom_newton (20th March 2012)
19th March 2012, 10:25 PM #18
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?
Originally Posted by pcstru
19th March 2012, 10:50 PM #19
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
Originally Posted by tom_newton
But I'd fully agree what everyone is saying. Bash and other scripting languages just aren't comparable to "proper" programming languages.
19th March 2012, 11:00 PM #20
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.
Last edited by Morgaine; 20th March 2012 at 12:44 AM.
20th March 2012, 07:41 AM #21
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.
20th March 2012, 07:51 AM #22
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').
Originally Posted by CyberNerd
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.
Thanks to pcstru from:
CyberNerd (20th March 2012)
20th March 2012, 08:03 AM #23
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 <condition>" as a means of maximising the throughput - maximising the time the processor spent earning money from running jobs.
Originally Posted by Morgaine
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.
20th March 2012, 08:06 AM #24
Originally Posted by PiqueABoo
20th March 2012, 11:04 PM #25
Originally Posted by pcstru
10th December 2012, 11:36 PM #26
- Rep Power
Don't bash bash please
Well.. I work in a profession that is slowly being overtaken by software running on machines. If I got 10 cents for every time some salesperson pitched me a solution that "required" custom software written in some new object-oriented language I would be rich. If I got an additional 10 cents for all those problems that could be solved using "scripting language" running on a linux machine I would be doubly rich. The fact is that unless your doing something really really really groundbreaking - what you are trying to accomplish is probably just a new workflow on existing algorithms/tools: then you need a scripting language. But if you don't know scripting-languages and don't understand them you will see every problem as a ground-up problem.
Originally Posted by Turbo-FB
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?
4 Thanks to skeldoy:
CyberNerd (11th December 2012), jinnantonnixx (11th December 2012), mac_shinobi (11th December 2012), pcstru (11th December 2012)
11th December 2012, 08:26 AM #27
Nice post but I think you may have missed the point of university. It wasn't to produce solutions to problems that could be used, it was to teach you programming. You won't learn much about sorting algorithms by simply calling a sort program.
Originally Posted by skeldoy
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.
11th December 2012, 08:39 AM #28
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.
Last edited by localzuk; 11th December 2012 at 08:41 AM.
11th December 2012, 09:00 AM #29
Not in the servers, supercomputers or telephone world.
Originally Posted by localzuk
And BASH does work on windows too. .....
11th December 2012, 09:05 AM #30
And kids in our schools will be coming across bash installed on Windows regularly won't they? Or supercomputers, servers or telephony systems? No. Why not just go the whole hog and teach assembly in year 2. Its used in embedded systems all over the place, and its very quick at processing things...
Originally Posted by CyberNerd
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.
By EduTech in forum Jokes/Interweb Things
Last Post: 30th March 2009, 11:26 PM
By atfnet in forum Educational Software
Last Post: 19th June 2007, 12:33 PM
By mighty.grey.eagle in forum Coding
Last Post: 21st January 2007, 02:01 PM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Tags for this Thread