OSDev.org

Now; what do you think this "scientifically proven best programming language possible" would look like?

I'm not going to go in to a convoluted discussion of this because I disagree with your premise that there is such a thing as the "scientifically proven best programming language possible" any more than I believe there is such a thing as the perfect operating system. Languages simple and complex all have their role to play depending upon the task in hand and the person using them. (Not that that means that languages are beyond critical review.) I would no more use GW-BASIC to write an operating system than I would expect the hypothetical eight-year-old to use Eiffel to learn the basic principles of programming.

Hi,

iansjack wrote:

Now; what do you think this "scientifically proven best programming language possible" would look like?

I'm not going to go in to a convoluted discussion of this because I disagree with your premise that there is such a thing as the "scientifically proven best programming language possible" any more than I believe there is such a thing as the perfect operating system. Languages simple and complex all have their role to play depending upon the task in hand and the person using them. (Not that that means that languages are beyond critical review.) I would no more use GW-BASIC to write an operating system than I would expect the hypothetical eight-year-old to use Eiffel to learn the basic principles of programming.

You don't think that my "hypothetical, in theory, scientifically proven best programming language possible" actually exists? I never would have guessed...

There are only 4 possible points of view:

• You think that unjustified complexity is impossible (relatively insane)
• You agree that unjustified complexity is possible, but currently don't think anything in any existing language is unjustifiably complex
• You agree that unjustified complexity is possible, and do think at least one thing in at least one language is unjustifiably complex
• You're a spineless fence-sitter refusing confirm or deny anything in case someone assumes you're capable of rational thought

I think many languages have at least some unjustified complexity. What do you think? Please note that going off on some random tangent and ignoring what I'm trying to say is the same as the "spineless fence-sitter" option.


Cheers,

Brendan

You're a spineless fence-sitter refusing confirm or deny anything in case someone assumes you're capable of rational thought

Combuster is right - no point in discussing things in those terms.

If you can't discuss a subject rationally, why bother? I'll take the "spineless fence-sitter" option over the "I'm so clever that I know much more about everything than you do" line.

"Scientifically proven best programming language possible" is not possible (not only doesn't exist; it is not possible to create one).

Back to the point - I prefer a language that 95% of population doesn't understand over a language that 100% of population would understand. Why? Because no matter how simple and easy to use the language is, 90% of code written in it will always be total garbage and utter ****, and you cannot eliminate human stupidity from the equation by using impossible to create language.

I do not want a 10yo to be able to program. I want a 10yo to be able to SOLVE BASIC MATH PROBLEMS. And most of 10yo is "grown up" in such a way they cannot really understand anything more than "2 + 2 = 4" (and some are on the level where "2 + 2 = 5"). I do not want people unable to f*cking count on their fingers to program, because that's the reason that programming forums and IRC channels are filled with utterly garbage questions.

I do not want a simple and easy to use language, where I have to reimplement everything (like templates and polymorphism) from scratch to get any serious application done. I do not want a "simple and easy to use language", because it's impossible - language is EITHER simple or easy to use. Lack of template meta wanke^H^H^H^H^Hprogramming would sure make C++ a simpler language (let's not stick to the language I chose here, I could choose any language in the world). *Simpler* language. Language with less rules. But removing TMP from the language would render many really easy to use, powerful, and definitely not simple techniques useless.

I DO want a language that is moderately easy to use for starting person, and that is powerful enough for power programmer. So far, IMHO C++ is perfect at that. It sure have lots of caveats, but RAII and quite automatic memory management is sure better than manual memory management from C or from assembly, and is also better than totally automatic GCs (I *do* want to know *exactly* when my object is destroyed!).

Brendan will surely start to flame me for this entire post. I do not care, let's let him do that. I'm not going to further reply in this topic, unless someone misquotes me or asks for clarification. I have spent too much time arguing over languages already, and despite not being old I can clearly see when someone makes a theoretical argument in practical discussion just to start a flame. I am going to spend the time I'd spend arguing to write a real code, in a real language, that, thanks to those so complex rules will be short, but extremely reusable and flexible. Feel free to code only in your "perfect" and imaginary languages; just one note, though.

