I have read an re-read your post about an implementation of BASIC emmbedded within an application but I'm not convinced that it is a problem with C++ or just a crappy implementation of a BASIC interpreter. What you have described could as easily been messed up in C or any language.
I am SO delighted that someone with Torvald's credentials said what he said about C and C++.
Reading the linked Torvald's quote I get the idea he was talking more about the quality of programmers than the language itself.
Still, I remember many years ago their was an effort to use C++ in the Linux kernel and it did not go so well. Not surprising because at the time I had code that would compile with some compilers but cause GCC to crash!
A few years ago, I was assigned a couple of young guys to help out with a project after management decided it was too much for just me. They natuarally wanted to use C++. I tried very hard to dictate that they will only use as many C++ features as makes sense on a small embedded system. As it happened they were working in Stockholm and I was far away in Helsinki so they could do a lot of damage whilst I was not looking. Sure enough the project was full of every possible feature of C++. They finished their contract time and I had to spend an age cleaning up all the memory leaks:) The whole shebang has been now scrapped as unmaintainable. Luckilly I stopped working there a while ago.
C++ was a good idea. Only they should have quit the desire for it to be 100% backwards compatible with C. And somewhere along the line the whole language standard has got out of control.
For example:
Why keep forever the idea that 033 is an octal number?
Why do we need header files in which we repeat the same stuff as written in the C code?
Why do we need to continue to support the macro preprocessor when declaring constants and inline functions can do the same?
Yes you say what about "#ifdef BLABLA, well a normal "if" would do. If BLABLA is assigned but never changes the compiler can remove the appropriate code.
C has a lot of baggage that is practical, like the preprocessor, and designed to enable building programs on small systems but is basically a hinderence to just writing your idea in code. C++ has even more.
No, the whole caboodle is the problem, parA, parB, localA, localB, innerA innerB, they all don't exist when someFunc() returns in C. After all they were only ever on the stack.
Well, yes, but if they're declared 'static' then they're not on the stack, they're in the global variable space except that they're not lexically visible outside the function they're declared in. And there's exactly one instance of parA etc., and with that in mind it's reasonably easy to figure out what won't work. In any case, multiple instances of functions in C simply don't exist unless you evoke threads (and functions called from multiple threads should never have static variables unless you need exactly that single-instance, permanent variable that you protect as necessary).
As for translating closures-programming in e.g. Javascript to C I wouldn't even try that, you'll have to approach the problem from another angle. Which is what C programmers have done for a long time.
Not directly related, but it's not that difficult to program in an 'object' oriented way in pure C. The Linux driver model (and most Unix driver models) are done that way, and it's clean enough.
BTW there's a language called 'Vala', it's very C# like but compiles to pure C. It's got all the usual object oriented features. It's possible to compile to executable code, or to the intermediate C code which can then be compiled (even on another platform) by a C compiler. It's probably not that useful in a Propeller context because it's really designed to handle the GNOME GObject model. So it's very easy to program GTK+ applications. But it's also possible to use for non-GTK applications. Here's how it compares to C#: https://live.gnome.org/Vala/ValaForCSharpProgrammers. Just to show that other people are also trying to avoid C++ (well in the case of Vala it's really because C++ is so horrible for use with the GNOME libraries.
I am SO delighted that someone with Torvald's credentials said what he said about C and C++. (I'm stowing his quote in my briefcase, to pull out at opportune times.)
It is worth noting that the use of abstraction has had miraculous success, such as in chip design. But it may be too much rope in other cases. In the natural world, survival of the fittest takes care of such misapplications.
What Linus said is very clear to practical C programmers. This is the reason I talked about rope before.
People need proper guidance, and unfortunately education without practical industry experience does not give it. If educators can highlight practical things (rather than everything in a language just because it is there) the rope becomes a paint-brush. The folks in Parallax are very aware of the need for the paint-brush (think SPIN). Too bad that someone beat them to C++ version of it and took away so much market share (loathing C is the reason this happened IMHO).
Yes, I know what "static" does. Still you cannot make the parameters of a function static in C.
In C parameters are pushed to the stack, the function is called and then the fuctions finds it's parameters on the stack. Same as it does non-staic local variables.
If it were allowed to make parameters static that would imply that they are written to some fixed memory location, the function is called, and the function finds them there. Those memory slots would not be available to anyone but the caller and the called. Kind of pointless in C, except that a function could return a pointer to a parameter that lives on after it has returend.
Threads, oh yeah that will make things really iteresting. There is a difference between "instances" and "threads". We can or could have the former without the latter.
Yes, it's easy(ish) to program in C in an object oriented way. As we know early C++ compilers were just preprocessors to C that hid all the messy details like instance pointers from your source code.
Traditionally there was not much computing going on but a lot of computer science in accademia and such.
Those big time computer science thinkers came up with such things as ALGOL and Pascal and Ada where correctness and algorimic expression was the main thrust. In this collection we can put operating system designers like the guys behind the hugely expensive and failed MULTICs.
Down on the ground we had guys trying to get stuff done. They came up with things like C and UNIX. Smaller, simpler, maybe not so "pure" but they worked, here and now. ALGOL was a disaster becacuse they forgot to standardize input and output, a concern accademics would not imagine to worry about. As a result programms were totally non-portable.
I forget the name of the guy who devised Javascript but he has said a brilliant thing that goes something like this:
"I only had six weeks to design the language, which is just as well, if Ihad longer it would have been worse":)
JS has not changed much since then and is surprisingly powerfull.
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone"
He said that before the smart phone so it is even more true today!
I also like the two kids of computer languages, those people complain about, and those no one uses.
So far, everything seems to point to learning C for the Propeller before bothering with C++.
Thankfully, there is a lot of good material for learning C. The "two kids of computer languages"? I guess you mean the two kinds.
C is great. After studying a bit of Assembly language and LEX and YACC, I can even envision how it was created in a compiler. The fact that it is that close to the fundamentals is very appealing to me.
There are some things in it that are a bit tricky - like the fact that a Statement is ended with a semicolon or surrounded by braces (two options, so the user has to remember the alternatives) or an IF can be alternatively created with just a question mark.
But it seems all too the good. The ANSI C manual is relatively easy and enjoyable to read.
I am reading a bit about C++, but not really motivated to immerse myself in its world.
You are on the right track. Given that C is a subset of C++ you are not wasting any time by ignoring the C++ features for now and it will save you a lot of confusion.
Personally I never use the "?" thing. I think it's ugly and unnecessary, one of those things that should have been removed from C++.
Don't be confused by curly braces and semicolons, they are different things. I like to use braces around all conditional an loop blocks even if there is only a single statement in there. Like so:
if (a == b)
{
doSomething();
}
else
{
doSomethingElse();
}
In the above the braces are optional but I like the consitancy of always using them and it saves messing about if you decide to add a second statement to a block like that.
In the above the braces are optional but I like the consitancy of always using them and it saves messing about if you decide to add a second statement to a block like that.
I do the same, and it's even in the coding standards at work. One reason (in addition to your point) is that always using the braces makes it a piece of cake to quickly write a script to parse the code, due to its symmetry. I wrote a static analyzer in Perl in thirty minutes (or less, it's been a while but it was quick). It would have been much more hassle if I had to consider missing braces (and yes our coding standard also uses that brace-on-its-own-line, instead of the more common first-brace-at-end-of-line, and this also makes it quicker to throw together a script to parse the code for some purpose).
I do the same, and it's even in the coding standards at work. One reason (in addition to your point) is that always using the braces makes it a piece of cake to quickly write a script to parse the code, due to its symmetry. I wrote a static analyzer in Perl in thirty minutes (or less, it's been a while but it was quick). It would have been much more hassle if I had to consider missing braces (and yes our coding standard also uses that brace-on-its-own-line, instead of the more common first-brace-at-end-of-line, and this also makes it quicker to throw together a script to parse the code for some purpose).
-Tor
Various coding styles are listed here. My personal style is quite close to the original "K&R" style (with the addition that I always use braces, even if they are optional - and for the same reasons as Heater mentioned).
However, feel free to use whatever style you want - just be sure to choose a contect sensitive code editor (like vim) that highlights the corresponding brace and auto aligns them for you. That way, you can never go wrong.
...choose a context sensitive code editor (like vim)
Ross don't do that, loopy is probably having enough of a challenge getting to C with out needing to have to struggle with Vim at the same time:)
Many other editors will do what you want.
(Aside: Using Vim makes it impossible to use any other editor after a while. I have a terrible problem with ":wq" showing up in files if I try.)
(Aside: Using Vim makes it impossible to use any other editor after a while. I have a terrible problem with ":wq" showing up in files if I try.)
Yes, I know exactly what you mean. Vim is possibly the best programming productivity enhancer I've ever discovered - but it certainly "spoils" you for many other tools. I have one editing tool that interprets ESC as a request to immediately exit the program, even if you're in the middle of some complex operation. Despite it being a very useful tool, I've had to give up using it - my wife complained about all the cursing!
To continue my ramblings about languages said to be derived from C and whilst loopy is thinking about curly brackets. Here is some code that looks very similar in C and JavaScript but behaves very differently:
int a = 1;
printf ("a = %d\n", a);
{
int a = 2;
printf ("a = %d\n", a);
}
printf ("a = %d\n", a);
var a = 1;
console.log("a = " + a);
{
var a = 2;
console.log("a = " + a);
}
console.log("a = " + a);
Can you guess what is output in each case?
Those curly brackets have a totally different meaning in C than JS.
Actually with a bit of work we could get that JS snippet to compile in C++. Just define a console class with a log method, and a var class with operator overloads for assignment and adding to strings. However it will produce a different result than JS and I don't see how to get around the braces/scope difference.
OK I could not resist this exercise , despite it being pointless, here is a C++ program that #includes the JavaScript example above. It compiles without error. Gives different result than when the included JS is run as JS. So same syntax way different meaning.
(Warning: This is very horrible C++)
#include <iostream>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
using namespace std;
class var
{
public:
// Constructor
var()
{
data = 0;
}
// Assignent operator, puts an int into the Var
var& operator= (const int x)
{
data = x;
return (*this);
}
// The Vars data
int data;
};
// Overload binary addition of char* and Var
inline char* operator+(const char* lhs, const var& rhs)
{
// Oops memory leak !!
char* res = (char*)malloc (strlen(lhs) + 100);
sprintf (res, "%s%d", lhs, rhs.data);
return (res);
}
// Provide a JS like console output
class Console
{
public:
void log(char* s)
{
cout << s << "\n";
}
};
Console console;
int main (int argc, char* argv[])
{
// Yes we are going to compile JavaScript into here
#include "scope.js"
return (0);
}
Please elaborate. I have my own ideas about that, what are yours?
Hmmm ... so many possibilites ... where to start?
I guess my main gripe is that both seem to be "write only" languages. By that I mean it is difficult to interpret the meaning of a piece of code without a comprehensive understanding of the context it appears in. Of course, you can write impenetrable programs in C (the obfuscated C competition is a classic!) - but the difference is that in C you have to work at obfuscating it. With C++ it just happens.
I can't imagine how anyone can maintain a large C++ code base, and my limited reading about JavaScript (not a language I'm overly familiar with) seems to indicate it suffers from similar problems - albeit for slightly different reasons. To hearken back to that Linus Torvalds quote - only a person who knew they wouldn't have to maintain a software system consisting of hundreds of thousands of lines of code would ever contemplate using C++ or JavaScript to develop one. The code base quickly becomes just layer after layer of pointless abstractions with poor underlying implementations. Some of this arises from the sheer impenetrability of any existing code base, and some arises from the impossibility of ever recovering from any initial poor design decisions.
I know you at a loss as to where to start but by question was in the context of that particular example, both C++ and JS.
What specific details are "deeply flawed" in such a short pieces of code?
Luckily it's not often you are going to want to write hundreds of thousands of lines of JS. What with it taking time to load into your browser and then runs like a snail.
Oh, wait a minute, I have just been toying with node.js which runs JS server side like any other scripting language, that could get out of hand. And then there is the wonderful QML from the Qt guys. QML builds user interfaces with JS and Qt libs so you can have the best of C++ and JS at the same time!
Are you having nightmares yet?
P.S. Strangely my node.js implementation (interpreted) of some server functionality loads the CPU less than my C++ implementation (native code). Which either says something bad about my C++ or something good about node.js....
Well, I had already discovered vim with the switch to Linux and am quite aware as how obscure some of these original Unix/Linux text editors are. Generally I use nano as vim just wastes the day in reading documentation to clean up the mess that it created. Also there is now gedit.
Unmaintainable 'write only' languages are a real issue in today's world. I suspect any for profit OS that has personel turnover suffers from this problem. But these are the people that love to upgrade and revise computer lanaguages. So the irony is they punish themselves.
I got started with BasicStamps back in 2004 as a relative latecomer and PBasic seemed far more appropriate for learning at the time than what others were beginning to tout as OOP. Ever since I have been rather wary of OOP.
Some of that may come from my graduate studies in teaching English as a 2nd language. I found everyone could generate an awful pile of jargon and concept, but not really nail down what language and linguistics were in concise way.
In some ways, it is nice to have objects that eliminate building something. But I am more comfortable with the idea of libraries of functions. The overlay of everything must have a Class is still daunting to me.
Humans tend to create meta-languages that seem to become more and more obscure; but with the objective of concisely controlling a machine (meaning the computer), an open-ended solution is likely to be useless. At some point, all languages are useful because they assist in tasks. If not, it is all rather like having a madman babbling in your ear.
Still, I am surprised that Linux now accepts C++ as its GCC language. Either C++ improved greatly in recent years or Linus Torvalds has let the issue slide.
Loopy.
Personally I never use the "?" thing. I think it's ugly and unnecessary, one of those things that should have been removed from C++.
I'm a tertiary operator addict! To the point that at least one of my co-workers has said I need an intervention. But it comes in really handy if you want to convert a boolean expression to another data type and return the value. Here's a trivial example:
int aBoolean;
// aBoolean is set to some value.
printf("aBoolean = %s", aBoolean ? "True", "False");
More complex expressions can be used, but the idea is you want to return a value based upon a Boolean expression.
I am surprised that Linux now accepts C++ as its GCC language
No, that is not what has happened.
Linux is an OS kernel who's development lead is Linus Torvalds. It is written in C and as long as Linus is in control there will not be any C++ in it.
GCC is a compiler originally started by Richard Stallman many years before Linux came on to the scene. It is also written in C.
Of course C++ is used for many programs that are part of a Linux based OS like RedHat or Ubuntu. For example the desktop environment KDE.
The recent development was that the GCC team decided it was time to use C++ to write or rewrite parts of the compiler collection.
I know you at a loss as to where to start but by question was in the context of that particular example, both C++ and JS.
What specific details are "deeply flawed" in such a short pieces of code?
I think you said it succinctly enough:
(Warning: This is very horrible C++)
My point is that there is really no such thing as readable C++ - we all just seem to accept "horrible C++" as normal. I believe JavaScript is similar, but I have less direct experience of this language.
I loved that (alleged) quote from Bjarne Stroustrup: "Within C++, there is a much smaller and cleaner language struggling to get out". Yes there certainly is - it's called C - and you $#@^&* it up! :frown:
Ross.
Comments
I have read an re-read your post about an implementation of BASIC emmbedded within an application but I'm not convinced that it is a problem with C++ or just a crappy implementation of a BASIC interpreter. What you have described could as easily been messed up in C or any language.
Reading the linked Torvald's quote I get the idea he was talking more about the quality of programmers than the language itself.
Still, I remember many years ago their was an effort to use C++ in the Linux kernel and it did not go so well. Not surprising because at the time I had code that would compile with some compilers but cause GCC to crash!
A few years ago, I was assigned a couple of young guys to help out with a project after management decided it was too much for just me. They natuarally wanted to use C++. I tried very hard to dictate that they will only use as many C++ features as makes sense on a small embedded system. As it happened they were working in Stockholm and I was far away in Helsinki so they could do a lot of damage whilst I was not looking. Sure enough the project was full of every possible feature of C++. They finished their contract time and I had to spend an age cleaning up all the memory leaks:) The whole shebang has been now scrapped as unmaintainable. Luckilly I stopped working there a while ago.
C++ was a good idea. Only they should have quit the desire for it to be 100% backwards compatible with C. And somewhere along the line the whole language standard has got out of control.
For example:
Why keep forever the idea that 033 is an octal number?
Why do we need header files in which we repeat the same stuff as written in the C code?
Why do we need to continue to support the macro preprocessor when declaring constants and inline functions can do the same?
Yes you say what about "#ifdef BLABLA, well a normal "if" would do. If BLABLA is assigned but never changes the compiler can remove the appropriate code.
C has a lot of baggage that is practical, like the preprocessor, and designed to enable building programs on small systems but is basically a hinderence to just writing your idea in code. C++ has even more.
As for translating closures-programming in e.g. Javascript to C I wouldn't even try that, you'll have to approach the problem from another angle. Which is what C programmers have done for a long time.
Not directly related, but it's not that difficult to program in an 'object' oriented way in pure C. The Linux driver model (and most Unix driver models) are done that way, and it's clean enough.
BTW there's a language called 'Vala', it's very C# like but compiles to pure C. It's got all the usual object oriented features. It's possible to compile to executable code, or to the intermediate C code which can then be compiled (even on another platform) by a C compiler. It's probably not that useful in a Propeller context because it's really designed to handle the GNOME GObject model. So it's very easy to program GTK+ applications. But it's also possible to use for non-GTK applications. Here's how it compares to C#: https://live.gnome.org/Vala/ValaForCSharpProgrammers. Just to show that other people are also trying to avoid C++
-Tor
What Linus said is very clear to practical C programmers. This is the reason I talked about rope before.
People need proper guidance, and unfortunately education without practical industry experience does not give it. If educators can highlight practical things (rather than everything in a language just because it is there) the rope becomes a paint-brush. The folks in Parallax are very aware of the need for the paint-brush (think SPIN). Too bad that someone beat them to C++ version of it and took away so much market share (loathing C is the reason this happened IMHO).
Yes, I know what "static" does. Still you cannot make the parameters of a function static in C.
In C parameters are pushed to the stack, the function is called and then the fuctions finds it's parameters on the stack. Same as it does non-staic local variables.
If it were allowed to make parameters static that would imply that they are written to some fixed memory location, the function is called, and the function finds them there. Those memory slots would not be available to anyone but the caller and the called. Kind of pointless in C, except that a function could return a pointer to a parameter that lives on after it has returend.
Threads, oh yeah that will make things really iteresting. There is a difference between "instances" and "threads". We can or could have the former without the latter.
Yes, it's easy(ish) to program in C in an object oriented way. As we know early C++ compilers were just preprocessors to C that hid all the messy details like instance pointers from your source code.
Traditionally there was not much computing going on but a lot of computer science in accademia and such.
Those big time computer science thinkers came up with such things as ALGOL and Pascal and Ada where correctness and algorimic expression was the main thrust. In this collection we can put operating system designers like the guys behind the hugely expensive and failed MULTICs.
Down on the ground we had guys trying to get stuff done. They came up with things like C and UNIX. Smaller, simpler, maybe not so "pure" but they worked, here and now. ALGOL was a disaster becacuse they forgot to standardize input and output, a concern accademics would not imagine to worry about. As a result programms were totally non-portable.
I forget the name of the guy who devised Javascript but he has said a brilliant thing that goes something like this:
"I only had six weeks to design the language, which is just as well, if Ihad longer it would have been worse":)
JS has not changed much since then and is surprisingly powerfull.
Bjarne finally admits that the whole C++ project is totally out of control an totally bol****ed up.
And why would anyone ever be proud to be a MICROSOFT Windows user?
Close as we will ever get: http://www.stroustrup.com/bs_faq.html#really-say-that
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone"
He said that before the smart phone so it is even more true today!
I also like the two kids of computer languages, those people complain about, and those no one uses.
Thankfully, there is a lot of good material for learning C. The "two kids of computer languages"? I guess you mean the two kinds.
C is great. After studying a bit of Assembly language and LEX and YACC, I can even envision how it was created in a compiler. The fact that it is that close to the fundamentals is very appealing to me.
There are some things in it that are a bit tricky - like the fact that a Statement is ended with a semicolon or surrounded by braces (two options, so the user has to remember the alternatives) or an IF can be alternatively created with just a question mark.
But it seems all too the good. The ANSI C manual is relatively easy and enjoyable to read.
I am reading a bit about C++, but not really motivated to immerse myself in its world.
You are on the right track. Given that C is a subset of C++ you are not wasting any time by ignoring the C++ features for now and it will save you a lot of confusion.
Personally I never use the "?" thing. I think it's ugly and unnecessary, one of those things that should have been removed from C++.
Don't be confused by curly braces and semicolons, they are different things. I like to use braces around all conditional an loop blocks even if there is only a single statement in there. Like so:
if (a == b) { doSomething(); } else { doSomethingElse(); }In the above the braces are optional but I like the consitancy of always using them and it saves messing about if you decide to add a second statement to a block like that.
-Tor
Various coding styles are listed here. My personal style is quite close to the original "K&R" style (with the addition that I always use braces, even if they are optional - and for the same reasons as Heater mentioned).
However, feel free to use whatever style you want - just be sure to choose a contect sensitive code editor (like vim) that highlights the corresponding brace and auto aligns them for you. That way, you can never go wrong.
Ross.
Ross don't do that, loopy is probably having enough of a challenge getting to C with out needing to have to struggle with Vim at the same time:)
Many other editors will do what you want.
(Aside: Using Vim makes it impossible to use any other editor after a while. I have a terrible problem with ":wq" showing up in files if I try.)
Yes, I know exactly what you mean. Vim is possibly the best programming productivity enhancer I've ever discovered - but it certainly "spoils" you for many other tools. I have one editing tool that interprets ESC as a request to immediately exit the program, even if you're in the middle of some complex operation. Despite it being a very useful tool, I've had to give up using it - my wife complained about all the cursing!
int a = 1; printf ("a = %d\n", a); { int a = 2; printf ("a = %d\n", a); } printf ("a = %d\n", a);var a = 1; console.log("a = " + a); { var a = 2; console.log("a = " + a); } console.log("a = " + a);Can you guess what is output in each case?
Those curly brackets have a totally different meaning in C than JS.
Actually with a bit of work we could get that JS snippet to compile in C++. Just define a console class with a log method, and a var class with operator overloads for assignment and adding to strings. However it will produce a different result than JS and I don't see how to get around the braces/scope difference.
(Warning: This is very horrible C++)
#include <iostream> #include <stdlib.h> #include <string.h> #include <stdio.h> using namespace std; class var { public: // Constructor var() { data = 0; } // Assignent operator, puts an int into the Var var& operator= (const int x) { data = x; return (*this); } // The Vars data int data; }; // Overload binary addition of char* and Var inline char* operator+(const char* lhs, const var& rhs) { // Oops memory leak !! char* res = (char*)malloc (strlen(lhs) + 100); sprintf (res, "%s%d", lhs, rhs.data); return (res); } // Provide a JS like console output class Console { public: void log(char* s) { cout << s << "\n"; } }; Console console; int main (int argc, char* argv[]) { // Yes we are going to compile JavaScript into here #include "scope.js" return (0); }That concludes this ramble:)
And you have the temerity to accuse me of confusing Loopy by mentioning vim???
However, what your example does neatly illustrate is that both JavaScript and C++ are deeply flawed languages.
Ross.
Please elaborate. I have my own ideas about that, what are yours?
Hmmm ... so many possibilites ... where to start?
I guess my main gripe is that both seem to be "write only" languages. By that I mean it is difficult to interpret the meaning of a piece of code without a comprehensive understanding of the context it appears in. Of course, you can write impenetrable programs in C (the obfuscated C competition is a classic!) - but the difference is that in C you have to work at obfuscating it. With C++ it just happens.
I can't imagine how anyone can maintain a large C++ code base, and my limited reading about JavaScript (not a language I'm overly familiar with) seems to indicate it suffers from similar problems - albeit for slightly different reasons. To hearken back to that Linus Torvalds quote - only a person who knew they wouldn't have to maintain a software system consisting of hundreds of thousands of lines of code would ever contemplate using C++ or JavaScript to develop one. The code base quickly becomes just layer after layer of pointless abstractions with poor underlying implementations. Some of this arises from the sheer impenetrability of any existing code base, and some arises from the impossibility of ever recovering from any initial poor design decisions.
Ross.
I know you at a loss as to where to start but by question was in the context of that particular example, both C++ and JS.
What specific details are "deeply flawed" in such a short pieces of code?
Luckily it's not often you are going to want to write hundreds of thousands of lines of JS. What with it taking time to load into your browser and then runs like a snail.
Oh, wait a minute, I have just been toying with node.js which runs JS server side like any other scripting language, that could get out of hand. And then there is the wonderful QML from the Qt guys. QML builds user interfaces with JS and Qt libs so you can have the best of C++ and JS at the same time!
Are you having nightmares yet?
P.S. Strangely my node.js implementation (interpreted) of some server functionality loads the CPU less than my C++ implementation (native code). Which either says something bad about my C++ or something good about node.js....
Unmaintainable 'write only' languages are a real issue in today's world. I suspect any for profit OS that has personel turnover suffers from this problem. But these are the people that love to upgrade and revise computer lanaguages. So the irony is they punish themselves.
I got started with BasicStamps back in 2004 as a relative latecomer and PBasic seemed far more appropriate for learning at the time than what others were beginning to tout as OOP. Ever since I have been rather wary of OOP.
Some of that may come from my graduate studies in teaching English as a 2nd language. I found everyone could generate an awful pile of jargon and concept, but not really nail down what language and linguistics were in concise way.
In some ways, it is nice to have objects that eliminate building something. But I am more comfortable with the idea of libraries of functions. The overlay of everything must have a Class is still daunting to me.
Humans tend to create meta-languages that seem to become more and more obscure; but with the objective of concisely controlling a machine (meaning the computer), an open-ended solution is likely to be useless. At some point, all languages are useful because they assist in tasks. If not, it is all rather like having a madman babbling in your ear.
Still, I am surprised that Linux now accepts C++ as its GCC language. Either C++ improved greatly in recent years or Linus Torvalds has let the issue slide.
I'm a tertiary operator addict! To the point that at least one of my co-workers has said I need an intervention. But it comes in really handy if you want to convert a boolean expression to another data type and return the value. Here's a trivial example:
int aBoolean; // aBoolean is set to some value. printf("aBoolean = %s", aBoolean ? "True", "False");More complex expressions can be used, but the idea is you want to return a value based upon a Boolean expression.
No, that is not what has happened.
Linux is an OS kernel who's development lead is Linus Torvalds. It is written in C and as long as Linus is in control there will not be any C++ in it.
GCC is a compiler originally started by Richard Stallman many years before Linux came on to the scene. It is also written in C.
Of course C++ is used for many programs that are part of a Linux based OS like RedHat or Ubuntu. For example the desktop environment KDE.
The recent development was that the GCC team decided it was time to use C++ to write or rewrite parts of the compiler collection.
How well that is going to go we shall see...
I think you said it succinctly enough:
My point is that there is really no such thing as readable C++ - we all just seem to accept "horrible C++" as normal. I believe JavaScript is similar, but I have less direct experience of this language.
I loved that (alleged) quote from Bjarne Stroustrup: "Within C++, there is a much smaller and cleaner language struggling to get out". Yes there certainly is - it's called C - and you $#@^&* it up! :frown:
Ross.