Makes you wonder if the whole Oracle patent shitstorm around Java is making Google reconsider its reliance on that technology. If so, would be interesting to see what they bring forth instead.
Go is an interesting language, but there hasn't been much effort from Google to provide adequate tooling for it so far (IDE, debugging etc). Also, its lack of generics in this day and age is quite surprising - even Java had those.
Java is a "byzantine language", really? You must be a C coder if you seriously think so.
I'd say Linus Torvalds described this well enough.
KISS.
Keep it Simple and Slow? ~
Well, we're talking about Java vs C...
Seriously, there's a bad trend among some "modern" languages of piling up constructs without regards for efficiency, simplicity or sanity. For example, you can write a non-optimized compiler for languages I'd call sane in a week while for some a team in five years can't be expected to fully implement the standard. There is not a single compliant compiler of C++, and for Java it's only because of a skewed definition of "compliant" Sun has. And if you can't write a compiler reliably, how can you program in it?
The language with best balance between simplicity and featuritis I know is LPC. It has things sorely missing in C, like strings (something that C++ scrrewed in epic ways...), refcounted structures (arrays, mappings), closures, rudimentary OOP.
I did not get to learn golang yet, but it looks promising. I do have a bit of beef with some details, but nothing that'd make me vomit.
Seriously, there's a bad trend among some "modern" languages of piling up constructs without regards for efficiency, simplicity or sanity.
You have a point with respect to C++, though I think that's precisely what makes it invaluable for certain tasks - sometimes you do have a team that knows what they're doing, and they can do it so much better with that pile of features.
But what about generics that makes you lump them into the same category? Efficiency? - but C++ std::sort will beat qsort any day precisely because all polymorphism there is compile-time, and can be fully optimized. Simplicity? Granted, C++ templates are very complicated, but
This is C++, not C, but you can always choose to use a "better C" subset of C++ features that suits you, many people do. I've used this trick for locking/unlocking mutexes (_very_ handy for that) and freeing memory too.
Except that you still pay the full price for using C++:
You now require a C++ compiler, not just a C compiler.
You cannot use C static-analysis tools.
You have to worry about 'extern "c"' if you want to work with C code.
Not saying it's necessarily a terrible idea, but you pay a price for using C++ as a better C.
I know how to do this with C++. The original discussion was explicitly about C, however. Note however that your code is extremely verbose - you have to write a wrapper type with destructor. Scope guards are something much simpler in intent.
Another thing I'd kill for in C is a limited form of RAII, namely scope guards - the ability to say at any given point, "when the scope ends, run this before leaving it"
If you are willing to limit yourself to GCC-compatible compilers (GCC, clang, ICC, Path64, and - I think - XLC), then you should look up __attribute__((cleanup)). I use this for locks in C all the time. I just have a LOCK_FOR_SCOPE() macro, and the lock is automatically released when it goes out of scope. It's even exception safe if you compile with -fexceptions, so if some C++ or Objective-C throws an exception through your stack frame, it works nicely.
Yes, I know about __attribute((cleanup)). I think it has some design deficiency - notably, it always applies to a single variable, it requires having a cleanup function (no inline code), and it has strict requirements for the signature of that function. For example, you cannot use it directly with fclose() when you need to clean up a FILE*, because it expects the cleanup function to accept FILE** (i.e. it always adds an extra level of indirection, even where it is undesired). Similarly, you can't use it dir
Seriously, there's a bad trend among some "modern" languages of piling up constructs without regards for efficiency, simplicity or sanity.
It's not so much the languages, but the standard libraries. I've spent a lot of time writing performance optimised code (3D engines, large database-type apps, etc...), and the thing that shits me is this:
foreach( x in list_of_x ) { foo( x ); }
where 'foo' does something like:
prep();
work_on( x );
cleanup();
That is bad, especially if 'work_on(x)' has a couple of layers of the same kind of thing -- then there's virtually no hope of the compiler ever optimising that loop in any sig
Seriously, there's a bad trend among some "modern" languages of piling up constructs without regards for efficiency, simplicity or sanity. For example, you can write a non-optimized compiler for languages I'd call sane in a week while for some a team in five years can't be expected to fully implement the standard. There is not a single compliant compiler of C++ [...]
That argument worked in 1999, but not today. Both GCC and Microsoft have had reliable, compliant C++ compilers for many years now.
And frankly I don't care if it takes *twenty* years to write a new C++ compiler, when gcc exists, is free, and is the first piece of software ported to any new CPU architecture.
"A mind is a terrible thing to have leaking out your ears."
-- The League of Sadistic Telepaths
Oracle? (Score:5, Interesting)
Makes you wonder if the whole Oracle patent shitstorm around Java is making Google reconsider its reliance on that technology. If so, would be interesting to see what they bring forth instead.
Re: (Score:2)
Re: (Score:2)
Go is an interesting language, but there hasn't been much effort from Google to provide adequate tooling for it so far (IDE, debugging etc). Also, its lack of generics in this day and age is quite surprising - even Java had those.
Re: (Score:2)
Add more and more junk like generics and you'll end with languages as byzantine as C++ or Java.
KISS.
Re: (Score:3)
Add more and more junk like generics and you'll end with languages as byzantine as C++ or Java.
Java is a "byzantine language", really? You must be a C coder if you seriously think so.
KISS.
Keep it Simple and Slow? ~
Re:Oracle? (Score:3, Informative)
Java is a "byzantine language", really? You must be a C coder if you seriously think so.
I'd say Linus Torvalds described this well enough.
KISS.
Keep it Simple and Slow? ~
Well, we're talking about Java vs C...
Seriously, there's a bad trend among some "modern" languages of piling up constructs without regards for efficiency, simplicity or sanity. For example, you can write a non-optimized compiler for languages I'd call sane in a week while for some a team in five years can't be expected to fully implement the standard. There is not a single compliant compiler of C++, and for Java it's only because of a skewed definition of "compliant" Sun has. And if you can't write a compiler reliably, how can you program in it?
The language with best balance between simplicity and featuritis I know is LPC. It has things sorely missing in C, like strings (something that C++ scrrewed in epic ways...), refcounted structures (arrays, mappings), closures, rudimentary OOP.
I did not get to learn golang yet, but it looks promising. I do have a bit of beef with some details, but nothing that'd make me vomit.
Re: (Score:3)
Seriously, there's a bad trend among some "modern" languages of piling up constructs without regards for efficiency, simplicity or sanity.
You have a point with respect to C++, though I think that's precisely what makes it invaluable for certain tasks - sometimes you do have a team that knows what they're doing, and they can do it so much better with that pile of features.
But what about generics that makes you lump them into the same category? Efficiency? - but C++ std::sort will beat qsort any day precisely because all polymorphism there is compile-time, and can be fully optimized. Simplicity? Granted, C++ templates are very complicated, but
Re: (Score:1)
This is C++, not C, but you can always choose to use a "better C" subset of C++ features that suits you, many people do. I've used this trick for locking/unlocking mutexes (_very_ handy for that) and freeing memory too.
Except that you still pay the full price for using C++:
Not saying it's necessarily a terrible idea, but you pay a price for using C++ as a better C.
Re: (Score:2)
I know how to do this with C++. The original discussion was explicitly about C, however. Note however that your code is extremely verbose - you have to write a wrapper type with destructor. Scope guards are something much simpler in intent.
Re: (Score:3)
Another thing I'd kill for in C is a limited form of RAII, namely scope guards - the ability to say at any given point, "when the scope ends, run this before leaving it"
If you are willing to limit yourself to GCC-compatible compilers (GCC, clang, ICC, Path64, and - I think - XLC), then you should look up __attribute__((cleanup)). I use this for locks in C all the time. I just have a LOCK_FOR_SCOPE() macro, and the lock is automatically released when it goes out of scope. It's even exception safe if you compile with -fexceptions, so if some C++ or Objective-C throws an exception through your stack frame, it works nicely.
Re: (Score:2)
Yes, I know about __attribute((cleanup)). I think it has some design deficiency - notably, it always applies to a single variable, it requires having a cleanup function (no inline code), and it has strict requirements for the signature of that function. For example, you cannot use it directly with fclose() when you need to clean up a FILE*, because it expects the cleanup function to accept FILE** (i.e. it always adds an extra level of indirection, even where it is undesired). Similarly, you can't use it dir
Re: (Score:3)
Seriously, there's a bad trend among some "modern" languages of piling up constructs without regards for efficiency, simplicity or sanity.
It's not so much the languages, but the standard libraries. I've spent a lot of time writing performance optimised code (3D engines, large database-type apps, etc...), and the thing that shits me is this:
foreach( x in list_of_x ) { foo( x ); }
where 'foo' does something like:
prep();
work_on( x );
cleanup();
That is bad, especially if 'work_on(x)' has a couple of layers of the same kind of thing -- then there's virtually no hope of the compiler ever optimising that loop in any sig
Re: (Score:2)
There are fully conforming C++ compilers.
Re: (Score:2)
Re: (Score:2)
C++0x is not a published standard yet.
C++, in that context, refers to C++03.
Re: (Score:2)
Re: (Score:2)
Comeau, for example.
Re: (Score:2)
Thanks, didn't know that.
Re: (Score:2)
Seriously, there's a bad trend among some "modern" languages of piling up constructs without regards for efficiency, simplicity or sanity. For example, you can write a non-optimized compiler for languages I'd call sane in a week while for some a team in five years can't be expected to fully implement the standard. There is not a single compliant compiler of C++ [...]
That argument worked in 1999, but not today. Both GCC and Microsoft have had reliable, compliant C++ compilers for many years now. And frankly I don't care if it takes *twenty* years to write a new C++ compiler, when gcc exists, is free, and is the first piece of software ported to any new CPU architecture.