Solved Should I write all of my scripts in JavaScript?

  • Thread starter Deleted member 63539
  • Start date
It really depends. My perception is that there are 2 kinds of students, those having chosen IT randomly because they HAD to go to university but had no idea of what they wanted to do in life, and those having caught the IT virus and feeling happy to be able to study what they like, at last. The latter make very good IT professionals, sometimes even better than others doing that job for a long time just to bring the bacon home.

Concerning the former, note it is not always because they don't care, but very often because they feel so much pressure on their shoulders that they are afraid to make any decision.

I find most young people who want to learn programming and computer usage are always looking for an easier way to get around having to do that. Those are the people who want to not learn C, math, science and are always on reddit or Stack Overflow looking for a framework or library that will do the work for them rather than understanding how things work.
 
It really depends. My perception is that there are 2 kinds of students, those having chosen IT randomly because they HAD to go to university but had no idea of what they wanted to do in life...
I was a Biology student in the '80s. The majority of the students in my classes were there not because they had any interest in the subject, but because their parents wanted them to be doctors and/or they wanted to make a lot of money. IT is the pre-med of the 21st century, unfortunately.
 
It really depends. My perception is that there are 2 kinds of students, those having chosen IT randomly because they HAD to go to university but had no idea of what they wanted to do in life,
In my experience, those are choosing something else than IT, for example philosophy or arts.
 
In my experience, those are choosing something else than IT, for example philosophy or arts.
Off-topic, but: the philosophers of this kind get a bloody nose when they have to pass a test in logic (hardcore, nearly the same stuff like logic for mathematicians) and on the artists,... well, I've witnessed some profs exploit their power to sell diploma for "other services"... sadly so.
 
  • Thanks
Reactions: a6h
I found a scripting language I like. I think I will use it alongside with sh. Unfortunately, it requires the Java JVM to work :(
 
Op, when I need to automate something I usually search around to see if someone already did it, else I roll up my sleeves and do it myself. However I tend not to use someone else's 20-line script if I have to install 20 new packages; kind of defeats the purpose of 20-line script if it comes with tens of megabytes of dependencies attached. Just my two cents.
 
Op, when I need to automate something I usually search around to see if someone already did it, else I roll up my sleeves and do it myself. However I tend not to use someone else's 20-line script if I have to install 20 new packages; kind of defeats the purpose of 20-line script if it comes with tens of megabytes of dependencies attached. Just my two cents.
Exactly my thoughts.

Admittedly, the bourne shell syntax can be cumbersome at times. But it has one big advantage: It’s basically available everywhere, without having to install anything special. So, for small and simple tasks, the bourne shell is my favourite.

For anything more complex, Python is my language of choice. It’s not part of FreeBSD’s base system, but chances are that it’s going to end up on your machine anyway, because there are so many common packages that depend on it. So, again, you don’t have to install anything extra in most cases (the same holds true for the other BSD projects and most Linux distributions). Python is easy to learn, but powerful, and it can be used for scripting tasks as well as for serious programming.

If speed is a concern, I go with C. Actually Python isn’t really slow (after all, Python sources are compiled into a VM byte code that is quite efficient), but there are times where nothing comes close to C, speed-wise (*). This is another area where Python shines: It is very easy to interface Python with C.

I have once written a video application for analyzing and cutting MPEG4 files. For the basic framework, the user interface and most other parts I chose Python. The core functions that handle the actual video frames I wrote in C and embedded it into the Python application. This works exceptionally well.

So: My favorite “triumvirate” of computer languages is bourne shell + Python + C, and I chose whatever is most suitable for a particular task, which might also mean mixing any two of them, or even all three of them. Having said that, I also wander to other languages for special purposes, like JavaScript for client-side web stuff. For example, this little game uses Python on the server side and JavaScript on the client side (actually, the JavaScript code is generated by the Python code).

(*) Well, maybe assembler language, but then you lose portability.
 
Widen your horizon & learn at least one programming language of each of the major programming paradigms: Pascal, C, Java, Haskell, Erlang, Python, Prolog, Lisp, ML, ... Then choose the language that fits best to solve the problem. Usually, shell scripts that grow beyond ~1k LoC are not maintainable. Both Python & LUA are better choices (have modules); for some problems awk(1) or a macro processor like m4(1) is perfect.
 
  • Like
Reactions: a6h
Widen your horizon & learn at least one programming language of each of the major programming paradigms: Pascal, C, Java, Haskell, Erlang, Python, Prolog, Lisp, ML, ... Then choose the language that fits best to solve the problem.
At university I learned one programming language per month, just for fun. It turned out that the majority of them were never really useful for anything that I came across. Admittedly, some of those languages were quite obscure.

In the end, it led me to Python as my favorite language, with C, shell, JavaScript and some others for special purposes. One of the things I like about Python is that it supports several programming paradigms (partially or in full), but it doesn’t enforce any of them. You can write scripts in plain old imperative style if you want, but you can also do object-oriented programming (with operator-overloading, multiple inheritance, meta classes and so on), and it even supports certain features of functional programming languages. And all of that in a comparatively simple and concise syntax, it’s almost executable pseudo code (whereas Perl is executable line noise, as some people say). ;)
Usually, shell scripts that grow beyond ~1k LoC are not maintainable.
Rather ~ 0.1 kLOC, in my opinion. But it depends on how well they’re written. You can write a script of 10 lines that is practically unreadable. On the other hand, it’s quite possible to write a script of 1000 lines that is well structured, has helpful comments and meaningful variable names. The problem is that most people don’t seem to write shell scripts that way, unfortunately.
Both Python & LUA are better choices (have modules); for some problems awk(1) or a macro processor like m4(1) is perfect.
Ugh, no, m4 is a nightmare, except for trivial use cases. As soon as you start with include files and several levels of nested quotes, it quickly becomes unmaintainable. In my opinion it was a big mistake that sendmail selected m4 as the macro processor for its mc framework. Caused me swearing more than once because things got expanded (or not expanded) at places I didn’t expect because you can’t really see it in the actual code, unless you know the contents of all included files by heart.

