Seeing some of the other posts, I think I should say for the record: I am actually a die-hard proponent of both the functional programming paradigm and of the strong static type system. My favorite language is Haskell.

So there's a lot of languages now I hate programming in:
- I don't like "dynamically" typed languages like Perl because I can't hard-code in all the type transformations (from function to function) or type value ranges to do a complete program prototype. (I put "dynamic" in quotes because strong type systems can be quite "dynamic" with parametric and ad-hoc polymorphism).
- I don't like C/C++ obviously because of the lack of referential transparency, but also because functions can't return copies of all objects; e.g., you have to return a reference to an array, instead of returning a copy of an array (or making a copy and a returning a reference to that, which can obviously be messy when you don't have gc).
- This will sound a bit snobby, but I don't like lowest-common-denominator languages like PHP where the goal is to get the least knowledgeable programmers turning out code and applications as fast as possible. Programmers should be striving to understand the mathematical and theoretical concepts that make for great programming, and the languages themselves should encourage that.

Having said all that, viewing each language within its own culture and assumptions, I'm inclined to be less harsh.

If something requires you to be smart while that same something can be implemented in a manner it requires from you much less effort, the implementation is bad.

And C++ template language is not object-oriented, it is functional.

1 members found this post helpful.

I believe you're correct, but what I had in mind was it's manipulation of functions and types rather than operating on snippets like cpp does. In fact, I've used templates in a way that made what I wrote somewhere between functional and OO. It would have been a very graceful solution to my problem except the C++ paradigm of passing and returning arguments made it more ugly than other solutions.An unskilled programmer can write a bad program in any language. The hard truth for skilled programmers is that most people can't or are unwilling to think like a programmer, but many of them can benefit greatly from what we see as detrimentally-simple languages. If someone can make their work week 20 hours shorter by automating a redundant task for themselves, even in a language that's unsuitable for "real" programming, I don't see that as a bad thing. I'm wondering if "scripting language" should be synonymous with "not for real programming", then. If not, there should be a word that means "I didn't design this as a programming language, but rather as a convenience" and we should object vehemently when those languages are called "programming languages." As of now there is no clear threshold for languages that draws a line between "feature-packed 'convenience' languages" and "poorly-designed 'programming' languages".
Kevin Barry

1 members found this post helpful.

While agreeing with the general tenure of what you said, I am not convinced that the above statement is true. There are some languages, are there not, in which simply the process of learning the language will force you to become a better programmer, because the fundamental premises and constructs of the language are based in some higher theory. For example, can you really spend a month learning Prolog (successfully) and still remain an "unskilled" programmer? If you fail to learn the core concepts, you would fail to learn the language itself, would you not?

A more familiar example for me would be Haskell, in which so many higher concepts are infused into language design that is it impossible to accomplish anything of practical size without learning them. Enforced referential transparency implies an understanding of the difference between pure functions and tainted functions, which in turn plunges the user into contact with the monad and category theory. The rejection of the more commonplace oop syntax (which comes along with referential transparency) forces a consideration of polymorphism related concepts (parametric polymorphism, ad-hoc polymorphism, existential quantification, and so forth) and a reconsideration of how polymorphism is best applied. And accommodating Haskell's strong typing system leads naturally to user-defined types and the flexibility of Haskell constructors, which will lead to better program architecture.

Perhaps someone with a broader background might know another language or two like that.

Well, as "fun" as some languages might be to program in, this does have to be checked with the realization that, most of the time, you are working with software that is a dozen years old or more. Furthermore, you might well be dealing with systems that are written in more than one language at a time.

A seasoned programmer will write "good code" in whatever language she needs to be using, because she is experienced enough to know how to design and write code that is both lucid and maintainable. ("She?" Yes. By far, the most talented programmers I know are women. I'm not.) She will also be able to move easily from one programming language to another, because she has a strong foundation of knowledge of what all of these languages have in common with one another.

In these days and times, machine efficiency is no longer the most drastic consideration: we have both memory and CPU-cycles to spare. What we do not have, however, is any programmer time to waste. And, because of the extremely centric place that software systems have in every business in the world, we have almost no opportunity for avoidable error. "If you screw this thing up, you screw up big."

You basically just said "you can't become competent without becoming skilled," which may or may not be true. What I'm saying, however, is that no programming language can protect programmers from themselves to the point that their programs are immune to both bugs and unmaintainability. Such a language would be so inflexible you'd get no real work done.
Kevin Barry

This might be true for software that largely waits on user interaction or changes in hardware state (e.g. enterprise, web, and some industrial applications,) but it's certainly not the case for scientific research (e.g. adaptive experiments) and real-time computation-intensive data analysis (e.g. video face recognition over a crowd.) A huge number of programmers exist (such as myself) who on occasion write nontrivial programs that take as long (or longer) to run as they take to write. Efficiencly isn't as obsolete as people have tried to make it.
Kevin Barry

In addition to that I'd like to add that in certain virtualised
environments the cost of memory and/or CPU hogs may be
considered prohibitive, e.g., Linux on IFL with a ~ 5000 $ / GB
(some handwaving there, prices may vary for country & IBM tie-
in) makes certain apps look like really bad choices.

But we're digressing from the initial question ...


Cheers,
Tink

Yes, but it is very interesting for me to follow this thread. I Would like the discussion go on in that way

Markus

It's also not true for smaller programs that will be executed remotely by tens of thousands of users, running millions of such programs per day.

Sure, there's almost no problem in computing you can't solve by throwing more money at it, but money is still a finite resource.

In many cases capabilities must be defined in terms of what can be done within a certain time limit. Sure, you can wait to upgrade hardware, but an application that runs inefficiently will do so more quickly on faster hardware. Unless that hardware is fast enough to make running time trivial, making the software more efficient will increase capabilities with or without an upgrade.
Kevin Barry

Not entirely. As far as I'm concerned, the "hardware is cheap" philosophy of some programming languages makes them undesireable. In several cases I've seriously considered whether or not to move something from MATLAB or R to C++, which wouldn't have crossed my mind if computation time wasn't an issue. The ultimate deciding factor wasn't use of programmer time, but rather the dim prospect of having a future programmer competent in C++.
Kevin Barry

RPG. Learned that in college. Very single minded and you had to follow its flow, no branching or subroutines.

Thank you. I was beginning to think I was the only one left who counted cycles (yes, an exaggeration, but only a slight one). Not every new program runs on a monster computer with a GUI and limitless disk and memory.

My least favorite language: English. Not enough rules, too inconsistent & vague, hard to write a good compiler for it. Works okay with an interpreter, sometimes.

--- rod.

Totally OT, but would any of them happen to be good looking and single?

1 members found this post helpful.