And shell scripting sure isn't a bad language one you learn all of its quirks. They can be confusing if you're a newbie, though.

I'm not a fan of IDL either (though am forced to use it, as it's standard in my field and reimplementing things in anything else would take time). I don't do anything with linear algebra, but I hate that in IDL you can use round brackets for arrays (MATLAB also suffers from this, of course), because you can confuse functions with arrays. In my own code, I use square brackets for arrays, but if I'm using someone else's, it's a problem. I also dislike that it doesn't have tab completion and if things spill onto another line, you can't edit the line with backspace. There are other things that I dislike about IDL, but these are the main things.

I do have to say that I quite like R and would use it for the sorts of things I do (data analysis) where I had a choice.

Shell scripting is a bad language because of all its quirks.

1 members found this post helpful.

But as far as I can tell, they are all necessary and make sense once you understand them.

How would you design a "quirk-less" shell script language?

By the way, C++ can be considered pretty bad - despite its wide usage.

An example of its badness is the amount of 'const' in a typical properly written C++ code. My point is since 'const' is that often needed, the need to write it explicitly means a bad choice of default. I.e. the default should have been 'const', and the opposite to it should have been 'var' or whatever other name meaning "changeable".

Tcl ... the fact that you're allowed to redefine base language
constructs as you go just makes me cringe. I find the whole
thing next to unintelligible ...


Cheers,
Tink

Lucky you! I had to pass two COBOL courses in college... So my vote for worst goes to COBOL.

1 members found this post helpful.

My memories of TCL are also quite bad - it was very difficult to debug. I.e. the error messages and the actual locations of problems used to be quite uncorrelated.

It's not that shell script langauges are intentionally bad like INTERCAL, it's just that the trade-offs that were made resulted in a language that is bad for programming. It's okay for simple interactive use.

es, maybe?

2 members found this post helpful.

Back to C++ - the official undebuggability of templates, i.e. lack of prescribed by standard at least 'print' statements allowing to trace template specialization, recursive expansion, etc.

1 members found this post helpful.

Thanks for the post. I often find your posts quite educational .

The trouble with shell scripting is that it is nothing but quirks. Some people like that. The shell tools are good to great (awk, sed, and so on), but shell scripting itself... yuk++. Non-designed by pony-tailed sandal wearing high-flying hippies, possibly a pre-1970s variety, as far as I can tell. Oh yeah, did I mention I don't like shell scripting? Its almost as bad as perl.

Not a newbie. 12+ year linux user. 30 year software developer (almost entirely in linux, web, embedded systems).

I've been thinking about this thread for a while. What language have I used that I could consider the worst?

Well, there's basica/basic/ub, those were pretty annoying, but at the time there wasn't anything else (that I knew of), and they really weren't all that bad. As well as, in some odd way I actually prefer basic's peek() over c's *, (TYPE *), &, etc. (Not for usefulness, but for readability ).

Then I moved on to asic and Qbasic, and that's the first time I remember running into this...
-------------------

Were the languages useless? No! Not completely, they had their uses.

After that, I moved into Windows 95, and tinkered around with Borland C/C++ (Didn't get the hang of it, though), and RQBasic which was my first experience with OOP programming.

Were these two awful languages? No! Not completely. They had their uses.

Then a couple of years ago I began playing around with C, Assembler (Intel syntax), FreePascal, FreeBasic, Bash, Yabasic, Calc, and a few others, but not counting scripting languages C and Assembler are the ones I remember the best.

C. The only things that really bug the living daylights out of me are the symbols, *, &, (TYPE *), etc, but oddly enough I love Asm's (intel syntax) "CODE reg/mem, reg/mem" or "CODE [reg/mem], reg/mem" or "CODE reg/mem, [reg/mem]". Though, Asm is rather a pain to modify, unless I want to have some spaghetti on the side.

Were these two languages awful? No! Not completely. They had their uses.

So all in all, I'd say there hasn't been a programming language I've used that I could consider the worst. They've all had their uses.

Many of the quirks in shell scripting result from the transparency of invoking subshells and external binaries to handle constructs that aren't particularly special in any other language. For example, it took me a while to realize that [ is a program (and/or built-in) and ] is its mandatory last argument; that piping to a while loop invokes a subshell, preventing variable changes from leaving the loop unless you contain it with {}; and that cd could never work if it wasn't a built-in. Shell scripting has the unfortunate quality of having the syntactic features of a programming language without actually behaving like a programming language. In fact, I'd go so far as to say that shell scripting is merely an evolved method of giving control structures to shell tasks. That being said, shell scripting is one of my most-used and favorite tools. It's easy to call it a language then call it poorly-designed and inconsistent, but it excels at its purpose of streamlining shell tasks.
Kevin Barry

1 members found this post helpful.

Honestly, a few years ago I would have really argued against you, but last week I finally made the distinction between "favorite" and "most-proficient" language. I've certainly called C++ my favorite language in the past because it's been the language I've had the most intimate knowledge of for several years, but I do have to agree that the combination of ISO platform-generality and the required behavior of templates has made them difficult to debug, increases compilation times, and increases binary size significantly.

Debugging templates is mostly a matter of experience with the types of error messages vs. the semantics of the line in question, which took me years to acquire. It would be extremely helpful if typedefs weren't expanded for error messages in templates. Error messages should be more clear; however, templates are effectively implemented as an object-oriented preprocessor so template-related errors within functions often happen during a different compilation stage than parsing of the template itself. This is also what allows you to write a template that contains operations that are clearly nonsensical for types you'd never use with that template (e.g. using void as a character type for std::basic_string.) On the bright side, you generally get a line number and a function name with the error. R, on the other hand, won't give you a line number and it only gives you a function name under select circumstances.

C++ is stretched a little too far across the abstraction spectrum for its own good. It has mandates at the binary level stemming from compatibility with C, but it also has very abstract mandates in the form of templates, virtual functions, and virtual base classes*. The addition of function and operator overloading and member functions has made C++ distinctly incompatible with C at the linking phase (some sort of FFI in the standard would have been helpful.) And, of course, polymorphism of run-time objects is generally a one-way funnel toward the top of a class hierarchy (I won't even start with dynamic_cast and RTTI.)
Kevin Barry

*In other words, C++ is mostly defined in terms of behavior, but it has enough representational mandates to make it difficult to implement all behaviors in an efficient and debuggable manner.

PS Java fixes some of these problems, but it does so at the expense of flexibility and low-level control. In fact, it seems that the flexibility and low-level control provided by C++ templates are precisely what makes them so difficult to debug.