That reminds me of this little gem that I found in a signature once:
“Swearing is the only language that every programmer speaks perfectly.”
 
Not really, it's widely used in commercial products by big companies (e.g. Synopsys)

Since a time I play with the idea of buying an fpga, for fun.

When I learned some principles of VLSI with APL (instead of VHDL,Verilog), I could not
dream to apply that knowledge.

But it will perhaps remain a dream, there is a lot of other nice things to do.

No idea what role plays tcl here.
 
At university I learned one programming language per month, just for fun.
There is a group of people who maintain a web page that shows useful program in a zillion programming languages, mostly bizarre. All the programs sort of solve the same problem (and I don't even remember what the problem was). A colleague of mine has helped out on the web site, for languages such as Intercal. That's a language in which it is virtually impossible to write any useful program.

Rather ~ 0.1 kLOC, in my opinion. But it depends on how well they’re written.
I used to work with a system that had about 1/4 million lines of it implemented in shell scripts. The largest single script I remember was 18K lines. While they weren't exactly easy to debug and improve, they were well written enough that it was possible.

That system ended up having so many compatibility problems with shell implementations on different OSes that it ended up shipping the source code to a public domain sh implementation with it, and compiling that standardized shell for its own use. It's sort of disturbing to learn that if you explore all the nooks and crannies of something as old, tested, and standardized as sh, it still has bugs and incompatibilities.
 
I used to work with a system that had about 1/4 million lines of it implemented in shell scripts.

Last week, I wanted to convert a set of markdown documents into an EPUB ebook. I started coding it with sh (at first, it appeared as a scripting problem to me) and after 2 days, I felt I would never be able to complete the task. I rewrote the whole thing in Java and it was done in 1 day.

This is to say that each language has its own qualities that may not suit all purposes. I doubt shell scripts were intended to write 1/4 million lines applications, and the use cases for which they were designed would probably not have had compatibility issues.
 
It's sort of disturbing to learn that if you explore all the nooks and crannies of something as old, tested, and standardized as sh, it still has bugs and incompatibilities.
I guess the reason for that is that the bourne shell predates the POSIX standard, and there were just too many different implementations. Even today, new variations are created, like the new ksh2020.

For example, the /bin/sh of Solaris is (was) extremely restrictive and far from the POSIX standard. It didn’t know the $(...) syntax, no arithmetic expansion, no test command built-in, and so on. To get a POSIX shell on Solaris, you had to use /usr/xpg4/bin/sh. And then there is ksh, of course. Bash is mostly POSIX-compliant, but you have to enable it with the --posix option. Similar for zsh.

FreeBSD’s /bin/sh isn’t POSIX-compliant either (but comes a lot closer than Solaris’ /bin/sh). It was derived from the Almquist shell (“ash”), which was yet another bourne shell re-implementation. The Linux folks also picked up ash and made yet another fork, calling it “dash”.

And then there is the Korn shell ksh with dozens (maybe hundreds) of implementations, derivatives and variations. There is a UNIX shell family tree on this page, but it is extremely simplified (and not entirely correct, I think).

So, indeed, if you intend to ship shell scripts that are meant to be portable across a broad variety of systems, you must either be very careful to only stick to the common divisor of the standard shells of those system, or require the users to install a certain shell (bash, zsh), or ship a shell along with your scripts. Of course, the best solution would be to port the scripts to a language that doesn’t have as much portability problems as the bourne shell, like Python.
 
or ship a shell along with your scripts.

Makes me shudder to remember building dtksh (shipped with CDE). Granted it had Motif bindings but getting that thing to build just after we had finally convinced them to release the source was painful. It had suffered a lot of bit rot!

Therefore, upon reflection, I recommend not shipping a shell with your software ;)
 
