It does have to interpret the messages at some level, lexers for example aren't known for giving the best error messages (most of the time they don't have sufficient information to do so). Often the compiler will go looking for the exact mistake itself if it gives a good error message.
Yes, but that's the UI interpreting the output of the compiler for you. The actual compiler errors aren't nearly as clear as you might think. Oracle/Sun's java compiler is about on par with GCC in terms of error reporting in my opinion.
I won't argue with you about that, it's simple and very powerful. Other languages have tried to enhance it but in the end they all go back to the original design. It's not the most elegant thing in the world but it gets the job done.
The Cypress EZ-USB FX2LP ( http://www.cypress.com/?id=193 ) is a nice example of the 8051 still doing its job. If you want something more specific I suggest using Farnell to find one that suits your needs, they allow you to sort on 8051 and 8052 designs.
And VHDL for anything else than hardware synthesis is indeed something only a lunatic would use. But for building up systems it is a common choice in academic settings. Verilog isn't near as predictable as VHDL, and SystemC hardware synthesis is rather problematic.
You're wrong. I only got to terms with OOP after becoming familiar with hardware synthesis. It is a very natural method if used correctly. I agree it doesn't lead to the most efficient machine code. I also agree that the Ruby and Java style OOP is just a bad idea. Then again, it's a compromise just like everything else about your computer. But the correct naming should be modular programming. OOP is a valid paradigm to pull a program into modular chunks. You can make the rather small parts of code in the module very efficient. They might not tie into the rest of the application in the most efficient way but it'll work just fine. In fact objects are a logical extension of dynamic loading. There are a few set entry points, and everything happens in the library its own memory space or the program's memory space (see this as public, protected and private access in some way). When the code is done executing it'll return to the main program and return its values through some mechanism like a stack. Now doesn't this sound an awful lot like an object?
Being against something in a radical way is stupid, you neglect its possible uses and the advantages it might offer. It's the same with people who are radical against a certain language (except Ruby, you're allowed to hate that one cause it really is a bad idea in terms of readability in my humble opinion).
Personally I find myself aligned with Ada's methodology for modular programming, but sadly many people have difficulties grasping the finer points of the language. Ada allows you to drag pretty much everything out of any system if you use it correctly. Most people just don't like that Ada really won't let you mess around with data types as you wish; you respect Ada's way or you can bugger off. But in return you gain security and speed, the compiler knows exactly what will occur at any given point and is able to produce very efficient code. Still people hate it for various reasons; First of all it was made by the U.S. military, I grant you that's not a good start all things considered. A second problem is the lack of popularity on the internet. I have yet to find a good Ada tutorial on the internet. Third and foremost it's very verbose and strict. Make one mistake and the compiler will come back at you with a long sharp object with the sole intention to pierce your vital organs and your children. Ada programmers will often curse at the compiler like there'll be no tomorrow cause of it. They'll blame it for every bad event on the planet, but at the end of the day they know it'll do its job and prevent them from writing bad code.
The real problem here is that they assume that search engine popularity translates into language popularity. It's not cause a bunch of hipsters want to learn how to make an iOS application that it's actually going to become the programming language of choice for a majority of the developers.
C in combination with some form of assembly still holds the absolute first position in terms of how much its actually deployed. Every mainstream OS its core, bootloader,... was written in C and assembly. And lets not forget about all the microcontrollers out there. Almost all mainstream microcontrollers are programmed in C and assembly. And there are a whole lot more microcontrollers out there than CPUs. Lets take the 8051 as an example; If you knew how many USB controllers actually use an 8051 internally. I'd go as far as appointing the 8051 assembly a top 10 spot if the amount of deployed units of software is taken into account.
C++ holds its second spot without problem simply due to the fact that it's compatible with C and it does offer native object extensions.
The top 5 will probably be completed by Visual Basic, C# and Java for enterprise applications. They're perfectly fine languages for such goals and they do their job well.
After that it becomes tricky, most likely a couple of web languages like PHP and Perl in combination with a few of the old gems like Ada and FORTRAN. Ada is used in the aircraft industry on a regular basis and FORTRAN is the corner stone of weather prediction. Two rather interesting languages (not really programming languages though) would most likely also show up on there: VHDL and Verilog.
Anyway, I would just wish people would stop linking to the TIOBE index cause it actually has 0 value compared to real research into the subject. I'd rather see them do a study trying to correlate suicide statistics in the programming community with the programming language that was being used at the time, that might actually give more information about how good a language is than a couple of search engine hits.
Objects simply allow for an efficient programming structure for large software. That's the main reason. The real debate is about how far this object orientation should go. There are people like me that are of the opinion: use objects when necessary for structure. Others on the other hand will wrap anything in layers of objects. Dynamic allocation isn't strictly necessary for object support (see C++ to know why). It's just that most object oriented languages now also want to use polymorphism, at that point dynamic allocation is necessary cause it's near impossible for the compiler to predict what'll happen. But it's a rather pointless debate in the long run. To each his own as they say.
It's like the static vs dynamic linking debate that you sometimes hear. There's no real valid answer to that one either, it's a best guess on what'll lead to the best performance. With dynamic linking you don't need to load all the libraries at the start, on the other hand with static linking you don't need to call up the linker each time a library is loaded, and so on... My main advice: stay out of it. There's no real valid answer to these sort of things.
Of all the UN-related organisations out there ITU is one of the few that actually takes decisive action on a regular basis. Might take a while until we see results, but ITU won't back down for Apple or Microsoft.
People often forget Ada's main asset. It's brilliant at multi-threading and parallel execution. Very few languages are capable of what Ada can do with that.
But it requires a certain mindset from the programmer that doesn't come naturally. I hated Ada until I had to start working with VHDL, being forced to think in parallel with a highly modular structure made things a lot easier. From that point on I finally understood why Ada is actually one of the best programming languages out there. It allows you to apply almost any programming methodology but prevents you from making bad design decisions. It also helps that it actively makes a difference between object values, methods and properties. C++, Java, Ruby,... really aren't able to do that.
And why C still gets used? Why replace something that does its job well. C can be a scalpel or a sledge hammer depending on what you want or need. Need to carefully modify certain parts of the memory, C is up for the job. Need to process a few gigabytes of data quickly, no problem. It's reliable, produces fast code, has good tool chains, it's well supported, and allows for quick coding (if the programmer knows what (s)he's doing). Another important fact is that you can combine it with assembly without painful constructions. In fact can't imagine writing low level abstraction code without using C. It's the perfect bridge between low and high level code.
Run to the hills and don't look back! I've tried on several occasions to explain basic statistics to social science students, it's a hopeless effort. Very few of them seem to have a feeling for it. And those that do will act like they don't cause it's "cool" to suck at statistics.
Oh no, SPARC is a wonderful architecture. Very efficient and well designed. But it's assembly just isn't my thing. But in it's defence it is consistent compared to some of the other assembly languages of that era.
And I agree, PA-RISC wins by a large margin.
I don't have much against SPARC assembly in fact. I'm simply not fond of it's syntax. Its not easy on the eyes, very hard to skim over to get a rough idea of what the code does. Often confusing naming combined with abuse of %. It just doesn't add to the readability. More than once I ended up having to rewrite code simply cause one symbol was missing. Often one that didn't seem to have much use other than to annoy the programmer. So the first language I think of in when comparing something in terms of readability is SPARC assembly.
And can't say that I've ever seen PA-RISC and Google doesn't seem to be willing to help me find a snippet of it.
Ruby is far from consistent in my opinion. But that's subjective so I'll skip that one.
Chaining dot operators doesn't add to the readability of a language as some people seem to think it does. Yet for some reason the Ruby crowd seems to assume this is a good idea.
It actually is slower than the competing languages. Python (also dynamically typed) is a lot faster. In fact in certain cases even PHP beats Ruby at speed of execution. And your assumption that Java can only be run by a virtual machine is just plain wrong. There are a lot of processors that offer native support for Java. And I wouldn't call it a significant success. Getting it to run at Java-like speeds means that Perl is still able to beat the crap out of it.
And it's unreliable cause it's layered too much on other technology. Too much that can go wrong.
Tail recursion doesn't imply the compiler rewriting what the programmer wrote to me, it simply means using recursion in the return line. And the problem with that is that Ada will do exactly what you wrote. That's pretty much the entire point of the language. If you read over the code it's completely predictable what will happen on execution. Tail recursion as you state it will lead to unpredictable behaviour. As such Ada will not allow it.
It's not cause you can solve most problems using large explosions that you should is it? The same applies to recursion. Using recursion on a system that requires guaranteed stability is a sign of bad programming practice. Especially if it comes to embedded systems. Programmers seem to have gotten used to having an excess of resources and the ability to press the reset button on the machine if all else fails. There are a few problems with this. Your first assumption is that your compiler will recognize it. Your second assumption is that the compiler is capable of rewriting every recursive call to a loop on its own. Doing any of those things just won't fly in Ada. You should really consider what the language was designed for. Anything that's unpredictable or might lead to problems at runtime was eliminated. And then people complain about not having them.
Tail recursion to me simply means using the output of the function it was called from as return value of a function. It doesn't imply optimization.
So you might want to look at how rewriting what the programmer did is against the Ada philosophy. You should keep in mind predictability is important. Hence using tail recursion really would lead to recursion in Ada, result in possible stack overflows.
Comparing Ada to COBOL is an insult. Yes, it was based on Pascal, but you should educate yourself about the language before you wish to make a conclusion about it. Ada isn't meant for your fancy programming. Ada is meant to get the job done. And it's very good at that.
And that's the common miss conception. The latest standard versions of Ada are fully capable of dealing with objects.
Actually Ada pretty much fits the description you've given except for the extensive library. The financial backing is already there due to the military projects attached to it. If you want reliable software for potentially dangerous things Ada is the only acceptable choice.
And Ada doesn't support tail recursion for the simple reason that well written software shouldn't need recursion. Additionally it's actually terribly inefficient, Ada was also meant for embedded systems. Do you realise what happens every time you call a function? Your processor puts the program counter and other registers on the stack and then jumps to the function call. Now this might sound efficient to you. But actually decreasing/increasing a value and jumping back is far more efficient in terms of CPU cycle usage. Additionally it's easier to debug software that does not employ recursion. Stack overflow is a nasty thing that you really don't want to happen in programming language that was designed from the ground up to be as reliable as possible.
I'd rather see Ada come into common use. Ada actually has a lot of uses, supports some of the more exotic programming paradigms, it's easy to read and it'll smack you in the head if you write something in a bad way (as in, it won't even compile).
I agree that was the case on the older systems. Luckily with the increase in processor speed it's not that much of a problem any longer. But I must say I have noticed that Java does seem to work smoother on Intel processors. Probably might have something to do with the compiler Sun/Oracle has been using.
Java is fairly simple for a beginner. No need to worry about memory management. But it still exposes enough to be useful for any goal.
I wouldn't call Ruby, Clojure and Ceylon easy though. Ruby has a horrible syntax, it's slow and unreliable. Ceylon has another problem, it tries to make Java easier, and indeed the basic parts are easier. But the behaviour is unpredictable for more complicated situations. Clojure on the other hand has horrible syntax. I'd say in terms of readability it might actually be ranked below SPARC assembly (and that's not a compliment).
Slashdot Mirror
Yes, and that might obscure the more worrying issue here. They infringed on the writer of ACTA's rights by copying said clauses!
It does have to interpret the messages at some level, lexers for example aren't known for giving the best error messages (most of the time they don't have sufficient information to do so). Often the compiler will go looking for the exact mistake itself if it gives a good error message.
If it gives a list of possible fixes it's sure as hell doing some for of interpretation.
Yes, and both are a bad idea; Notice the usage of the word "and". I never implied the styles were identical.
Yes, but that's the UI interpreting the output of the compiler for you. The actual compiler errors aren't nearly as clear as you might think. Oracle/Sun's java compiler is about on par with GCC in terms of error reporting in my opinion.
I won't argue with you about that, it's simple and very powerful. Other languages have tried to enhance it but in the end they all go back to the original design. It's not the most elegant thing in the world but it gets the job done.
The Cypress EZ-USB FX2LP ( http://www.cypress.com/?id=193 ) is a nice example of the 8051 still doing its job. If you want something more specific I suggest using Farnell to find one that suits your needs, they allow you to sort on 8051 and 8052 designs.
And VHDL for anything else than hardware synthesis is indeed something only a lunatic would use. But for building up systems it is a common choice in academic settings. Verilog isn't near as predictable as VHDL, and SystemC hardware synthesis is rather problematic.
You're wrong. I only got to terms with OOP after becoming familiar with hardware synthesis. It is a very natural method if used correctly. I agree it doesn't lead to the most efficient machine code. I also agree that the Ruby and Java style OOP is just a bad idea. Then again, it's a compromise just like everything else about your computer. But the correct naming should be modular programming. OOP is a valid paradigm to pull a program into modular chunks. You can make the rather small parts of code in the module very efficient. They might not tie into the rest of the application in the most efficient way but it'll work just fine. In fact objects are a logical extension of dynamic loading. There are a few set entry points, and everything happens in the library its own memory space or the program's memory space (see this as public, protected and private access in some way). When the code is done executing it'll return to the main program and return its values through some mechanism like a stack. Now doesn't this sound an awful lot like an object?
Being against something in a radical way is stupid, you neglect its possible uses and the advantages it might offer. It's the same with people who are radical against a certain language (except Ruby, you're allowed to hate that one cause it really is a bad idea in terms of readability in my humble opinion).
Personally I find myself aligned with Ada's methodology for modular programming, but sadly many people have difficulties grasping the finer points of the language. Ada allows you to drag pretty much everything out of any system if you use it correctly. Most people just don't like that Ada really won't let you mess around with data types as you wish; you respect Ada's way or you can bugger off. But in return you gain security and speed, the compiler knows exactly what will occur at any given point and is able to produce very efficient code. Still people hate it for various reasons; First of all it was made by the U.S. military, I grant you that's not a good start all things considered. A second problem is the lack of popularity on the internet. I have yet to find a good Ada tutorial on the internet. Third and foremost it's very verbose and strict. Make one mistake and the compiler will come back at you with a long sharp object with the sole intention to pierce your vital organs and your children. Ada programmers will often curse at the compiler like there'll be no tomorrow cause of it. They'll blame it for every bad event on the planet, but at the end of the day they know it'll do its job and prevent them from writing bad code.
Yes, but keep in mind. The C preprocessor is the only thing that stands in between the sanity of the average C programmer and the great void.
The java compiler gives useful errors?
The real problem here is that they assume that search engine popularity translates into language popularity. It's not cause a bunch of hipsters want to learn how to make an iOS application that it's actually going to become the programming language of choice for a majority of the developers. ... was written in C and assembly. And lets not forget about all the microcontrollers out there. Almost all mainstream microcontrollers are programmed in C and assembly. And there are a whole lot more microcontrollers out there than CPUs. Lets take the 8051 as an example; If you knew how many USB controllers actually use an 8051 internally. I'd go as far as appointing the 8051 assembly a top 10 spot if the amount of deployed units of software is taken into account.
C in combination with some form of assembly still holds the absolute first position in terms of how much its actually deployed. Every mainstream OS its core, bootloader,
C++ holds its second spot without problem simply due to the fact that it's compatible with C and it does offer native object extensions.
The top 5 will probably be completed by Visual Basic, C# and Java for enterprise applications. They're perfectly fine languages for such goals and they do their job well.
After that it becomes tricky, most likely a couple of web languages like PHP and Perl in combination with a few of the old gems like Ada and FORTRAN. Ada is used in the aircraft industry on a regular basis and FORTRAN is the corner stone of weather prediction. Two rather interesting languages (not really programming languages though) would most likely also show up on there: VHDL and Verilog.
Anyway, I would just wish people would stop linking to the TIOBE index cause it actually has 0 value compared to real research into the subject. I'd rather see them do a study trying to correlate suicide statistics in the programming community with the programming language that was being used at the time, that might actually give more information about how good a language is than a couple of search engine hits.
Objects simply allow for an efficient programming structure for large software. That's the main reason. The real debate is about how far this object orientation should go. There are people like me that are of the opinion: use objects when necessary for structure. Others on the other hand will wrap anything in layers of objects. Dynamic allocation isn't strictly necessary for object support (see C++ to know why). It's just that most object oriented languages now also want to use polymorphism, at that point dynamic allocation is necessary cause it's near impossible for the compiler to predict what'll happen. But it's a rather pointless debate in the long run. To each his own as they say.
It's like the static vs dynamic linking debate that you sometimes hear. There's no real valid answer to that one either, it's a best guess on what'll lead to the best performance. With dynamic linking you don't need to load all the libraries at the start, on the other hand with static linking you don't need to call up the linker each time a library is loaded, and so on... My main advice: stay out of it. There's no real valid answer to these sort of things.
Of all the UN-related organisations out there ITU is one of the few that actually takes decisive action on a regular basis. Might take a while until we see results, but ITU won't back down for Apple or Microsoft.
People often forget Ada's main asset. It's brilliant at multi-threading and parallel execution. Very few languages are capable of what Ada can do with that. ... really aren't able to do that.
But it requires a certain mindset from the programmer that doesn't come naturally. I hated Ada until I had to start working with VHDL, being forced to think in parallel with a highly modular structure made things a lot easier. From that point on I finally understood why Ada is actually one of the best programming languages out there. It allows you to apply almost any programming methodology but prevents you from making bad design decisions. It also helps that it actively makes a difference between object values, methods and properties. C++, Java, Ruby,
And why C still gets used? Why replace something that does its job well. C can be a scalpel or a sledge hammer depending on what you want or need. Need to carefully modify certain parts of the memory, C is up for the job. Need to process a few gigabytes of data quickly, no problem. It's reliable, produces fast code, has good tool chains, it's well supported, and allows for quick coding (if the programmer knows what (s)he's doing). Another important fact is that you can combine it with assembly without painful constructions. In fact can't imagine writing low level abstraction code without using C. It's the perfect bridge between low and high level code.
Run to the hills and don't look back! I've tried on several occasions to explain basic statistics to social science students, it's a hopeless effort. Very few of them seem to have a feeling for it. And those that do will act like they don't cause it's "cool" to suck at statistics.
Oh no, SPARC is a wonderful architecture. Very efficient and well designed. But it's assembly just isn't my thing. But in it's defence it is consistent compared to some of the other assembly languages of that era.
And I agree, PA-RISC wins by a large margin.
I don't have much against SPARC assembly in fact. I'm simply not fond of it's syntax. Its not easy on the eyes, very hard to skim over to get a rough idea of what the code does. Often confusing naming combined with abuse of %. It just doesn't add to the readability. More than once I ended up having to rewrite code simply cause one symbol was missing. Often one that didn't seem to have much use other than to annoy the programmer. So the first language I think of in when comparing something in terms of readability is SPARC assembly.
And can't say that I've ever seen PA-RISC and Google doesn't seem to be willing to help me find a snippet of it.
Ruby is far from consistent in my opinion. But that's subjective so I'll skip that one.
Chaining dot operators doesn't add to the readability of a language as some people seem to think it does. Yet for some reason the Ruby crowd seems to assume this is a good idea.
It actually is slower than the competing languages. Python (also dynamically typed) is a lot faster. In fact in certain cases even PHP beats Ruby at speed of execution. And your assumption that Java can only be run by a virtual machine is just plain wrong. There are a lot of processors that offer native support for Java. And I wouldn't call it a significant success. Getting it to run at Java-like speeds means that Perl is still able to beat the crap out of it.
And it's unreliable cause it's layered too much on other technology. Too much that can go wrong.
Tail recursion doesn't imply the compiler rewriting what the programmer wrote to me, it simply means using recursion in the return line. And the problem with that is that Ada will do exactly what you wrote. That's pretty much the entire point of the language. If you read over the code it's completely predictable what will happen on execution. Tail recursion as you state it will lead to unpredictable behaviour. As such Ada will not allow it.
It's not cause you can solve most problems using large explosions that you should is it? The same applies to recursion. Using recursion on a system that requires guaranteed stability is a sign of bad programming practice. Especially if it comes to embedded systems. Programmers seem to have gotten used to having an excess of resources and the ability to press the reset button on the machine if all else fails. There are a few problems with this. Your first assumption is that your compiler will recognize it. Your second assumption is that the compiler is capable of rewriting every recursive call to a loop on its own. Doing any of those things just won't fly in Ada. You should really consider what the language was designed for. Anything that's unpredictable or might lead to problems at runtime was eliminated. And then people complain about not having them.
Tail recursion to me simply means using the output of the function it was called from as return value of a function. It doesn't imply optimization.
So you might want to look at how rewriting what the programmer did is against the Ada philosophy. You should keep in mind predictability is important. Hence using tail recursion really would lead to recursion in Ada, result in possible stack overflows.
Comparing Ada to COBOL is an insult. Yes, it was based on Pascal, but you should educate yourself about the language before you wish to make a conclusion about it. Ada isn't meant for your fancy programming. Ada is meant to get the job done. And it's very good at that.
And that's the common miss conception. The latest standard versions of Ada are fully capable of dealing with objects.
Actually Ada pretty much fits the description you've given except for the extensive library. The financial backing is already there due to the military projects attached to it. If you want reliable software for potentially dangerous things Ada is the only acceptable choice.
And Ada doesn't support tail recursion for the simple reason that well written software shouldn't need recursion. Additionally it's actually terribly inefficient, Ada was also meant for embedded systems. Do you realise what happens every time you call a function? Your processor puts the program counter and other registers on the stack and then jumps to the function call. Now this might sound efficient to you. But actually decreasing/increasing a value and jumping back is far more efficient in terms of CPU cycle usage. Additionally it's easier to debug software that does not employ recursion. Stack overflow is a nasty thing that you really don't want to happen in programming language that was designed from the ground up to be as reliable as possible.
I'd rather see Ada come into common use. Ada actually has a lot of uses, supports some of the more exotic programming paradigms, it's easy to read and it'll smack you in the head if you write something in a bad way (as in, it won't even compile).
I agree that was the case on the older systems. Luckily with the increase in processor speed it's not that much of a problem any longer. But I must say I have noticed that Java does seem to work smoother on Intel processors. Probably might have something to do with the compiler Sun/Oracle has been using.
Java is fairly simple for a beginner. No need to worry about memory management. But it still exposes enough to be useful for any goal.
I wouldn't call Ruby, Clojure and Ceylon easy though. Ruby has a horrible syntax, it's slow and unreliable. Ceylon has another problem, it tries to make Java easier, and indeed the basic parts are easier. But the behaviour is unpredictable for more complicated situations. Clojure on the other hand has horrible syntax. I'd say in terms of readability it might actually be ranked below SPARC assembly (and that's not a compliment).