What you call "perfect", for others is nothing more than a bullshit. Are monads an element of a "perfect" language? Both possible answers will be heard. As everyone is different, everyone wants to choose his/her own tool and keep using it. And (s)he will keep using it as long as it is totally enough to do what (s)he wants to do, or as long as someone enlightens him/her that a better tool exists. The choice MUST exist. You don't like template meta wankery? That is 100% fine, you are not required to use it. Heck, you can even make a religion that use "template meta programming is utter garbage" and seek salvation in spreading this word. You can even tell me that people that designed an awesome, accidentally Turing complete tool are total idiots, but there are thousands of people around the world who use this tool, like or love it, and don't give a damn about what you think about it.

Choice must exist. All more or less recent "there is only one true way" attempts ended badly, because there is but one thing that people really want and will never give it up, as long as they can hope to get it: freedom of choice. And that is another reason why your "perfect, simple and easy to use scientifically proven language" cannot exist.

Hi,

Griwes wrote:"Scientifically proven best programming language possible" is not possible (not only doesn't exist; it is not possible to create one).

You'd think that people arguing for complex languages would be more able to understand abstract ideas, like a hypothetical "scientifically proven best programming language" (or the square root of -1, or anything else that doesn't actually exist but is a useful concept despite its non-existence).

Griwes wrote:Back to the point - I prefer a language that 95% of population doesn't understand over a language that 100% of population would understand. Why? Because no matter how simple and easy to use the language is, 90% of code written in it will always be total garbage and utter ****, and you cannot eliminate human stupidity from the equation by using impossible to create language.

If 95% of the population doesn't understand a piece of code, then that piece of code is 100% garbage to 95% of people. This is a higher amount of garbage than "90% garbage to 100% of people" would be (0.95 > 0.9).

If "90% of code will be bad code (regardless of language)" is a problem, then what would you do to reduce the amount of bad code? For an example, would you consider reducing the chance of bad C++ code (slightly) by removing support for "C strings" from the language (and accidentally reduce the complexity of C++ slightly at the same time)?

Griwes wrote:I do not want a simple and easy to use language, where I have to reimplement everything (like templates and polymorphism) from scratch to get any serious application done. I do not want a "simple and easy to use language", because it's impossible - language is EITHER simple or easy to use. Lack of template meta wanke^H^H^H^H^Hprogramming would sure make C++ a simpler language (let's not stick to the language I chose here, I could choose any language in the world). *Simpler* language. Language with less rules. But removing TMP from the language would render many really easy to use, powerful, and definitely not simple techniques useless.

There's 2 points here. The first is that you do recognise that there is a compromise between "easy to learn" and "productivity after learning" (this is good). However, it's not that simple - there are other compromises (performance, how easy/hard it is for compilers to support, etc). Obviously, for each possible feature you'd want to weight up the advantages and disadvantages before deciding whether to include/exclude that feature from a language; and you wouldn't want to (e.g.) ignore any disadvantage/s (and include everything that has any potential advantage at all, regardless of how many disadvantages it has). For a simple example, how would you feel about adding a "swap operator" to C++? Would the increase in productivity of being able to do "a :=: b" be justified by the extra complexity?

