And what if a program cannot be inserted in a rigid multilevel scheme? Take a look at mplayer encoders, they hardly fit into this. This is the price of flexibility: rigid, easy-to-use models are not possible without sacrificing some of it. For several types of projects, this may be acceptable, but certainly not for all.
This is visible already. GUIs are done using RAD for example.
Well, even stuff like chip design is done (partially) with VHDL and Verilog.
The problem is that visual solutions scale much worse than programming languages. A hello world - no problem. MPEG-4 encoder? Good luck... you'll need it. And that is why comparisons with HTML are invalid: HTML is much, MUCH less powerful and complex. Programming languages are turing-complete.
What you suggest is yet another XML mess. Embedding SVG in code is pointless; SVGs are resources. Also, UML is not the silver bullet that will replace programming languages; its just not nearly as powerful. C++ metaprogramming and generic programming with UML? Lisp magic with UML? System programming with UML? Erlang-style threadlets with UML?
UML diagrams are good tools for representing an overview, and for brainstorming ("hey, what if we change this class inheritance to this one..."). But you forget about the mass of details a program has. UML describing all this WILL get messy and tedious to maintain, more so than a traditional programming language.
Obviously, those ducks were hit hard by sea storms etc. in the past. So maybe some got deformed and their shadow resembles Elvis! Imagine the tons of money you could get in Ebay with such a duck!
Well of course this issue needs to be adressed. The beauty of non-volatile RAM is that temporary files and temporary memory blocks are the same thing. So, do all non-persistent calculations in a tmp block (may be even visible in something like/tmp/, although that directory would be filled with LOTS of files then), and use persistent blocks only if its useful (like, a document).
malloc/new don't change; they still give you a temporary block thats gone once you free it. Persistent file access should use different, mmap-like calls. This way one does not run in the problem you described.
Most of these ideas are just gimmicks. One HUGE milestone only gets a footnote: non-volatile RAM.
Look at today's PC. Where is the bottleneck in 95% of all cases? The hard drive.
So, what could be the next killer feature? Non-volatile RAM (PRAM, FRAM, MRAM..). The immediate advantage is speed of course. But there is something much bigger.
Most of the time, loading a file is no longer necessary! Much of the boot time of today's OSes comes from loading stuff into RAM. This can be omitted with P/F/MRAM, reducing booting to device initialization. Also, suspend-to-disk comes for free.
Every single OS is based on the fact that there is a slow, but persistent memory (hard drive) and a fast, volatile one (RAM). They'd need a complete overhaul to fully exploit the new paradigm. Hell, almost all programs too. "Loading file to memory" is not necessary anymore, because the file already IS in memory! Thus, some sort of direct access is needed (unless the file is fragmented).
and now? Everyone should trash their Core 2's? I for one have neither the money nor the incentive to do this. Its a good thing De Raadt highlights these very serious issues, but unfortunately it comes too late.
Actually we are talking about VHDL. The "million transistors" argument is just as appropiate as saying "software is so large, it has so many ones and zeros". Development does not happen at this low stage.
Then why did you buy it in the first place? Besides, a 8800 GTX is a very good card. I chose a GTS because of power usage and price. But if you bought a $700 highend card without actually wanting it, then you are to blame.
assuming game developers jump on DX10, then gamers will be among the few who will upgrade to Vista. Now, this is a chicken-and-egg situation. Since few adopt Vista, devs still write games for DX9. So, what if the killer feature DX10 fails?
Read my correction above. Its Context < SingleThreaded > vs. Context < MultiThreaded > .
The idea is to either derive from the given class (SingleThreaded or MultiThreaded), or create an instance of it in the Context class. Both classes have ScopedLock subclasses etc. but in the SingleThreaded one ScopedLock is empty. Thus the compiler optimizes it away completely, as a result you have code without synchronization stuff, which make sense when one does not use threads. In MultiThreaded, ScopeLock *does* have contents, and locks/unlocks. This way, I can change the behaviour of the class just by passing a different template argument.
It gets even more interesting when more than one template argument is involved, for example Image . Adding support for another colorspace equals writing just another policy class (like ColorspaceLAB). I don't even have to derive it from a base class, it just has to have specific methods that get called inside of Context.
I highly recommend that you get the book "Modern C++ Design" by Andrei Alexandrescu. It is true that there is a hype around boost, however parts of it are excellent. And for the record, I have been programming for 15 years, 68k & x86 Asm, C, C++, Java, a bit Lisp, Python, Pascal.
Ideally, dynamic allocation should be encapsulated in classes which are guaranteed to be deallocated, either by simply being stack objects, or by a delete call that always - really always gets called.
If v1 + v2 is not readable for you, I suggest you learn some math. The grep argument is valid, though I use egrep and a regexp in this case. Also, I suspect you also hate extremely hard to read associative container access like table["entry"] = value; right?
Simple. Generic programming allows N+M work, whereas pure OO forces N*M. N being the number of algorithms, M the types. Translating to real code, the advantages of a generic vector container like the STL vector should be obvious, unless you feel inclined towards writing such a container for every type. This is true because generic programming identifies the properties of an object directly (for example, a + operator), and plain OO identifies types (thus ensuring that an object has certain properties).
Template metaprogramming also allows policy-based design, which essentially introduces permutations. Context vs. Context for instance. This way, you can optionally add thread safety at compile-time. Impossible with pure OO, and very big timesaver. How about iterators? Impossible in OO at compile-time and without downcasts (thats what Java does). Generic find algorithm? MVC signals? (These are extremely handy for GUI toolkits) Or how about stuff like boost::bind?
MVC and RAII are basics, not "fancy new toys". It is likely that you already know them, just not by this name. Happens to me often, too, I implement design patterns and don't know that this is actually pattern XYZ.
BS again. Overloading a + operator is just "showing off"? I suppose you like adding vector components manually, instead of doing v1 + v2? How about bigint classes, operator overloading is a bless there. Correct use of templates can significantly reduce the amount of written code and clarify it, as shown in the earlier vector example.
Correction: the people who gave C++ templates, which are a killer feature. Thanks to templates, I can do generic programming and metaprogramming in C++, which are orders of magnitude more powerful than OO only.
Stuff the mem allocation in the constructor, or at least set the pointer to zero there. Call delete in the destructor. This avoids memleaks and is exception-safe.
Great RPGs: Oblivion and KotOR. KotOR: ok. Oblivion: no. Gameplay-wise, Oblivion is closer to Diablo than to an offline RPG. Instead, you should mention Fallout 1 & 2, Baldurs Gate 1 & 2, and especially Planescape Torment. I mean, the contrast between Oblivion and P:T is so enormous, its hard to believe both are called RPGs.
Planescape Torment is also a very good example of what MMOGs can never deliver and single player RPGs can: immerse the player in a very detailed and extensive storyline.
XUL is not HTML. They have a similar syntax, but thats it. XUL defines interfaces, HTML describes hypertext. Hypertext is NOT good as an interface. The whole paradigm does not fit into this. The entire layout mechanism should be different for web applications, and things like the "back" button just don't fit in this. I am all for XUL, but keep HTML out of this. Write hypertext documents in HTML+CSS, and webapps in XUL.
Slashdot Mirror
And what if a program cannot be inserted in a rigid multilevel scheme? Take a look at mplayer encoders, they hardly fit into this. This is the price of flexibility: rigid, easy-to-use models are not possible without sacrificing some of it. For several types of projects, this may be acceptable, but certainly not for all.
This is visible already. GUIs are done using RAD for example.
Sorry, overlooked the "comment" bit. Its just that people tend to see XML as a shiny new hammer all the time.
Well, even stuff like chip design is done (partially) with VHDL and Verilog.
... you'll need it.
The problem is that visual solutions scale much worse than programming languages. A hello world - no problem. MPEG-4 encoder? Good luck
And that is why comparisons with HTML are invalid: HTML is much, MUCH less powerful and complex. Programming languages are turing-complete.
Please, stop the XML overuse.
What you suggest is yet another XML mess. Embedding SVG in code is pointless; SVGs are resources. Also, UML is not the silver bullet that will replace programming languages; its just not nearly as powerful. C++ metaprogramming and generic programming with UML? Lisp magic with UML? System programming with UML? Erlang-style threadlets with UML?
UML diagrams are good tools for representing an overview, and for brainstorming ("hey, what if we change this class inheritance to this one..."). But you forget about the mass of details a program has. UML describing all this WILL get messy and tedious to maintain, more so than a traditional programming language.
HTML is not nearly as powerful as a language. What you imply has been tried many times; programming languages still are with us.
Obviously, those ducks were hit hard by sea storms etc. in the past. So maybe some got deformed and their shadow resembles Elvis! Imagine the tons of money you could get in Ebay with such a duck!
Well of course this issue needs to be adressed. The beauty of non-volatile RAM is that temporary files and temporary memory blocks are the same thing. So, do all non-persistent calculations in a tmp block (may be even visible in something like /tmp/, although that directory would be filled with LOTS of files then), and use persistent blocks only if its useful (like, a document).
malloc/new don't change; they still give you a temporary block thats gone once you free it. Persistent file access should use different, mmap-like calls. This way one does not run in the problem you described.
Most of these ideas are just gimmicks. One HUGE milestone only gets a footnote: non-volatile RAM.
Look at today's PC. Where is the bottleneck in 95% of all cases? The hard drive.
So, what could be the next killer feature? Non-volatile RAM (PRAM, FRAM, MRAM..). The immediate advantage is speed of course. But there is something much bigger.
Most of the time, loading a file is no longer necessary! Much of the boot time of today's OSes comes from loading stuff into RAM. This can be omitted with P/F/MRAM, reducing booting to device initialization. Also, suspend-to-disk comes for free.
Every single OS is based on the fact that there is a slow, but persistent memory (hard drive) and a fast, volatile one (RAM). They'd need a complete overhaul to fully exploit the new paradigm. Hell, almost all programs too. "Loading file to memory" is not necessary anymore, because the file already IS in memory! Thus, some sort of direct access is needed (unless the file is fragmented).
and now? Everyone should trash their Core 2's? I for one have neither the money nor the incentive to do this. Its a good thing De Raadt highlights these very serious issues, but unfortunately it comes too late.
Actually we are talking about VHDL. The "million transistors" argument is just as appropiate as saying "software is so large, it has so many ones and zeros". Development does not happen at this low stage.
Then why did you buy it in the first place?
Besides, a 8800 GTX is a very good card. I chose a GTS because of power usage and price. But if you bought a $700 highend card without actually wanting it, then you are to blame.
The only way to prevent war is to prevent the existence of more than one opinion.
So, a hive mind would end the wars.
But would this be really better?
assuming game developers jump on DX10, then gamers will be among the few who will upgrade to Vista.
Now, this is a chicken-and-egg situation. Since few adopt Vista, devs still write games for DX9. So, what if the killer feature DX10 fails?
Read my correction above. Its Context < SingleThreaded > vs. Context < MultiThreaded > .
The idea is to either derive from the given class (SingleThreaded or MultiThreaded), or create an instance of it in the Context class. Both classes have ScopedLock subclasses etc. but in the SingleThreaded one ScopedLock is empty. Thus the compiler optimizes it away completely, as a result you have code without synchronization stuff, which make sense when one does not use threads. In MultiThreaded, ScopeLock *does* have contents, and locks/unlocks. This way, I can change the behaviour of the class just by passing a different template argument.
It gets even more interesting when more than one template argument is involved, for example Image . Adding support for another colorspace equals writing just another policy class (like ColorspaceLAB). I don't even have to derive it from a base class, it just has to have specific methods that get called inside of Context.
I highly recommend that you get the book "Modern C++ Design" by Andrei Alexandrescu. It is true that there is a hype around boost, however parts of it are excellent. And for the record, I have been programming for 15 years, 68k & x86 Asm, C, C++, Java, a bit Lisp, Python, Pascal.
Ideally, dynamic allocation should be encapsulated in classes which are guaranteed to be deallocated, either by simply being stack objects, or by a delete call that always - really always gets called.
Then, RAII does work.
Context vs. Context
should be Context < SingleThreaded > vs. Context < MultiThreaded >
If v1 + v2 is not readable for you, I suggest you learn some math.
The grep argument is valid, though I use egrep and a regexp in this case.
Also, I suspect you also hate extremely hard to read associative container access like table["entry"] = value; right?
Simple. Generic programming allows N+M work, whereas pure OO forces N*M. N being the number of algorithms, M the types. Translating to real code, the advantages of a generic vector container like the STL vector should be obvious, unless you feel inclined towards writing such a container for every type. This is true because generic programming identifies the properties of an object directly (for example, a + operator), and plain OO identifies types (thus ensuring that an object has certain properties).
Template metaprogramming also allows policy-based design, which essentially introduces permutations. Context vs. Context for instance. This way, you can optionally add thread safety at compile-time. Impossible with pure OO, and very big timesaver. How about iterators? Impossible in OO at compile-time and without downcasts (thats what Java does). Generic find algorithm? MVC signals? (These are extremely handy for GUI toolkits) Or how about stuff like boost::bind?
Without templates, C++ loses its real advantage.
MVC and RAII are basics, not "fancy new toys". It is likely that you already know them, just not by this name. Happens to me often, too, I implement design patterns and don't know that this is actually pattern XYZ.
BS again. Overloading a + operator is just "showing off"? I suppose you like adding vector components manually, instead of doing v1 + v2? How about bigint classes, operator overloading is a bless there. Correct use of templates can significantly reduce the amount of written code and clarify it, as shown in the earlier vector example.
Correction: the people who gave C++ templates, which are a killer feature. Thanks to templates, I can do generic programming and metaprogramming in C++, which are orders of magnitude more powerful than OO only.
No, Java generics are not the same.
You forgot one important thing: RAII.
Stuff the mem allocation in the constructor, or at least set the pointer to zero there. Call delete in the destructor. This avoids memleaks and is exception-safe.
Well, I played Baldurs Gate 2, and Oblivion, and I have to say BG2 quests are much more varied, deeper, more interesting, and better constructed.
Great RPGs: Oblivion and KotOR.
KotOR: ok. Oblivion: no. Gameplay-wise, Oblivion is closer to Diablo than to an offline RPG. Instead, you should mention Fallout 1 & 2, Baldurs Gate 1 & 2, and especially Planescape Torment. I mean, the contrast between Oblivion and P:T is so enormous, its hard to believe both are called RPGs.
Planescape Torment is also a very good example of what MMOGs can never deliver and single player RPGs can: immerse the player in a very detailed and extensive storyline.
XUL is not HTML.
They have a similar syntax, but thats it.
XUL defines interfaces, HTML describes hypertext. Hypertext is NOT good as an interface. The whole paradigm does not fit into this. The entire layout mechanism should be different for web applications, and things like the "back" button just don't fit in this. I am all for XUL, but keep HTML out of this. Write hypertext documents in HTML+CSS, and webapps in XUL.