I used to work with a system that had about 1/4 million lines of it implemented in shell scripts. The largest single script I remember was 18K lines. While they weren't exactly easy to debug and improve, they were well written enough that it was possible.
My worst experience was a shell installer that was ~3k lines. No one would go in there so it had embarrassing client-visible bugs like indentation fails. I corrected these, mostly to see if I could. It took hundreds of tries, and almost a week.

That system ended up having so many compatibility problems with shell implementations on different OSes that it ended up shipping the source code to a public domain sh implementation with it, and compiling that standardized shell for its own use. It's sort of disturbing to learn that if you explore all the nooks and crannies of something as old, tested, and standardized as sh, it still has bugs and incompatibilities.
Isn't this what Go does by default? Everything is statically linked and shipped as a giant blob. I'm seeing more and more people ship an embedded Java VM too.

...the best solution would be to port the scripts to a language that doesn’t have as much portability problems as the bourne shell, like Python.
I've lost faith in Python. They're breaking backwards compatibility with dot releases now. They learned the wrong lesson from the 2->3 upgrade fiasco.
 
I've lost faith in Python. They're breaking backwards compatibility with dot releases now. They learned the wrong lesson from the 2->3 upgrade fiasco.
I disagree here.

It was a good thing to get rid of old things and make the language cleaner and more streamlined again. There was some historical cruft that was preventing progress. Just one example: The handling of string encodings in Python 2 was a nightmare and a never-ending source of problems. This could not be fixed while keeping backwards-compatibility.

And I don’t think there is (or was) a “fiasco”. Admittedly some people have problems with switching from Python 2 to Python 3 (I don’t, and most of the people I know don’t), but it really isn’t a big deal. You can even stay with Python 2 if you absolutely want to, but you won’t get further updates, of course, and you won’t benefit from the fixes and new features introduced in Python 3.

By the way, Perl did the same. It was also called a “fiasco” by some people back then, but today everybody is happy with it. Things like that are not uncommon.
 
By the way, Perl did the same. It was also called a “fiasco” by some people back then, but today everybody is happy with it. Things like that are not uncommon.

Perl is an interesting one to follow in that it is the first time I can recall that the community has outright rejected breaking changes and the new development was forked (into Raku).

This could mean that Perl will remain very robust and stable indefinitely because all those who don't particularly care about problems caused by breakage and just want "New New New gimmicks!" are ushered onto Raku.

As for Python, the *only* two projects I used (Trac and MoinMoin, both fairly large and popular!) didn't (and still don't) support Python 3, so I just thought the whole ecosystem were a bunch of clowns basically.
 
It was a good thing to get rid of old things and make the language cleaner and more streamlined again. There was some historical cruft that was preventing progress. Just one example: The handling of string encodings in Python 2 was a nightmare and a never-ending source of problems. This could not be fixed while keeping backwards-compatibility.
I agree that this had to be done and the pain had to be endured. What I disagree with is that now they've decided to fix problems that are much less important in dot releases, even though these fixes (which are sometimes merely cosmetic) break backwards compatibility. I guess the rationale here is to not let things fester. The alternative of subjecting your community to a death of a thousand cuts is not a reasonable reaction.

And I don’t think there is (or was) a “fiasco”. Admittedly some people have problems with switching from Python 2 to Python 3 (I don’t, and most of the people I know don’t), but it really isn’t a big deal. You can even stay with Python 2 if you absolutely want to, but you won’t get further updates, of course, and you won’t benefit from the fixes and new features introduced in Python 3.
We'll have to agree to disagree here. There are still major software projects that either didn't upgrade, or wrote a completely new version that is not as popular as the old version.

By the way, Perl did the same. It was also called a “fiasco” by some people back then, but today everybody is happy with it. Things like that are not uncommon.
Nope.
 
Perl is an interesting one to follow in that it is the first time I can recall that the community has outright rejected breaking changes and the new development was forked (into Raku).
I’m sorry, I should have been clearer. I wasn’t talking about Perl6 / Raku, but about the switch from Perl4 to Perl5.
As for Python, the *only* two projects I used (Trac and MoinMoin, both fairly large and popular!) didn't (and still don't) support Python 3, so I just thought the whole ecosystem were a bunch of clowns basically.
Well, the latest release of MoinMoin (1.9) is 2 years old. The development version that is going to be released as MoinMoin 2.0 indeed supports Python3, as does the upcoming version 1.5.2 of Trac.
 
Back
Top