I've never heard anyone informed bash C. C++ and Java, yes, but not C. Even people who've never used it tend to know that C has a domain at which (a) it excels, and (b) it's really the only credible option.
There's actually no such thing as a bad language. I enjoy language wars as much as anyone else, but languages are only good or bad relative to the type of problem they're being used for.
For example, what makes C++ and Java odious is that people try to use them for inappropriate purposes. They aren't platonically "evil" languages, and they weren't designed by stupid people; they're just inappropriate for over 90 percent of what modern programmers have to do in their professional lives. When people need high-level features and don't have them, they tend to roll their own-- badly. This is Greenspun's Tenth Rule and the heart of those god-awful "design patterns".
C++ and Java, for all that, also have domains in which they're the appropriate languages to use. They're just very small.
I do think there are bad languages. Brainfuck is terrible. Maybe there are no bad serious languages, but you'll have to define what you mean by serious, and you'll have to argue with Dijkstra's ghost when it comes to COBOL et al. (though I think he would have liked J). (His two famous quotes against COBOL come from http://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html) I don't think good/bad is really the best way to judge languages, I'm more interested in language power, fluidity, and library support.
I'd agree that every language has a purpose, even if the purpose is as simple as making a joke like in the case of LOLCODE, and that people abuse the language beyond its intended purpose. I read somewhere someone asserting "Design patterns are missing language features" and I more-or-less agree with that.
I do think there are bad languages. Brainfuck is terrible.
Brainfuck is not terrible, it's just not easy on human eyes. Brainfuck is really a very simple 8 instruction turing machine designed to have the smallest possible compiler on the Amiga (240 bytes, at that). It is actually a derivation of p'', which is a programming language from the 60s used to describe a family of turing machines.
Now, for a truly terrible language, I introduce you the only programming language named after the eighth circle of hell in Dante's Inferno...
Writing programs in Malbolge is so difficult, typically one has to use another language to generate programs and search for a working malbolge program, or make extremely large programs that go on for pages.
Why would he have liked J? I do not see how he would describe it differently from "a mistake, carried through past perfection". Also, slightly related: he may not have seen J, but http://www.dijkstrascry.com/node/90 shows that he can not have been totally unfamiliar with APL developments.
I hadn't seen that note from him, thanks for the link. I think J solves a lot of the problems he makes of APL. It can be taught without a J interpreter, it doesn't require a special keyboard, and it offers abstraction capabilities. Also it's an answer to some positive things he talks about in this 1985 interview and elsewhere: http://www.cs.utexas.edu/users/EWD/misc/vanVlissingenIntervi... It supports both functional and imperative styles and it's deeply rooted with mathematics. It's also "hard" and isn't made for the layman developer. It encourages a very logical thought-process. I would guess he'd think Haskell was superior, but I still think he'd at least consider J in higher regards to APL even if he didn't like it.
I really flipping "hate" C. It's used for everything in Linux it seems like. Things that really ought to be high level turn out to be a libfoo.so, requiring a C compiler.
It's not a gui programming language. It's not a text-handling programming language. It's not a symbolic programming language.
But it's used as those, constantly.
Pointer-based errors are endemic to C; they ought to be an expected part of the language usage by now. There are reasons why static analysis tools such as Klocwork are out there, and are very expensive... and keep being bought. Because C is bad for an incredibly large range of tasks that it keeps getting used for. I've done some of that, and using C (or C++) made things harder and more error-prone.
It's also very good at other tasks... like writing OS kernels or drivers. I've done some of that, and C made it possible.
Although at this point, I'd be interested to give writing an OS in D a spin to see how it works.
> I really flipping "hate" C. It's used for everything in Linux it seems like. Things that really ought to be high level turn out to be a libfoo.so, requiring a C compiler.
I'm confused by what you mean. What is this "higher level" that functionality should exist at that is above libfoo.so?
I think the difference is, most people recognize that there is a place where C is really your only choice. Maybe you need a little shim code to interact with a shared object in another language from ML or something. It's harder to argue that for C++ or Java.
Other than when compilers are simply not available, a rare occurrence these days (and I will argue "missing the point" if that's the only important property of the language), I am having a difficult time imagining a situation where C works but C++ would not.
However, C is not suitable for all purposes and it would be nice if people bashed it a little bit more. For example, it is a very common as an introductory CS101 first programming language here in Brazil even though it is full of traps for begginers and has some severe limits in expressive power (most notably, manual memory allocation really gets in the way)
My son's CS101 class at Penn State was based on C++ and supposedly taught OOD/OOP. But the instructor only focused on syntax and there were vast portions of the whole class system missing from the course.
I think it's probably a mistake to teach OOD/OOP in an introductory course and would rather see types, assignment, flow-control, etc. covered in a thorough manner. As it was, he ended up with big gaps in his general knowledge.
If I was teaching a programming class, I'd probably pick Coffeescript or Python as the implementation language (Nothing against Ruby ... I'm just not expert enough to be teaching it).
My rationale is that I can easily start just by letting the students type into REPL while they're learning basic concepts like assignment and operators. Classes are there when you need them but can be ignored until the students are comfortable with both the language syntax and the basic concepts behind programming.
I hate classes where the instructor says "just do this without asking why for now" ... and I learn best when I can experiment freely and iterate quickly.
I think another problem with teaching java in university is that pretty much everything is defined in detail. I have seen students that were taught java write ocaml code that expected a particular order of evaluation of expressions (which is undefined (implementation defined) btw).
C needn't be the only credible option in its domain forever.
There is another axis of 'badness', other than suitability for the problem domain. C's main problem is features that look fine but might subtly invoke wrong behaviour - the infamous traps and pitfalls.
If you can accept this view, then there /can/ be such a thing as a bad language, and it can be possible for two languages to suit the same domain and one to be better than the other. The domain that C serves well is not going away (though it might shrink, as more suitable tools are used for things like compiler-writing), but a better langauge for the domain could come along in the end.
Does anybody here have an idea why? I have heard reasons ("interfacing languages is a mess" and "you'd have to learn several languages" being the main ones), but none I found compelling (especially when the alternative is C++).
If it's irrational to reject multi-language solutions (I believe it is), why do people keep doing it?
When the DoD started what became the Ada mandate, they had some insane number of languages and projects scattered about. I don't remember the exact number but think something like 450-500 and this was from the 1960s and 70s when they still weren't terribly digital. At the macro level, that's impossible to maintain. I think a large part of the multi-language dislike came out of that. There is a giant difference between 3-6 languages and 400, it's also harder to get good people once you add a new technology to the stack that they need to know. There are generations of developers and IT/IS guys that have been trained and warned of the dangers of polyculture. That's why people keep doing it.
Tool support is usually poor, particularly for debugging. Interfacing languages is a mess, whether obviously (if you do it by hand) or hidden away (if you use SWIG). More code to deal with and step through. Higher chance of really ugly, hard-to-diagnose side effects from making a mistake on the C side. People working in both languages will regularly introduce bugs or perf problems because they get the languages mixed up as they're working. If you have less-technical people working in the higher-level languages, they'll will work around bugs in the C side, so you never hear about them until you fix them and break everything.
I've worked on a number of mixed-language projects, and these same issues keep cropping up. Perhaps it depends on the team, but that is not something not everybody gets the chance to choose. My current mixed-language program (tcl/C++) is working out OK, with just me working on it, but tool support is poor, and hand-writing the language interfaces is annoying.
(Notable exception: Visual Studio 2010 looks to offer pretty decent mixed native/managed debugging, and the CLR has good C++ interop support.)
I haven't had the opportunity to try it yet, I only heard about it a couple of days after the last time it would have been really really useful (naturally). But I know it's going to come up sometime.
Well well well... I've long liked the look of gdb 7 and its python scripting, and now it is looking better and better! I like it when I can retire a longstanding problem. (Luckily there's never any shortage of further problems to replace it with, so I won't run out of things to talk about.)
Now seems doubly annoying that Apple make you use lldb or crappy old gdb 6 for iOS.
It increases complexity. Your build system needs to be configured to support all the languages, you need code style guidelines for each of the languages, you need rules about when to use each language, you need to ramp up each new team member on the languages, etc. All this is overcomable of course, but it stacks the odds against using multiple languages.
The little bit I have seen of multi language code would say that that holds, especially if the languages involved are not C and something else(What does a Python dictionary look like in Haskell? Answer: Crap unless you do a bunch of translation work). Debugging tools don't tend to work across language boundaries. etc. Maybe I gave up to quickly, but multiple languages in one executable just doesn't seem worth it. Writing components in different languages and have them communicating over some sort of shared bus, web services, whatever is simple and fairly effective.
Couple of old projects (ha sw top on linux) that I've worked the soultion was using C and Python. C for the system stuff and Python for the CLI-part. Which worked quite nicely on that division. My personal taste would have been to use Python a bit more, but the division was 'set to stone' at the start of the project and some managers were inclined to change it.
There's actually no such thing as a bad language. I enjoy language wars as much as anyone else, but languages are only good or bad relative to the type of problem they're being used for.
For example, what makes C++ and Java odious is that people try to use them for inappropriate purposes. They aren't platonically "evil" languages, and they weren't designed by stupid people; they're just inappropriate for over 90 percent of what modern programmers have to do in their professional lives. When people need high-level features and don't have them, they tend to roll their own-- badly. This is Greenspun's Tenth Rule and the heart of those god-awful "design patterns".
C++ and Java, for all that, also have domains in which they're the appropriate languages to use. They're just very small.