Better to do in in plain C, which is actually even easier compared to bash. It is even portable on Microsoft Windows.

I also worked in C, with embedded sql. C is not really portable, python/perl/java are (for example) much better to write platform independent code. (although you can do that with c too).

I agree. "C" and really "C++" are both low-level languages ... ideal for writing language-interpreters in. The usual interpreters (Java, JavaScript, Python, Perl, PHP, Ruby, etc...) all have strong-and-standard implementations on many platforms, and you can with them invoke "many pages of battle-tested C/C++ code" by writing a single line of source. Usually, the performance of these methods is plenty good enough, now that today's computers are(!) finally fast enough to get out of their own way.

(Well do I remember the days years decades ... koff koff ... when they were not!)

I worked on a hospital IT department for several years. By year 4 I was the Program Administrator, software designer, Coder, database administrator, and software QA team. Just me. My nickname was "Bill, the computer guy". When you are the "lone ranger" it is seductive to cut corners, but that is when it is most important to NOT cut corners! My version control was manual (a process I "invented" before 1990) and my release was staged. It did not matter what could go wrong or at what stage of the process, there was no way to spread blame so every step HAD to be perfect. (And there was just a chance that someone's life would depend on my getting it right the first time. Hospital!)

As an aside, there is an effect that is humbling when you work with hundreds of people that you KNOW are brilliant, highly trained, far more intelligent than you are, but who have NO idea what is going on under the hood when it comes to the technology. You, you are the expert, but you will never be the expert that nurse is. Even the med tech saves more lives and has more training. You learn to be careful when you speak to people, and value what they bring to the table.

From there I went to working on a team, where I could actually share the load (AND the blame) and count on other eyes to help catch anything I might miss. OH MAN I learned to love teamwork! Having someone else to QA your design, advise on things you might not know about the effects or value of a project, QA your final product, or stage testing or deployment FOR you is priceless!

Alas, we do not always have that luxury.

I respectfully disagree. If the complexity comes above a certain level, I would prefer moving to PERL or C. Bash is prefect if the point is calling external things (database tools come to mind) and has a huge advantage if you have a SYSADM team with a few BASH coders but few other programmers. The long term maintenance is more important than your personal comfort level with the tools under the solution.

A few years ago my preference was BASH (Very quick to complete, very portable, several other could maintain it, and I could hand a solution off to clients and they might even know what to do with it if something went wrong later), PERL (requires few or no external calls, PERL library hell is achievable but also avoidable, very portable, very fast, nicely maintainable, somewhat less readable), C/C++ (Compiled, mixed results on portability but very good, compiled static has fewer dependencies than even PERL, execution time gold, less maintainable unless you have a team of coders, a clear preference if you are coding a solution that will not need enhancement, maintenance, or modification for a LONG time).

These days I might add MONO, Python, FreePascal (Because I have found it oddly useful for things that nothing else does, it has built-on protections missing from C/C++, compiles to somewhat static executable, and I like the style), RUST, FORTH (For embedded), FORTRAN (for matrix work), or COBOL (Object Oriented Cobol: and because nothing does government forms better).

It really depends on the project, the data, the maintenance and support profile, and the time restrictions. Ultimately, you have to let the problem dictate the solution, and the solution recommend the tools.

Python and Java are great. They are very fast, usually employed in Windows, and many persons still use these programming languages.
I wonder why Java is not much more employed under Linux.

I like Java especially for scientific applications.

Hi,

I have times where a scripting would be done to prove a project then if necessary use of high level language would be used to speed things up when necessary and provide portability. Often times the script would meet the needs for the smaller projects. And scripts would provide portability when adapted properly.

With the availability of Gnu then projects would not be a price burden. Testing is a important function within any project thus proofing will always be needed. Hand checks can find errors but to really proof then production checks must be done.

I started using machine code early in my life and moved easily too assembler then to C. Heck I even used Basic for a client that required such. I tried to move to a better language but that client thought she understood Basic and felt that support would be easier for her therefore my program development (old article but good) was limited because of this choice. Not really a good thing but when the person that puts the dollars out then you do that to satisfy in order to get your payments. I got a large payout from that company because the owner had no real idea about program generation(s) or facilities to prove the code. Code changes were dictated by the client thus not following good practices for the code. As I said, I got a good payout for this troublesome person who only had a toe in the development/stages/master code. Versions were controlled by that customer.

Keep your toolbox close to your heart and protect yourself. Grant usage of sets but control distribution to protect your intellectual rights for that portion of code. Some small snippets can provide future income so do not sign away any rights unless you feel it is necessary or lead to potential negotiations. Protect yourself and meet the requirements of your contract(s).

BTW, I really do not care to use attorneys but at times they are a must have.

Hope this helps.
Have fun & enjoy!

Hi,
I do agree too some of what you are saying. I think jobs should be addressed by the best fit point. I remember my early IBM days and having to use COBOL and the heartache/headaches to wrap the task with the code. Yes, forms were easier but the formats could be challenging. My big issue was we still used Unit Records and my punch skills were not the best when I had to make small changes. To submit for a small change was frowned upon so we would make the card changes for the deck then submit a job. I no longer have the heartache/headache that comes from UNIT Records & punch cards. Thankfully those days are gone forever!

RPG could be a pain period. One reason to use assembler was I knew that the changes made would be correct but project managers were old school and prefer COBOL when appropriate.

Our University Unit records was performed by student aids and to get a job done most times required a project number or else you were pushed to a low level entry and those times could be into days verse hours with a grant project number which would put you to the top.

My migration to UNIX was easy since we were gifted by AT&T UNIX license and equipment within our LAB. So to have workstations and server locally made my day a lot easier than submitting to the University computer. Debugging went a lot faster having the tools locally. I have not coded in COBOL,RPG and very little FORTRAN over the last few years. I still need to reference when using 'C'. My assembler skills are still used at times. You do adjust your skills as needed by any task(s); Hope this helps.
Have fun & enjoy!

Actually, I didn't consider the "mixing code" problem to apply to awk statements in a bash script. Most people expect that kind of thing because SH isn't a programming language, its scripting. Let's put it this way, if you form the awk statement incorrectly, awk will complain when you try to run the script. It's easy to see where the problem is.

I think I may have a slant on that.
Oracle owns the orignal SUN java. That did not matter until recently, when they began to charge for the development (SDK) use when used for development of paid products. Suddenly some things that were ALWAYS free under SUN, and had been free under ORACLE, are no longer free.

If you are trained ONLY in the JAVA that Oracle owns, it suddenly became less of an advantage to use it. The OSS version of JAVA is not as advanced, lacks a few features, and fewer people have moved to development there. ORACLE forces everyone to pull their Java from their site, only the OSS version is allowed in REPOS. At a corporate level, the ORACLE version is the one that is supported under restrictive corporate standards.

All of this is a mess, and SHOULD shake out to everyone using the OSS java eventually. Life does not wait on "eventually".

Many people who one pushed java and java solutions are tired of the ORACLE me$$ and are pushed to other languages. Python, RUST, and GO come to mind. Some commercial packages have moved to smalltalk and C++. One I know has now moved to .NET with all of the tools to develop for Windows and Linux in the same source.

Java has always had some memory issues and is a "hungry" language. In part this is execution, not design, but some of the problem is in the language design. Some developers that got tired of fighting to get proper behavior from java have moved off to other things that either handle memory better or enforce better memory management on the programmer and compiler to achieve applications with a leaner, faster profile at runtime.

I used to like java, despite the flaws (about version 1.1 and 1.2) but left it behind a long time ago. It just may be that more coders (and shops) are leaving it behind for some of the same reasons I did, plust these new reasons.

Java is garbage... If you want that sort of light top level language, just Node.js or something else. Java drives us sysadmins nuts because your preferred language requires nine thousand versions of it's runtime to exist side-by-side and not step on each other. From the perspective of systems management, java is nothing but endless headaches created by people who do not understand anything about the OS or hardware.

If that's not true, how else do you explain the 10,000 repeat questions on stack overflow asking the same remarkably stupid question: Why can't the kernels be written in java so I can contribute?

When people try to explain things like standard libraries, runtime locks, garbage collectors, exception overhead and cache misses, these same people glaze over and "don't get it."

Sure, you could write a kernel in Java. You could also make a car out of lead. But, the more important question is: Why the hell would someone do that?

My biggest problem with Java is the immense size of its virtual machine ... and that it tends to run quite slowly. It was "designed by a committee," and it shows. Like Ada, it set out to be everything for everybody and in so doing became nothing for nobody. There are many other more-modern compiled languages which fill this niche much more effectively.

Its much-touted ability to "run on anything" is also fairly superfluous because, in real life, it only gets run on one thing. JVM has no exclusive claim upon any underlying OS facility that is not better-exposed by other tools. An honest-to-god compiler, generating native code for whatever-is the target, would invariably run much better than Java.

Like I said, abomination... It and vala. Both need to go, neither make it onto my LFS machines.

Speaking of which, IBUS now requires vala. Hopefully, someone will fork it away from that nightmare... and soon. Either way, I won't be installing it while that's a requirement. The mere existence of Vala on my machine makes so many package builds break when they try to build vala extensions.

Java runs well and fine under Windows. It takes lot of memory,... high level (garbage) maybe. Java could also run much differently under Linux. Java is still present everywhere. Libreoffice uses even Java, which means that you can use Java in your daily working time under Linux as well.

If you don't like Java, heavy things, there are many other things under Linux which are largely bloated. That's open source - all is possible, as the existence and presence of Java

For scientific applications, Java is still largely used. Maybe, because it is convenient for programmers.

Since we're bashing Java, I'm surprised that one of its biggest weakness hasn't been brought up yet: its official GUI toolkit (Swing) looks like garbage on Linux. It also clearly isn't coded properly, considering that it's uniquely incompatible with most tiling window managers.