Your second point is templates. I'm sure you understand that templates are easy to get wrong and harder to debug. I'm also sure you understand how much templates complicate things like link-time code generation. There are advantages to "meta-programming", but are templates really the best way to get those advantages? For example, what if you could use something like Python to generate C++ code - would that avoid half the disadvantages of templates? For a start people would actually be able to look at the generated C++ code (in the same way that it's possible to see how a macro expands in C or assembly) and it'd make the C++ compiler a lot less complex.

*Please* try to understand that my main point isn't for or against the swap operator, or for or against templates, or for or against anything else. My main point is that language researchers aren't trying to find better compromises between complexity and productivity - they're ignoring the disadvantages (or at least severely under-estimating them) and ending up with more complexity just for a small benefit for a small number of people.

Choice must exist. All more or less recent "there is only one true way" attempts ended badly, because there is but one thing that people really want and will never give it up, as long as they can hope to get it: freedom of choice. And that is another reason why your "perfect, simple and easy to use scientifically proven language" cannot exist.

Everyone wants freedom of choice, but only if they're the person that gets to choose. Achieving a consensus has greater advantages.


Cheers,

Brendan

I know I said I won't reply, but I just couldn't resist

Achieving a consensus has greater advantages.

Achieving a consensus hurts everyone more or less equally and leaves no-one really happy, that's why different options for different people are better than single option for everyone. Everyone chooses what hurts him least.

Hi,

Griwes wrote:I know I said I won't reply, but I just couldn't resist

Don't worry - I'm still disappointed that you didn't attempt to challenge any of the main points.

Griwes wrote:

Achieving a consensus has greater advantages.

Achieving a consensus hurts everyone more or less equally and leaves no-one really happy, that's why different options for different people are better than single option for everyone. Everyone chooses what hurts him least.

WARNING: Hypothetical examples follow. Please DO NOT take these examples literally. I do know that both examples are extremely unlikely, and I an NOT suggesting they are likely.

Imagine if Microsoft, Intel, IBM, Apple, GNU, etc all decided that from now on they're going to drop support for all languages except C++; and all programmers only had to learn one language; and everyone could understand each other's code, share classes between any (open source) projects, use each other's libraries, etc. Would this be bad? I don't like C++, but under these circumstances I would be willing to sacrifice my freedom of choice for the benefits.

Imagine if Microsoft, Intel, IBM, Apple, GNU, etc all decided that freedom of choice was important, and created 20 different alternatives to IPv4/IPv6 to provide that freedom of choice; and (due to incompatible protocols) the Internet as we know it got split into 20 different separate internets. Would this be good? Under these circumstances, I wouldn't be willing to sacrifice the benefits of a global network just for "freedom of network protocol choice".


Cheers,

Brendan

Brendan wrote:Imagine if Microsoft, Intel, IBM, Apple, GNU, etc all decided that from now on they're going to drop support for all languages except C++; and all programmers only had to learn one language; and everyone could understand each other's code

You're not really saying that using one language would mean that everyone could understand each other's code? Because that I can understand the notation in which an algorithm is written down doesn't mean that I understand how it works semantically. The language is usually not what keeps me from understanding code.

share classes between any (open source) projects, use each other's libraries, etc.

You only need common ABIs for this, not a single language. You can compile several languages to compatible Java bytecode or CIL, and for native binaries usually the C conventions are the common ABI that every compiler can deal with.

With features that C doesn't have, like classes, the situation looks worse. But the problem is here really missing standardisation on a common API rather than standardisation on a single language. In fact, two compilers for different languages can be compatible and two compilers for the same language incompatible.

What you're proposing is the same thing as standardising on specific software instead of standardising on file formats, on implementations instead of interfaces.

Hi,

Kevin wrote:

Brendan wrote:Imagine if Microsoft, Intel, IBM, Apple, GNU, etc all decided that from now on they're going to drop support for all languages except C++; and all programmers only had to learn one language; and everyone could understand each other's code

You're not really saying that using one language would mean that everyone could understand each other's code? Because that I can understand the notation in which an algorithm is written down doesn't mean that I understand how it works semantically. The language is usually not what keeps me from understanding code.

If you can understand the notation but can't understand the how it works semantically; then you're looking at poorly commented/documented code. I can't think of a practical way to force programmers to write adequately commented/documented code.

Kevin wrote:

share classes between any (open source) projects, use each other's libraries, etc.

You only need common ABIs for this, not a single language. You can compile several languages to compatible Java bytecode or CIL, and for native binaries usually the C conventions are the common ABI that every compiler can deal with.

With features that C doesn't have, like classes, the situation looks worse. But the problem is here really missing standardisation on a common API rather than standardisation on a single language. In fact, two compilers for different languages can be compatible and two compilers for the same language incompatible.

What you're proposing is the same thing as standardising on specific software instead of standardising on file formats, on implementations instead of interfaces.

You're right - the ABI is a major part of the problem. It still doesn't help with the "learn 20 different syntaxes" problem though.


Cheers,

Brendan

Brendan, if this were ideal, then we would all be programming in machine code (David, here's your cue, lol). The reason for different languages is different preferences. This is like saying, "Prices would be much simpler if grocery stores only sold peanuts. If you don't like peanuts, or are allergic, starve."

m12 wrote:Brendan, if this were ideal, then we would all be programming in machine code (David, here's your cue, lol).

I'd better not disappoint you then. Not quite - you may want something close to that level but independent of actual instruction sets (unless you can come up with the ideal instruction set and get rid of all the others). I use machine code for a number of reasons, but one of them I now realise is a mental disability - I can't cope with abstract notations, so the further a language takes me away from being able to see the direct process, the harder things get for me. I can't cope with all the squiggles in maths either until I see it converted into a direct process, but as soon as it's put in the form that a computer can run as machine code, it becomes easy for me to understand. [Edit: and it's the same with music - I hate the way it's written down and have always had to work by hearing and memorising everything instead.] Writing programs in a natural language like English would be best though, and that's what we should all be doing already when writing the commentary on our code - the commentary should be regarded as the program.

Brendan wrote:You're right - the ABI is a major part of the problem. It still doesn't help with the "learn 20 different syntaxes" problem though.

I guess my point is that this problem doesn't exist in the first place. As long as the concepts are the same, understanding a different syntax isn't a problem. In some cases you need to invest a few minutes for reading about the syntax, but in most cases when there is an announcement about a new programming language, I'll go straight to the examples section, have look at it and in general I understand what the code is supposed to do.

Hi,

Kevin wrote:

Brendan wrote:You're right - the ABI is a major part of the problem. It still doesn't help with the "learn 20 different syntaxes" problem though.

I guess my point is that this problem doesn't exist in the first place. As long as the concepts are the same, understanding a different syntax isn't a problem. In some cases you need to invest a few minutes for reading about the syntax, but in most cases when there is an announcement about a new programming language, I'll go straight to the examples section, have look at it and in general I understand what the code is supposed to do.

This is very unrealistic.

Randomly pick 2 languages, and really think about how much time a person who has only ever used the first randomly selected language would need to spend become proficient with (not merely "learn") the second randomly selected language. Then randomly select a third language, and think about how much time a person who has only ever used the first 2 languages would need to spend to become proficient with the third language. Then select a fourth language, fifth language, etc.

Now do this for all possible permutations. What you'll probably find is that a person spends several years learning basic concepts that programming languages rely on (starting from learning how to count in decimal in kindergarten; going up to things like algebra, boolean logic and number bases). After this it might (on average) take 6 months to become proficient in their first language, 4 months to become proficient in their second language, 3 months to become proficient in their third language, etc.

Someone like you (who I expect has probably already spent a total of 2 or more years learning 5 or more languages) might be able to become proficient in another language in as little as 2 weeks; but this is only because of the time you've spent learning all the previous languages. It would be entirely wrong to ignore the previous "2 or more years learning 5 or more languages" and claim that anyone can learn any language in 2 weeks; and equally wrong to claim that "6 months learning one language plus a few wasted years" would be equal to (or less than) "6 months learning only one language".


Cheers,

Brendan

I agree with your observations, but I don't think the conclusion is right.

Why is it that the fifth language takes so much less effort to learn than the first one? I would say that the syntax is really only a small part of it. It is because in the first language (let's call it A) all concepts are still new to you. In your second language, B, you can already transfer a lot of knowledge from A, but B will probably miss some features from A and at the same time add some new concepts. You'll have to learn how to use the new concepts and how to replace the missing ones.

Now you learn C, and you can transfer everything that you know from the union of A and B. C will again introduce some new concepts, but the overlap with your previous knowledge is greater because you already know more concepts. In language F you'll see one or two interesting features, but everything else has already been there before.

The problem with your assumption is that learning only A will give you a much smaller toolbox. Any language that supports all of the concepts that you will have learnt by the time you've achieved proficiency in F, will not take only the six months of A, but more or less the sum of the time you invested for all languages from A to F. If it takes less, there are concepts that one of the other languages supports and the unified language lacks, and therefore it likely won't be able to obsolete the old language.

This is of course a bit overgeneralised, there are probably some features that you can easily do away with, but the point is that the additional knowledge from more languages is not only a useless impediment, but teaches you more concepts and therefore makes you a better programmer in the end.