Can you give examples -- specifically examples where Java can do it but declarative langauges can't (or can't easily)?
Try writing some real time instrument control software in a declarative language.:-)
Not saying it can't be done, or even potentially be done well, but I know of no declarative language that provides even close to the same level of control over sequences of events, and synchronisation between parallel sequences, as would be routine in a typical procedural or OO program.
(Apparently some such languages do actually exist. Another poster referred me to two quite old language families I hadn't previously encountered, and I'll look into them when time allows. Certainly none of the mainstream variations of things like ML, Haskell or LISP are up to the job as far as I've seen, though.)
I question whether you have actually tested any of this theory.
I work on computationally intensive software that gets built on more than a dozen platforms, including pretty much everything you mentioned. Having examined the assembly output for several of these on numerous occasions, I can promise you that most reasonably modern C++ compilers will optimise away those temporaries, allocate stack space en masse at function entry just as C usually does, inline or completely remove construction/destruction code that serves no useful purpose, and otherwise get rid of the various types of unnecessary overhead you seem to think are inescapable. You seem to write as if C++ optimisers still worked the way they did a decade ago.
If you prefer C to C++ for its simplicity and elegance, by all means say so. It's a perfectly reasonable position to take. But let's not start making claims about C++ that are demonstrably untrue, OK?
I have no idea what the heck you're talking about. The seperation of header files and source files?
That's a part of it, yes. You have various common situations, just looking at classes as an example.
Every time you have a method in a class, you have to specify it in full in the interface, and then again in the implementation. Except that the names of the parameters can be omitted in the interface (although header files can make good documentation, so they're often reproduced anyway) and default parameters must be specified in the interface (though they, or at least a note of their existence, are commonly added as comments in the implementation as well). There is no need to have two independent copies of all of this information; it's perfectly possible to have a development environment where you spec the interface, and then the code behind each function, without the duplication.
Similarly, every time you override a base class method, you must specify the whole thing again in the derived class interface, and yet again in the derived class implementation. Again, there's no reason you couldn't have a development environment which worked everything off the single base class interface specification, plus the knowledge that both base and derived class provide an implementation. Don't even mention hiding base class members in a derived class, using declarations to bring them back into scope, and other such irritations.
Another common one is static data members, which in C++ must be declared (and under some circumstances can even be initialised) in the class declaration, but must then be defined in a single translation unit as well.
All of these things are just needless redundancy in the source code, created by the structure of C++, adding no value yet multiplying up the time taken to code things, and worse, multiplying up the time taken to change your mind later. With a system where interfaces are well managed and everything else depends cleanly upon them, it is easy to make changes. With a system where your interface spec is needlessly repeated every time someone implements part of it, or some other interface borrows from it, you just create needless dependencies between different areas of the code, which then need to be kept in sync, wasting time and risking errors.
And yes, there are development tools available today that can help with this, but I stand by my points that (a) most of them aren't that great anyway, and (b) they should be far more universal than they are.
So instead of a development environment where basic refactoring of classes, functions, etc. is done with a couple of mouseclicks or a keyboard shortcut, we have a model where we manually and laboriously trawl through dozens of different source files just to rename a member function whose purpose has subtly changed, or to extract a block from an inner loop and make it into a separate function. These processes have cost but offer no benefit, and thus, they suck.
He's talking about wasted overhead of creating temporary objects on the stack, and this is actually a valid complaint. You don't need the overhead of object creation when you're making an integer.
And creating an integer temporary typically entails zero overhead. WTP?
But why most of programmers are ok with destructive assignment? Variable value is a part of the (run-time) program code, it should not be modified - only created.
I'm all for a more declarative programming style where it's appropriate, but some data structures and algorithms are simply much more efficient if you change them in-place.
#include <std_iteration_vs_recursion_arguments.h>
Interestingly, while mathematically educated programmers do already (how many decades) know that the future is for FP...
Lots of pretentious academics who like to think they're clever because it justifies their existence will tell the journeyman programmers of the world that the tools they use suck, functional programming is technically superior, etc. But while theory is all very well if you live in an ivory tower, in the real world, we have to write the code that gets the job done.
If functional programming and such were so much better than procedural, OO, etc. in practice then the professional development industry would be using them as a matter of routine. As it stands, there are at least two very good reasons this is not the case: FP doesn't have critical mass (small installed base, small code base of libraries, limited number of programmers familiar with it) and the FP model has its own problems, which don't much show up in theory labs (hence most academics' ignorance of them, or willingness to overlook them) but bite you in seconds in the real world (hence many informed and highly mathematically educated programmers still reject FP for their work).
OO thinkers have focused so heavily on hiding implementation and implementation changes that they have lost sight of factoring, simplifying, and managing the changes in *interfaces* also.
I don't believe it... I actually agree with Tablizer.:o)
Many OO languages, including pretty much all of the major ones, suffer from tedious and repetitive syntax to define the various interfaces in use. For example, if I've got a method in a base class and I want to override it in a derived class, there is typically some significant redundancy.
I think having a separate definition of the interface to a class is useful as a tool for design, as documentation, and as a means of preventing silly errors. It has much the same practical benefits as using a strong typing system. But there is definitely too much pointless repetition in many OO languages.
It would be good for the industry if the development tools we use routinely all supported basic refactoring, browsing of the object model, etc. Even the best tools do a pretty mediocre job of this at present, resulting in countless hours of developer time wasted doing routine things like moving methods up or down a class hierarchy, or splitting a class.
The key is faster execution. [...] C++ wastes too much time in uncontroled and unpredictable memory management functions.
Sorry, but now I'm lost. What part of C++ memory management do you think is not completely deterministic, and at what point do you think C++ needs to generate less efficient output code than C to do the same thing? Sure, C compilers still sometimes optimise better than C++ ones, and some C++ libraries do silly things like adding overhead and then just calling the equivalent underlying C function from the same library, but these are quality of implementation issues, not flaws with the C++ language.
I'm familiar with RT systems and their particular requirements, by the way. Presumably you're not doing a whole lot of dynamic memory allocation, which makes your comments about unpredictable memory management functions even more puzzling. What platform(s) are you developing for, and with what compilers?
There is no silver bullet, no magical solution, no instantaneous makes-my-problem-go-away widget that is all things to all problems.
Of course there is. In fact, a new entry for the JCP to create a class AnythingDoer is being worked on as I write. From J2SE 1.6 onwards, you will be able to write a program to do anything you want as follows.
public class WholeProgram
{
public static void main(String[] args)
{
AnythingDoer omnipotent = new AnthingDoer();
System.exit(omnipotent.doEverythingINeed());
}
}
At that point, functional programmers will be feeling small and insignificant, finally realising the underwhelming lack of power that their tools really don't possess, and the need for any sort of formal training for pogrammers will be resolved once and for all.
For example, if you had no idea how to get/. to indent your sample code sensibly, you could just call that method and it would cause some helpful soul to reply and end months of frustration.:-)
You shouldn't be worrying about what the order of drawing. You should just declare "object a overlaps object b" and "object a doubles in size when the mouse is over it" etc etc.
But the point is that, when you're interacting with the world outside your program, you have to worry about ordering, timing, interfaces and protocols, etc. This side of programming is where most of today's functional languages really fall down, and probably the single biggest reason they haven't been used more for mainstream applications, IMHO.
At the risk of stating the obvious, the ability to do generic programming (in the sense of working with arbitrary interfaces without needing the inheritance/OOP angle to specify that they're met) has been around for decades in many languages.
There's nothing inherently special about generic code. From a certain point of view, the very fact that generic algorithms and data structures are regarded as anything but the obvious default is just indicative of a flaw in the underlying models of languages that need templates etc.
I appreciate your enthusiasm, and generic programming is a fine idea, but if you think things like the STL and expression templates are original, you need to read up on things like functional programming, where vastly more powerful versions of the same concepts are routine. These libraries are very useful tools for languages that don't support the concepts natively, without a doubt, but magical they ain't.
And relationships in the "Real World(tm)" don't necessarily hold in OOD, either. For instance, in mathematics, a square is a kind of rectangle.
The problem, of course, is that in their urge to hype the new toy, OO evangelists coined the term "is a" when it's not really an appropriate (or rather, complete) description of the concept.
Could you give an example of the sort of simple usage you're imagining? I can't think of much off the top of my head where you'd use an OOP feature in C++ but it would be faster to implement an equivalent manually in C, but maybe I'm missing something...
I realise the point he was trying to make, but unfortunately he's still wrong. C++ is designed with efficiency in mind, and in practice you will get identical or better output code using C++ features to model inheritance etc. than you would get by doing it manually in C. The guys writing the C++ compiler can do all the same tricks you can in C, and they can optimise at a lower level as well.
The "overhead" in using C++ OO features is almost entirely mythical, and has been for years.
I can do quite competent and very efficient OO coding in C and implement all OO's sacred features without the mindless under-the-hood overhead of C++ et. al.
Most drink-drivers think they're fine at the time. An impartial observer, objectively comparing their performance to a sober driver, would disagree.
What on earth makes you think you can implement the OO features of C++ manually in C, and do so better than those writing a C++ compiler who have resources to invest in optimising the way they are implemented?
The future -- take the best of declarative but...
on
The Post-OOP Paradigm
·
· Score: 1
I really don't think in the commercial world any well designed language is going to be popular.
In the commercial world, theoretically sound languages will become popular if and when the tools, user base and code base reach critical mass. These are the things that make the best practical tools of today (Java, C++, VB, etc.) popular, in spite of their well-known flaws.
I have high hopes for programming by specification, as in functional languages and such, but they, too, have their flaws. In particular, while they're dead neat for modelling calculations that just need to give you the right answer by whatever means necessary, they suck for modelling the concept of interaction with the outside world because they have problems repesenting the flow of time. Unfortunately, the benefits and problems are inherently tied together in a specification approach; the very things that give one also give the other.
What's needed, and my take on the next big thing in programming, is a language (textual or otherwise) that can represent both the flow of time to deal with interactions and pure specifications of the calculations and data manipulation to be done as a result, preferably with both being conceptually independent of the underlying machine. For example, I'd like things like threading and synchronisation to be mostly implicit, and I/O to be defined in terms of sequences of interactions and how they relate, much as in a specification language you can write a complex mathematical expression and only care that you get the right answer, without knowing where the calculation was performed, whether it used multiple threads/processors, etc. Of course, there will always be a certain need to understand the underlying model, just as when doing floating point maths you have to understand basic numerical analysis to avoid nasty surprises.
Some languages are heading in this direction already, but I don't know of any that's close to my ideal goal. When one comes along that reaches a critical mass of interest, the industry will start to change, slowly but surely, to adopt the theoretically superior approach. I'm not sure that language actually exists yet, though, nor what might act as the catalyst to get it to critical mass -- maybe the power of the Internet and enough geeks in senior developer positions taking a liking to the idea when it comes along?
c will have a long life in the embeddedspace. Little chips like the PICs, AVRs, 68H11s, and even the 8051s are programed in c or asm.
But mainstream microprocessors are being used more and more often. Economies of scale mean they often cost a comparable amount these days, and clearly they are easier targets for development.
C++ is just too big for 8k devices.
That's obviously not true, of course. If you can write for it in C, you can write for it in C++. Just don't use the extra features unless you really need them. And if you do really need them, it's probably more efficient to let your compiler do it behind the scenes than to hand-code an equivalent in C, even neglecting the benefits to development time, code maintenance, etc. that would result as well.
Sorry, I can't resist destroying this post point by point.
[C++] doesn't offer anything over a well written C program. If you write two identical programs on the same level as an OS in both C and C++, you'll end up with a lot of lines of code being about the same. Going through the extra trouble (and compilation overhead) involved in C++ isn't worth the bother when 99% of the code is the same.
You don't know much about how to write C++, do you? Sure, for really low level code, a lot of it will be the same. Then for the higher level parts -- which is still most of an OS -- the C++ should be clearer and more concise. If it's 99% the same as the C, you're doing something wrong.
For time critical things, you have to break C++'s object oriented model. This might seem like a part of the first reason but it's really a seperate issue. If you're violating the principles your language requires (and C++ lets you do this), then you haven't gained anything by using that language.
Do you know what the "zero overhead principle" of C++ says? You should read about it before you make such silly claims; try a copy of D&E for a start. Oh, and then try to work out how a language can let you violate the principles it requires. (Of course, C++ doesn't really require you to use OO at all, which is kinda the point.)
C++ isn't as widely used as C, and thus its maintenance will be less crisp. Factually, C++ is the most used programming language there is, but to a first approximation, all of this code is for Windows, and I don't count Windows. Furthermore, Microsoft has demonstrated that they want to move away from C++ to C# (I think this is because they want control over the language their stuff is written in). What's going to happen to C++ when 99% of its userbase just disappears? Windows programming has certainly helped to work out the kinks in C++, but without people pounding on it day in and day out, it won't stand for long.
This just gets better and better.
The installed base of C++ on any major platform you care to name is now estimated to exceed that of C. I speak as someone who writes code that runs on more than a dozen OSes every day, from Windows to MacOS to *nix flavours, and several others besides.
Microsoft might like the idea of people moving to C#, but it's not stupid. It knows that C++ is here to stay, and that the C++ community values support for some standard features that were previously missing from the Visual C++ compiler. The new version has several significant improvements on previous offerings, and Microsoft currently employs several of the biggest names in the C++ world. That doesn't sound like a company abandoning the language, and I speak as someone who is normally very sceptical of any claimed Microsoft position not supported by direct evidence.
C++ needs a change soon. This is also true of C. C is thirty years old, and with a few changes here and there, it's still the most relevant language there is, but it drags a lot of weight behind it. Reentrancy issues were fixed by adding reentrant functions (think strtok and strtok_r). When the next issue comes along, are more functions going to be added as well? Because of backwards compatibility, all of this stuff must continute to be supported. C really needs to be replaced with something that has the same functionality, but that can be written with today's machines in mind and backported to older machines, rather than the other way around. C++ has these same issues ahead of it, but it doesn't have the same niche or hardcore userbase C does.
I just don't know where to start with this. C++ doesn't exactly evolve at the same pace as, say, Java or Python, but whether that's a good thing or a bad thing remains to be seen. How you can claim C has a bigger "hardcore userbase" than C++ is beyond me. I work in fields where these langua
Yes, I understand where the number comes from, but I was just subtracting my daily Calorie intake from the 2,500 recommended for an average guy, and adding up the differences. Apparently, I'm a perfect example of a guy whose build and activity levels correspond to needing exactly 2,500 Calories a day to maintain weight, and furthermore my activities over the period were 100% efficient at burning fat to make up the shortfall. Or maybe I was just lucky in that the differences from these ideal figures cancelled out...:o)
Around new year, I decided I'd got heavier than I'd like. I'm reasonably fit, and a good weight for my height and build, but as a result of an injury I hadn't been doing nearly as much of my physical hobbies as usual, and I'd put on around a stone. So, I decided to try a genuine, honest-to-goodness diet + exercise regime to lose that weight.
For three months, I kept a spreadsheet of everything I ate or drank, with calorie counts, amounts of protein, carbs, fats and fibre, etc. I also kept a record of how much significant exercise I was doing, and my weight, daily.
Curious facts I discovered while researching/doing it...
Consuming around 3,500 Calories less than you would need to maintain your weight is supposed to give around a 1lb loss of weight. In my case, taken over the three months, I was so close to this figure that it was scary.
Cutting out a couple of cans of cola at work (or switching to 1Cal/can diet versions) and watching the amount of cheese and mayo in sandwiches at lunchtime is enough to drop 500 Calories a day. No, really. That's 1lb a week just for that, and I did it for three months while barely noticing the difference in my daily routine.
Exercise matters, but overall, not on a given day. Over a couple of weeks when my injury recurred and I didn't exercise much, I lost weight more slowly, and after a particular week when I did lots of dancing I dropped an extra pound or so, but day-to-day didn't much seem to matter.
If a typical adult male should eat 18g of fibre a day, it's not surprising so many people don't. If you're short, and suffering the inevitable but totally avoidable consequences (IBS, etc.) then try switching to wholemeal bread, eating a high fibre cereal for breakfast, and going for more high fibre fruit and veg in your diet; apples, potatoes, etc. are good.
It's actually surprisingly hard to fit 5+ portions of fruit and veg into your daily diet consistently. Most days I hit 3-4: a piece or two of fruit, some vegetable dish with dinner, a glass of orange juice at lunch, and that was about it. (Sure, there was salad on my lunchtime sandwich and my breakfast cereal had a little fruit in it, but nothing worth one of your five portions.) However, after making an effort to improve this area of my diet for a week, I did feel noticeably better. Dunno whether it was just pure psych or whether I really had a deficiency in some vitamin or mineral, but the latter seems quite plausible. And of course, fruit and veg help with things like fibre and carbs, too.
So there you go. My top tips for healthy eating with almost no change to your lifestyle:
Make the effort to find out what's actually in the food you eat.
Then watch the soda, cheese and sauces. Cutting down a little goes a long way.
Really do aim for 5+ portions of fruit and veg a day.
Aim for lots of fibre.
Don't make a token effort. Missing one can of soda or having a jacket potato instead of fries isn't good enough. You won't see results fast enough and you'll get discouraged. Just get off your arse and make a sustained effort, even if only a mild one, and visible results will come after a few days.
I lost the stone I wanted to comfortably in three months, and now feel much fitter as I get back into training. And I'm the laziest guy in the world, so if I can do it, anyone can.
That was one of the best things about B5, IMHO: while they had the requisite futuristic setting, I don't recall a single technological or scientific area that wasn't credible as somewhere we could be 250 years from now. We have faster-than-light travel, but it's not perfect in several ways. We have space stations, but people died falling out of the airlocks before they got them right. We have a time travel loop, but I never saw any logical flaws caused by it. Medical technology has improved, but it still can't cure everything. We've colonised Mars, but they live in enclosed cities, rather than having converted the atmosphere. We've met other races, and some of them are stronger than us. It's all credible.
That was one of the great things about the show, IMHO. I always liked Ivanova, and CC was brilliant at delivering some of her lines; the "Who am I?" speech was perfect.
Of course, there were also all those throwaway lines throughout the series that tied up the loose ends four series before you knew they existed. Want to know what happens to Londo and G'Kar? There's a visual cue in the very last episode, but actually you've known since the first episode of series one. Amazing thing, a series around 100 episodes long, spanning five years and dozens of recurring characters, and yet with barely a major loose end throughout.
What's even funnier is that when these always upright ships lose power they "lose" the ability to stay upright and drift on their side or upside down.
Actually, when artifial gravity fails, the graviton matrix that supports the inertial effect degenerates, and you get a recoil effect resulting in exactly that. Don't they teach you kids anything in high school any more?
Wait... This is 2203, right? Because if it's gone wrong and I've jumped too far again, the time cops are going to ki
It's a religious debate, but for my money there's simply no comparison between B5 and just about any other sci-fi series out there. I've watched and enjoyed plenty of the others, but B5 is just something else. It has a fantastically intricate storyline and some great characters, all set in a universe that's futuristic but very credible. The visual effects still look good even today, several years after it was made. Even the theme music changes subtly from series to series to sound more in tune with the story. It's dramatic, funny, triumphant, tragic, poignant, insightful and the only sci-fi that has ever made me cry.
NB: The episodes are somewhat independent, particularly in the early series, but there is a major story arc that runs throughout. You want to watch it from the start. It only really takes off from about the second series, but there are so many little set-ups (though you won't realise it at the time) that the first series is still a must. I doubt any regular channels are still running it anyway, as the last series was made several years ago. I'd just go and buy the whole lot on DVD.
dead-end? Java has already spawned javascript and C#.
...Neither of which has done anything to advance the state of the art in programming languages, even if your claim were true.
The one thing I have confidence in about programming in the future is that sooner or later, the tools and techniques with genuine advantages will beat the "useful hacks". Java, C++, VB and their ilk are widely used today because they can get a job done, and there's not much better around that gets the same job done as easily.
Sure, there are languages that are technically superior, but they're so cumbersome to use that no-one really notices them, and when they do, you don't have the powerful development tools, the established code base of useful libraries, the established user base of developers to hire, etc. When we get to the point that languages with more solid underlying models catch up on ease of use, then we'll relegate the useful hacks to their place in history as just that. Until then, we'll keep using the useful hacks because we have jobs to do, but don't expect the tools of the future to be built on them.
Slashdot Mirror
Try writing some real time instrument control software in a declarative language. :-)
Not saying it can't be done, or even potentially be done well, but I know of no declarative language that provides even close to the same level of control over sequences of events, and synchronisation between parallel sequences, as would be routine in a typical procedural or OO program.
(Apparently some such languages do actually exist. Another poster referred me to two quite old language families I hadn't previously encountered, and I'll look into them when time allows. Certainly none of the mainstream variations of things like ML, Haskell or LISP are up to the job as far as I've seen, though.)
I question whether you have actually tested any of this theory.
I work on computationally intensive software that gets built on more than a dozen platforms, including pretty much everything you mentioned. Having examined the assembly output for several of these on numerous occasions, I can promise you that most reasonably modern C++ compilers will optimise away those temporaries, allocate stack space en masse at function entry just as C usually does, inline or completely remove construction/destruction code that serves no useful purpose, and otherwise get rid of the various types of unnecessary overhead you seem to think are inescapable. You seem to write as if C++ optimisers still worked the way they did a decade ago.
If you prefer C to C++ for its simplicity and elegance, by all means say so. It's a perfectly reasonable position to take. But let's not start making claims about C++ that are demonstrably untrue, OK?
That's a part of it, yes. You have various common situations, just looking at classes as an example.
Every time you have a method in a class, you have to specify it in full in the interface, and then again in the implementation. Except that the names of the parameters can be omitted in the interface (although header files can make good documentation, so they're often reproduced anyway) and default parameters must be specified in the interface (though they, or at least a note of their existence, are commonly added as comments in the implementation as well). There is no need to have two independent copies of all of this information; it's perfectly possible to have a development environment where you spec the interface, and then the code behind each function, without the duplication.
Similarly, every time you override a base class method, you must specify the whole thing again in the derived class interface, and yet again in the derived class implementation. Again, there's no reason you couldn't have a development environment which worked everything off the single base class interface specification, plus the knowledge that both base and derived class provide an implementation. Don't even mention hiding base class members in a derived class, using declarations to bring them back into scope, and other such irritations.
Another common one is static data members, which in C++ must be declared (and under some circumstances can even be initialised) in the class declaration, but must then be defined in a single translation unit as well.
All of these things are just needless redundancy in the source code, created by the structure of C++, adding no value yet multiplying up the time taken to code things, and worse, multiplying up the time taken to change your mind later. With a system where interfaces are well managed and everything else depends cleanly upon them, it is easy to make changes. With a system where your interface spec is needlessly repeated every time someone implements part of it, or some other interface borrows from it, you just create needless dependencies between different areas of the code, which then need to be kept in sync, wasting time and risking errors.
And yes, there are development tools available today that can help with this, but I stand by my points that (a) most of them aren't that great anyway, and (b) they should be far more universal than they are.
So instead of a development environment where basic refactoring of classes, functions, etc. is done with a couple of mouseclicks or a keyboard shortcut, we have a model where we manually and laboriously trawl through dozens of different source files just to rename a member function whose purpose has subtly changed, or to extract a block from an inner loop and make it into a separate function. These processes have cost but offer no benefit, and thus, they suck.
And creating an integer temporary typically entails zero overhead. WTP?
I'm all for a more declarative programming style where it's appropriate, but some data structures and algorithms are simply much more efficient if you change them in-place.
#include <std_iteration_vs_recursion_arguments.h>
Lots of pretentious academics who like to think they're clever because it justifies their existence will tell the journeyman programmers of the world that the tools they use suck, functional programming is technically superior, etc. But while theory is all very well if you live in an ivory tower, in the real world, we have to write the code that gets the job done.
If functional programming and such were so much better than procedural, OO, etc. in practice then the professional development industry would be using them as a matter of routine. As it stands, there are at least two very good reasons this is not the case: FP doesn't have critical mass (small installed base, small code base of libraries, limited number of programmers familiar with it) and the FP model has its own problems, which don't much show up in theory labs (hence most academics' ignorance of them, or willingness to overlook them) but bite you in seconds in the real world (hence many informed and highly mathematically educated programmers still reject FP for their work).
I don't believe it... I actually agree with Tablizer. :o)
Many OO languages, including pretty much all of the major ones, suffer from tedious and repetitive syntax to define the various interfaces in use. For example, if I've got a method in a base class and I want to override it in a derived class, there is typically some significant redundancy.
I think having a separate definition of the interface to a class is useful as a tool for design, as documentation, and as a means of preventing silly errors. It has much the same practical benefits as using a strong typing system. But there is definitely too much pointless repetition in many OO languages.
It would be good for the industry if the development tools we use routinely all supported basic refactoring, browsing of the object model, etc. Even the best tools do a pretty mediocre job of this at present, resulting in countless hours of developer time wasted doing routine things like moving methods up or down a class hierarchy, or splitting a class.
Sorry, but now I'm lost. What part of C++ memory management do you think is not completely deterministic, and at what point do you think C++ needs to generate less efficient output code than C to do the same thing? Sure, C compilers still sometimes optimise better than C++ ones, and some C++ libraries do silly things like adding overhead and then just calling the equivalent underlying C function from the same library, but these are quality of implementation issues, not flaws with the C++ language.
I'm familiar with RT systems and their particular requirements, by the way. Presumably you're not doing a whole lot of dynamic memory allocation, which makes your comments about unpredictable memory management functions even more puzzling. What platform(s) are you developing for, and with what compilers?
Of course there is. In fact, a new entry for the JCP to create a class AnythingDoer is being worked on as I write. From J2SE 1.6 onwards, you will be able to write a program to do anything you want as follows.
At that point, functional programmers will be feeling small and insignificant, finally realising the underwhelming lack of power that their tools really don't possess, and the need for any sort of formal training for pogrammers will be resolved once and for all.
For example, if you had no idea how to get /. to indent your sample code sensibly, you could just call that method and it would cause some helpful soul to reply and end months of frustration. :-)
But the point is that, when you're interacting with the world outside your program, you have to worry about ordering, timing, interfaces and protocols, etc. This side of programming is where most of today's functional languages really fall down, and probably the single biggest reason they haven't been used more for mainstream applications, IMHO.
At the risk of stating the obvious, the ability to do generic programming (in the sense of working with arbitrary interfaces without needing the inheritance/OOP angle to specify that they're met) has been around for decades in many languages.
There's nothing inherently special about generic code. From a certain point of view, the very fact that generic algorithms and data structures are regarded as anything but the obvious default is just indicative of a flaw in the underlying models of languages that need templates etc.
I appreciate your enthusiasm, and generic programming is a fine idea, but if you think things like the STL and expression templates are original, you need to read up on things like functional programming, where vastly more powerful versions of the same concepts are routine. These libraries are very useful tools for languages that don't support the concepts natively, without a doubt, but magical they ain't.
The problem, of course, is that in their urge to hype the new toy, OO evangelists coined the term "is a" when it's not really an appropriate (or rather, complete) description of the concept.
Could you give an example of the sort of simple usage you're imagining? I can't think of much off the top of my head where you'd use an OOP feature in C++ but it would be faster to implement an equivalent manually in C, but maybe I'm missing something...
I realise the point he was trying to make, but unfortunately he's still wrong. C++ is designed with efficiency in mind, and in practice you will get identical or better output code using C++ features to model inheritance etc. than you would get by doing it manually in C. The guys writing the C++ compiler can do all the same tricks you can in C, and they can optimise at a lower level as well.
The "overhead" in using C++ OO features is almost entirely mythical, and has been for years.
Most drink-drivers think they're fine at the time. An impartial observer, objectively comparing their performance to a sober driver, would disagree.
What on earth makes you think you can implement the OO features of C++ manually in C, and do so better than those writing a C++ compiler who have resources to invest in optimising the way they are implemented?
In the commercial world, theoretically sound languages will become popular if and when the tools, user base and code base reach critical mass. These are the things that make the best practical tools of today (Java, C++, VB, etc.) popular, in spite of their well-known flaws.
I have high hopes for programming by specification, as in functional languages and such, but they, too, have their flaws. In particular, while they're dead neat for modelling calculations that just need to give you the right answer by whatever means necessary, they suck for modelling the concept of interaction with the outside world because they have problems repesenting the flow of time. Unfortunately, the benefits and problems are inherently tied together in a specification approach; the very things that give one also give the other.
What's needed, and my take on the next big thing in programming, is a language (textual or otherwise) that can represent both the flow of time to deal with interactions and pure specifications of the calculations and data manipulation to be done as a result, preferably with both being conceptually independent of the underlying machine. For example, I'd like things like threading and synchronisation to be mostly implicit, and I/O to be defined in terms of sequences of interactions and how they relate, much as in a specification language you can write a complex mathematical expression and only care that you get the right answer, without knowing where the calculation was performed, whether it used multiple threads/processors, etc. Of course, there will always be a certain need to understand the underlying model, just as when doing floating point maths you have to understand basic numerical analysis to avoid nasty surprises.
Some languages are heading in this direction already, but I don't know of any that's close to my ideal goal. When one comes along that reaches a critical mass of interest, the industry will start to change, slowly but surely, to adopt the theoretically superior approach. I'm not sure that language actually exists yet, though, nor what might act as the catalyst to get it to critical mass -- maybe the power of the Internet and enough geeks in senior developer positions taking a liking to the idea when it comes along?
But mainstream microprocessors are being used more and more often. Economies of scale mean they often cost a comparable amount these days, and clearly they are easier targets for development.
That's obviously not true, of course. If you can write for it in C, you can write for it in C++. Just don't use the extra features unless you really need them. And if you do really need them, it's probably more efficient to let your compiler do it behind the scenes than to hand-code an equivalent in C, even neglecting the benefits to development time, code maintenance, etc. that would result as well.
Sorry, I can't resist destroying this post point by point.
You don't know much about how to write C++, do you? Sure, for really low level code, a lot of it will be the same. Then for the higher level parts -- which is still most of an OS -- the C++ should be clearer and more concise. If it's 99% the same as the C, you're doing something wrong.
Do you know what the "zero overhead principle" of C++ says? You should read about it before you make such silly claims; try a copy of D&E for a start. Oh, and then try to work out how a language can let you violate the principles it requires. (Of course, C++ doesn't really require you to use OO at all, which is kinda the point.)
This just gets better and better.
I just don't know where to start with this. C++ doesn't exactly evolve at the same pace as, say, Java or Python, but whether that's a good thing or a bad thing remains to be seen. How you can claim C has a bigger "hardcore userbase" than C++ is beyond me. I work in fields where these langua
Yes, I understand where the number comes from, but I was just subtracting my daily Calorie intake from the 2,500 recommended for an average guy, and adding up the differences. Apparently, I'm a perfect example of a guy whose build and activity levels correspond to needing exactly 2,500 Calories a day to maintain weight, and furthermore my activities over the period were 100% efficient at burning fat to make up the shortfall. Or maybe I was just lucky in that the differences from these ideal figures cancelled out... :o)
Around new year, I decided I'd got heavier than I'd like. I'm reasonably fit, and a good weight for my height and build, but as a result of an injury I hadn't been doing nearly as much of my physical hobbies as usual, and I'd put on around a stone. So, I decided to try a genuine, honest-to-goodness diet + exercise regime to lose that weight.
For three months, I kept a spreadsheet of everything I ate or drank, with calorie counts, amounts of protein, carbs, fats and fibre, etc. I also kept a record of how much significant exercise I was doing, and my weight, daily.
Curious facts I discovered while researching/doing it...
So there you go. My top tips for healthy eating with almost no change to your lifestyle:
I lost the stone I wanted to comfortably in three months, and now feel much fitter as I get back into training. And I'm the laziest guy in the world, so if I can do it, anyone can.
That was one of the best things about B5, IMHO: while they had the requisite futuristic setting, I don't recall a single technological or scientific area that wasn't credible as somewhere we could be 250 years from now. We have faster-than-light travel, but it's not perfect in several ways. We have space stations, but people died falling out of the airlocks before they got them right. We have a time travel loop, but I never saw any logical flaws caused by it. Medical technology has improved, but it still can't cure everything. We've colonised Mars, but they live in enclosed cities, rather than having converted the atmosphere. We've met other races, and some of them are stronger than us. It's all credible.
That was one of the great things about the show, IMHO. I always liked Ivanova, and CC was brilliant at delivering some of her lines; the "Who am I?" speech was perfect.
Of course, there were also all those throwaway lines throughout the series that tied up the loose ends four series before you knew they existed. Want to know what happens to Londo and G'Kar? There's a visual cue in the very last episode, but actually you've known since the first episode of series one. Amazing thing, a series around 100 episodes long, spanning five years and dozens of recurring characters, and yet with barely a major loose end throughout.
Actually, when artifial gravity fails, the graviton matrix that supports the inertial effect degenerates, and you get a recoil effect resulting in exactly that. Don't they teach you kids anything in high school any more?
Wait... This is 2203, right? Because if it's gone wrong and I've jumped too far again, the time cops are going to ki
It's a religious debate, but for my money there's simply no comparison between B5 and just about any other sci-fi series out there. I've watched and enjoyed plenty of the others, but B5 is just something else. It has a fantastically intricate storyline and some great characters, all set in a universe that's futuristic but very credible. The visual effects still look good even today, several years after it was made. Even the theme music changes subtly from series to series to sound more in tune with the story. It's dramatic, funny, triumphant, tragic, poignant, insightful and the only sci-fi that has ever made me cry.
NB: The episodes are somewhat independent, particularly in the early series, but there is a major story arc that runs throughout. You want to watch it from the start. It only really takes off from about the second series, but there are so many little set-ups (though you won't realise it at the time) that the first series is still a must. I doubt any regular channels are still running it anyway, as the last series was made several years ago. I'd just go and buy the whole lot on DVD.
...Neither of which has done anything to advance the state of the art in programming languages, even if your claim were true.
The one thing I have confidence in about programming in the future is that sooner or later, the tools and techniques with genuine advantages will beat the "useful hacks". Java, C++, VB and their ilk are widely used today because they can get a job done, and there's not much better around that gets the same job done as easily.
Sure, there are languages that are technically superior, but they're so cumbersome to use that no-one really notices them, and when they do, you don't have the powerful development tools, the established code base of useful libraries, the established user base of developers to hire, etc. When we get to the point that languages with more solid underlying models catch up on ease of use, then we'll relegate the useful hacks to their place in history as just that. Until then, we'll keep using the useful hacks because we have jobs to do, but don't expect the tools of the future to be built on them.
Yeah...
Doesn't it just trip of the tongue? :o)