@ october:
Quote:
I'm searching for a language that ?s close to the machine AND easy to read & write.
Many mainline languages depend on the developer to care for readability. And I am sure BASIC code written by a careless coder can be as incomprehensible as C code written by a careless coder.
The thing that makes
bad C/C++/Java/Perl code so unintelligible is that these languages can
do so much. Now, usually you
want such a powerful language.
Well-written C/C++/Java/Perl code can be read and understood single-pass, top-down. If you cannot, that's a problem of the
code, not necessarily the language.
And, consider that your ability to read BASIC so easily might be because you are
used to read BASIC. I am used to reading C++, and if I have problems making sense out of some piece of code, that's usually because my co-workers didn't care for maintainability when writing it.
Schol-R-LEA wrote:
Huh? Perhaps I'm missing something, but I can't see the real advantage. Templates as they exist in C++ are a workaround due to the lack of a singly rooted object hierarchy, or such as my understanding.
Classes are the building block of one concept, namely "object oriented programming".
Templates are the building block of a
different concept, namely "generic programming".
The two are distinct, but quite usually a "generic" language is also "object oriented" because the two concepts go well together.
Quote:
Is there some other advantage of templates that I've overlooked? I'd be interested in seeing what I've missed.
There is, and I am lucky in that a coworker of mine is in the C++ Standards Committee, with templates being his speciality - I can use them quite well, but
he's the language lawyer knowing the "Why". He's on vacation right now, so I will open up a "Templates Explained" thread once he gets back.
Quote:
I just think that the advantages and disadvantages of any programming language should be thoroughly understood and recognized, and that different alternatives should be considered when choosing how to implement something.
Two factors often overlooked:
* do you really believe you can design a better mousetrap?
Sure you can go ahead and design your own language. But advancing that language to production level will take years in itself, requires quite some expertise, and in the end there
will be some bolted-on expansions because you won't get it right the first time. Do you really believe it's worth the effort?
* how many developers looking at the project will have to learn a new language just to participate?
Usually you won't find developers that are good / experienced
and have lots of time. The good ones almost always are notoriuously short on time. They won't bother learning a new language (donating time) just so they can donate time to
your project - they could advance their knowledge in a field that actually earns their money instead...
Basically, by designing your own language first, you delay your project by at least two years, increase your chance of failure, and limit your potential co-developers to those who have lots of time - thus being either students or fanatics.
Get me right, I'm not saying that students and/or fanatics cannot do a good job. But, so I found, the most valuable input comes from the pro's, and they seldom are in a mind of learning a new language they cannot put to use
anywhere else.
(That's why I, even while being interested, haven't had a closer look at e.g. FORTH, Smalltalk, or Oberon: I can't apply them on my job.)