To clarify, figuring out how the nerves convey messages to the muscles (and ignoring other means of communication as the parent pointed out) is kind of like sticking a bunch of oscilloscope probes onto a moderately complex breadboard and figuring out how it works from what we see on the scopes. Bear in mind that the circuit is analogue. And we're not quite sure where the nodes are. And we can't actually see the circuit at all.
Is the information frequency coded? Pulse coded? Phase coded? Some combination of the above? Who knows.
My hunch, based on the fragmentary information I've seen, is that nerves code messages in all three ways, AND that the encoding differs from person to person.
So what we really need is some sort of adaptive machine that figures out how to talk to the brain and then translates into signals conventional circuits can understand. Way beyond what is presently possible.
Re:Yes, but does it work in Europe?
on
SQL Cookbook
·
· Score: 1
Cheating ever so slightly by using OLAP functions;-) But forgiven. OP was slightly tongue-in-cheek; my point was that SQL is a bit dated.
Yes, but does it work in Europe?
on
SQL Cookbook
·
· Score: 1
I'd buy this book in an instant if it could give me a good (efficient) solution for this query:
return the set of most recent sales grouped by customer.
[Stands back and smirks while flocks of geeks bang their heads against relational algebra]
You have a great point about the difficulties of cross-language integration and debugging. It can be a bit of a nightmare, and is a good reason to develop individual products in a single language.
However...
"Where other programmers are afraid to walk at night"? What kind of "other programmers" are we talking about here? Speaking for myself, I have little time for programmers too afraid to venture outside of their "comfortable" language. Particularly if they then have the gall to describe themselves as "developers".
Software engineering is language-neutral. If you can do it in pseudocode, you can do it in Lisp, C, Pascal, even (heaven forbid) Visual Basic. As many others have pointed out, some languages are better suited to certain tasks than others. One of your responsibilities as a programmer is to know which languages are appropriate for the task at hand. Blindly hammering away with C or Python or whatever is a sure road to obsolescence.
At work we run a jabber server on our internet gateway, with MSN, Yahoo, AIM, etc. transports installed. That way I can run Psi and be connected to all the IM services I might want to use (including Google Talk, which is jabber in the first place). It's very convenient in terms of not cluttering up my task tray, although I must say I think Psi could use some user-interface work.
Oh, and remote control of resource priorities would be nice too...
The US is perfectly entitled to take whatever actions it deems necessary, and to be judged on the consequences of those actions. I'm merely explaining why the world is rapidly losing patience with America. If you think you can go it alone, fine - go it alone. The dollar will continue to slide, the deficits will continue to mount, and one of these days, when your president has to approach China hat-in-hand asking for another loan, you'll wonder where you went wrong. That is, if you don't get nuked into oblivion by terrorists who hate you first.
It's not envy that makes the terrorists hate America, as you seem to think. It's moral outrage at what are, by any objective measure, thoroughly despicable actions by your government. I don't believe - unlike GWB, apparently - that moral outrage justifies the initiation of force. However I do believe that those who have been attacked by America have a God-given right to defend themselves. I will therefore find it extremely hard to drum up any sympathy for you when the next 9/11 happens. Idealism, you said? Very well - going by the bronze rule ("he who has the gold makes the rules"), America fully deserved what happened to it on 9/11. After all, the terrorists had the planes, and you had nothing. Sucks, doesn't it?
America's attitude towards the Kyoto treaty is symptomatic of a growing malaise - a deliberate ignorance by Americans of the damage caused by America. Your pollution affects us. Five percent of the world's population (that's you) is producing 25% of its pollution. Europe, with a slightly larger economy, is producing less pollution than its "fair share", going by population. And you have the temerity to call foul when the Kyoto treaty isn't perfectly even-handed?
I agree that Kyoto is flawed, and in particular isn't stringent enough in the requirements it imposes on China. That does not give America an excuse to throw the process out the window, and refuse to play by the rules the rest of the world has agreed to.
Have you considered that there
mightbea reason
for the rest of the world to distrust the US? Did it occur to you that maybe, just maybe, your presence on the world stage is causing
more harm than good? Here's another reality check: the rest of the world does not want you to intervene in its affairs. We'd love it if you just quit the UN. Really. Only that wouldn't stop you from throwing your weight around, would it? So perhaps the thing to do is to stop being childish, and engage with the rest of the world in a productive way, in the forum designed for this very purpose - the United Nations. Hope springs eternal...
What I'm saying is that DDNS doesn't work "out of the box" on many popular distros, and it should. That's all. I know damn well that Windows does broken client-side DDNS:-). I've also helped configure enough Linux boxes to know that the average administrator has a tough time figuring out where to go looking when he can't ping the box he just hooked up to the network. It almost invariably involves some console work, which is unacceptable if Linux wants to reach the mass market. For myself, I don't have a problem getting it to work, but I find it irritating that I have to in the first place.
One thing about most main-stream Linux distros that has annoyed me a lot is that they don't seem to support dynamic DNS (which most corporate environments that I know of use). In particular, a parameter usually needs to be passed to the DHCP client to "send the hostname" (which allows the DHCP server to update the DNS records). This parameter is almost always off by default. On Redhat this is just annoying; you can turn it on fairly easily. On Ubuntu and some other Debian-based distros, this is a royal pain in the ass.
By comparison, Windows makes this very easy. Windows also doesn't insist on equating the hostname to localhost (i.e. putting hostname in the hosts file pointing to 127.0.0.1), which is very broken behaviour IMHO. Localhost = loopback = 127.0.0.1. Hostname = primary interface = some other IP. I understand the reasons why the distros do this, but there are adequate workarounds which should be used instead.
What you have written above essentially translates to: "The most powerful and successful country in the world is further to the right than the rest of the world."
While it is possible that political stance is not a statistical predictor of a country's success, you should take it into consideration that it could be.
Be careful. "To the right" means a lot of different things. Does religious conservatism promote economic success? Does pre-emptive war promote economic success? I would argue that the United States is successful because it values liberty: economic and political freedom. In this respect I subscribe to the views of Friedrich Hayek. Does W value liberty? Arguably he does (in economic respects, at any rate). Is it possible to liberalize (i.e. bring liberty to) another country by invading it? The weight of historical evidence suggests not.
Guess what, we don't give a shit what you think.
That's exactly why we have no respect for you. That, and the fact that you're ignorant enough to think that the rest of the world opposed the war on Iraq because they were "bribed by Saddam".
The deciding factor - crap.
on
Java 1.5 vs C#
·
· Score: 1
At this point (even before Whidbey) the deciding factor (as always) for Enterprise work, when choosing a language platform, should be the support it has behind it, in terms of IDE, tools, api, and
longevity of the vendor pushing it...
Crap.
C is the most successful language in history, and vendor support for it was fragmented at best. If you've got a good compiler, you understand the language and you have all the tools you need, who cares if the vendor goes under? Your assertion that the "longevity" of the vendor counts in the slightest has no substantive argument or evidence backing it up. Defend your position! Just because the store that sold me my deluxe high-powered all-in-one combo jigsaw/drill/planing tool has gone out of business doesn't mean that the tool is worthless, and that I should therefore use a hammer.
My position is this: when you're starting a project, you have several goals, with different relative importances. Often the primary goal is to get the job done quickly, in which case a so-called "scripting" [emotive and inaccurate term] language is your best choice. At other times interoperability with certain other products is more important, and that drives the choice of language. Sometimes speed counts. Choose your tools to fit the job!
Most of the time what I see in reality is programmers choosing languages not because of their technical merits, nor even necessarily because they're popular, but because they've had a lot of press. What kind of a criterion is that? How many of you (programmers) can honestly say you've mastered more than three languages? Speak up now. No? Then wouldn't it be fair to say that your toolbox is a little empty? And if that's the case, isn't it just maybe possible that you don't always use the best tool for the job?
I don't suppose anybody noticed that the PBMR referred to in the story was developed and made in South Africa? No idea if this is actually the PBMR system China is going to use, or if they developed their own. At any rate, the design was originally German, but they've moved away from nuclear power.
Eskom, the South African energy parastatal, is actually building one of these things at Pelindaba, although it's fairly small (~165MW, I think). If it's a success, I expect we'll see a lot more of these.
C++ isn't safe and it cannot be made safe without garbage collection.
I'd be very hesitant to make such a bold assertion. Define "isn't safe"! As I said, C++ programs can be made a lot safer than Java programs. They also can be made a lot less safe. It depends on who's writing them.
Safety is not a property of programs, it's a property of languages and runtimes.
That sounds suspiciously like an advertising jingo to me. Safety is most certainly a property of programs. Either a program is "safe", or it isn't. How the program was developed is another matter: some languages certainly promote safe practises more than others. Java promotes some safe practises, but in the process rides roughshod over a lot of other safety considerations. This makes it good for some applications (where the first set of safety criteria is all-important) and less than good for others (where the second set comes into play). Does this surprise anyone?
...most C++ programs contain large amounts of code over which you have no control.
That may or may not be the case. On the other hand, with C++ I have a lot of choice as to exactly which code that is not under my control I use. So "not under my control" is a relative thing;-).
And, in fact, most C++ abstractions are merely advisory and no guarantees. Just because you tie methods to an object that you intend to be stack allocated doesn't mean that I won't allocate it on the heap and fail to release the lock because of that.
Once again, I'd hesitate before making such an assertion. Here is a code fragment that may make you think twice:
class Foo { private: Foo() { } public: static std::auto_ptr<Foo> create() { return new Foo(); } };
As always, it depends on what you're trying to achieve, and most importantly, on who is writing the code. Use the right tool for the right job.
C++ solves a common but limited subset of the resource management problem and then just declares victory. And even that false victory is not very satisfying because in order to achieve it, C++ has sacrified runtime safety. (In fact, with that choice, it has also sacrificed efficiency, but you aren't going to believe that no matter what I say.)
I agree that there are some resource management issues that are more difficult to deal with in C++ than in a garbage collected language (i.e. those for which shared_ptr and weak_ptr are not sufficient). However, these are very, very few and far between. Also, they tend to arise in situations where careful thought about the design is required in any case. I'd rather explicitly think about lifetime and ownership issues in these cases than just sweep the problems under the rug that is garbage collection.
C++ is just as efficient and easy to use in the vast majority of memory management cases as Java or C#. What's more, it trumps those languages when it comes to managing other types of resources.
For those who are about to point out C#'s using statement: yes, this is not a bad idea, but you still have to remember to use it, and it's still therefore error-prone. In C++, we can make our lock() and unlock() methods accessible only to the RAII proxy, thus ensuring that there is exactly one unlock() for every lock(). Try enforcing usage contracts like that in Java/C#.
Which brings me to my next point: properly written C++ programs are much safer than Java/C# programs. One reason for this is that the C++ compiler is capable of forcing usage patterns in the manner described above. Another reason is that the judicious use of generic programming and encapsulated types significantly reduces the scope for the sins of ommission that are all too common amongst programmers.
Yes, it's still far easier to produce a core dump in C++. On the other hand, it's also far easier to produce a provably correct C++ program of any complexity than to produce the equivalent Java/C# program.
Java doesn't have destructors. It has finalizers, but they are called at unpredictable and occasionally awkward times (if at all). This presents a whole new challenge in terms of establishing invariants.
Consider, for example, the case of a mutex. In C++ I can encapsulate the acquisition and release of the mutex in an object (for an example of this, see boost::mutex::scoped_lock at www.boost.org), and know for certain that I will own the mutex object for the duration of the scope of the locking object. This invariant is maintained even in the presence of exceptions, break or continue statements, early returns, or other surprises.
The net effect is that the code is (a) robust, (b) maintainable, and (c) easy to read.
Contrast:
mutex::scoped_lock lock(name_list_update); if (!should_insert) break; name_list.insert("Bjarne");
Please explain to me exactly how you can implement a resource management system (or regime as you call it) in C++ for, lets say, managing socket connections, that has no equivlent in Java. You are aware of this method, right?
Okie dokie (pardon the bad formatting):
class TCPSocket { int handle_; public: TCPSocket() { handle_ = socket (AF_INET, SOCK_STREAM, 0); }
~TCPSocket() { close(handle_); } };
I think you'll find that there's no equivalent to the above in Java.
This may prove to be good reading, if you are interested in learning more.
Another important consideration is that where the programmer has the expectation that his garbage will be cleaned up for him, he will tend to assume that all of his resources will be cleaned up. This is clearly not the case. The seminal example for me was the use of database query result sets in C# - if you don't explicitly close them, they tend hang around, and the next time you try to perform a query on the same connection, you'll as likely as not get an exception. Surprise!
Also, as some other posters have pointed out, not all garbage collection is automatically bad. It works pretty well in Lisp, Scheme, Haskell, and friends. However in the cases of Java and C# it is certainly detrimental, as it disables the only really effective mechanism for managing resources in those languages - destructors.
Perhaps the thing to do is introduce an analogue for Lisp unwind-protect mechanisms. I suggested this a while back on the Java community forums, in the form of having sentry objects with the lifetime semantics of C++ automatic objects. Someone made the suggestion that the volatile keyword could be twisted to serve this purpose.
In Soviet Russia, you say Da-Nyet. In South Africa, it's No-Ja (no-yes), or if you're really trying to make a point, "Ja Well No Fine", or "No Ja Well Fine" or any other combination of the above. Basically, it's an emphatic way of saying, "whatever".
As some of you inferred (and others didn't), the OpenGL requirements are purely on the UI side;-).
My concern about interface contracts was this: it is very easy to accidentally change a.NET interface, since they aren't explicitly separated from the code. However, it should be possible to just make a bunch of read-only interface definitions in a common directory.
I think the biggest issue is (sadly) rapid development, and it is here that.NET establishes a clear dominance over the CORBA route. For the record, I love CORBA - IMHO it's the greatest middleware technology available.
Our cross platform requirement is not critical - we will likely not deploy the client-side on *nix for some years, and the back-end is of course much easier to port.
I am very concerned at the thought of having to host my services in IIS. Then again, connections are managed by a fairly thorough cryptographic challenge process.
I think NASA's current paralysis can be explained in part by their attitude towards money. What I have in mind is the famous space pen story - the Americans spend millions of dollars developing a space-pen, the Russians use a pencil. The article makes some interesting comparisons between the two programs, and it seems that the very budgetary constraints that are causing the Russian program to decay were the driving force behind some of its better/safer innovations. The Russians have always done clever things on a shoe-string, whereas the Americans have tended to go for the white elephants. Perhaps NASA should employ some of those Russian rocket scientists?
IN SOVIET RUSSIA.... naah.
Another big one which you've missed is the GTK. It has a glarea module for OpenGL drawing areas, and has the advantage of a very strong design. On the other hand, since your focus is on building an OpenGL-based system, why bother with the overhead of a widget set at all? Don't reject the idea out of hand. Not having a pre-designed widget set will force you to think carefully about your interface. In my opinion, this is the major shortcoming of most commercial modelling systems - a counter-intuitive UI.
Slashdot Mirror
To clarify, figuring out how the nerves convey messages to the muscles (and ignoring other means of communication as the parent pointed out) is kind of like sticking a bunch of oscilloscope probes onto a moderately complex breadboard and figuring out how it works from what we see on the scopes. Bear in mind that the circuit is analogue. And we're not quite sure where the nodes are. And we can't actually see the circuit at all.
Is the information frequency coded? Pulse coded? Phase coded? Some combination of the above? Who knows.
My hunch, based on the fragmentary information I've seen, is that nerves code messages in all three ways, AND that the encoding differs from person to person.
So what we really need is some sort of adaptive machine that figures out how to talk to the brain and then translates into signals conventional circuits can understand. Way beyond what is presently possible.
Cheating ever so slightly by using OLAP functions ;-) But forgiven. OP was slightly tongue-in-cheek; my point was that SQL is a bit dated.
I'd buy this book in an instant if it could give me a good (efficient) solution for this query: return the set of most recent sales grouped by customer. [Stands back and smirks while flocks of geeks bang their heads against relational algebra]
You have a great point about the difficulties of cross-language integration and debugging. It can be a bit of a nightmare, and is a good reason to develop individual products in a single language.
However...
"Where other programmers are afraid to walk at night"? What kind of "other programmers" are we talking about here? Speaking for myself, I have little time for programmers too afraid to venture outside of their "comfortable" language. Particularly if they then have the gall to describe themselves as "developers".
Software engineering is language-neutral. If you can do it in pseudocode, you can do it in Lisp, C, Pascal, even (heaven forbid) Visual Basic. As many others have pointed out, some languages are better suited to certain tasks than others. One of your responsibilities as a programmer is to know which languages are appropriate for the task at hand. Blindly hammering away with C or Python or whatever is a sure road to obsolescence.
At work we run a jabber server on our internet gateway, with MSN, Yahoo, AIM, etc. transports installed. That way I can run Psi and be connected to all the IM services I might want to use (including Google Talk, which is jabber in the first place). It's very convenient in terms of not cluttering up my task tray, although I must say I think Psi could use some user-interface work.
Oh, and remote control of resource priorities would be nice too...
The US is perfectly entitled to take whatever actions it deems necessary, and to be judged on the consequences of those actions. I'm merely explaining why the world is rapidly losing patience with America. If you think you can go it alone, fine - go it alone. The dollar will continue to slide, the deficits will continue to mount, and one of these days, when your president has to approach China hat-in-hand asking for another loan, you'll wonder where you went wrong. That is, if you don't get nuked into oblivion by terrorists who hate you first.
It's not envy that makes the terrorists hate America, as you seem to think. It's moral outrage at what are, by any objective measure, thoroughly despicable actions by your government. I don't believe - unlike GWB, apparently - that moral outrage justifies the initiation of force. However I do believe that those who have been attacked by America have a God-given right to defend themselves. I will therefore find it extremely hard to drum up any sympathy for you when the next 9/11 happens. Idealism, you said? Very well - going by the bronze rule ("he who has the gold makes the rules"), America fully deserved what happened to it on 9/11. After all, the terrorists had the planes, and you had nothing. Sucks, doesn't it?
America's attitude towards the Kyoto treaty is symptomatic of a growing malaise - a deliberate ignorance by Americans of the damage caused by America. Your pollution affects us. Five percent of the world's population (that's you) is producing 25% of its pollution. Europe, with a slightly larger economy, is producing less pollution than its "fair share", going by population. And you have the temerity to call foul when the Kyoto treaty isn't perfectly even-handed?
I agree that Kyoto is flawed, and in particular isn't stringent enough in the requirements it imposes on China. That does not give America an excuse to throw the process out the window, and refuse to play by the rules the rest of the world has agreed to.
Have you considered that there might be a reason for the rest of the world to distrust the US? Did it occur to you that maybe, just maybe, your presence on the world stage is causing more harm than good? Here's another reality check: the rest of the world does not want you to intervene in its affairs. We'd love it if you just quit the UN. Really. Only that wouldn't stop you from throwing your weight around, would it? So perhaps the thing to do is to stop being childish, and engage with the rest of the world in a productive way, in the forum designed for this very purpose - the United Nations. Hope springs eternal...
Set DHCP_HOSTNAME in /etc/sysconfig/network. Here's a page that may be helpful.
The rest of the world will be pleased to help you out. Which way did you come in?
What I'm saying is that DDNS doesn't work "out of the box" on many popular distros, and it should. That's all. I know damn well that Windows does broken client-side DDNS :-). I've also helped configure enough Linux boxes to know that the average administrator has a tough time figuring out where to go looking when he can't ping the box he just hooked up to the network. It almost invariably involves some console work, which is unacceptable if Linux wants to reach the mass market. For myself, I don't have a problem getting it to work, but I find it irritating that I have to in the first place.
One thing about most main-stream Linux distros that has annoyed me a lot is that they don't seem to support dynamic DNS (which most corporate environments that I know of use). In particular, a parameter usually needs to be passed to the DHCP client to "send the hostname" (which allows the DHCP server to update the DNS records). This parameter is almost always off by default. On Redhat this is just annoying; you can turn it on fairly easily. On Ubuntu and some other Debian-based distros, this is a royal pain in the ass.
By comparison, Windows makes this very easy. Windows also doesn't insist on equating the hostname to localhost (i.e. putting hostname in the hosts file pointing to 127.0.0.1), which is very broken behaviour IMHO. Localhost = loopback = 127.0.0.1. Hostname = primary interface = some other IP. I understand the reasons why the distros do this, but there are adequate workarounds which should be used instead.
Be careful. "To the right" means a lot of different things. Does religious conservatism promote economic success? Does pre-emptive war promote economic success? I would argue that the United States is successful because it values liberty: economic and political freedom. In this respect I subscribe to the views of Friedrich Hayek. Does W value liberty? Arguably he does (in economic respects, at any rate). Is it possible to liberalize (i.e. bring liberty to) another country by invading it? The weight of historical evidence suggests not.
Guess what, we don't give a shit what you think. That's exactly why we have no respect for you. That, and the fact that you're ignorant enough to think that the rest of the world opposed the war on Iraq because they were "bribed by Saddam".
Crap.
C is the most successful language in history, and vendor support for it was fragmented at best. If you've got a good compiler, you understand the language and you have all the tools you need, who cares if the vendor goes under? Your assertion that the "longevity" of the vendor counts in the slightest has no substantive argument or evidence backing it up. Defend your position! Just because the store that sold me my deluxe high-powered all-in-one combo jigsaw/drill/planing tool has gone out of business doesn't mean that the tool is worthless, and that I should therefore use a hammer.
My position is this: when you're starting a project, you have several goals, with different relative importances. Often the primary goal is to get the job done quickly, in which case a so-called "scripting" [emotive and inaccurate term] language is your best choice. At other times interoperability with certain other products is more important, and that drives the choice of language. Sometimes speed counts. Choose your tools to fit the job!
Most of the time what I see in reality is programmers choosing languages not because of their technical merits, nor even necessarily because they're popular, but because they've had a lot of press. What kind of a criterion is that? How many of you (programmers) can honestly say you've mastered more than three languages? Speak up now. No? Then wouldn't it be fair to say that your toolbox is a little empty? And if that's the case, isn't it just maybe possible that you don't always use the best tool for the job?
I don't suppose anybody noticed that the PBMR referred to in the story was developed and made in South Africa? No idea if this is actually the PBMR system China is going to use, or if they developed their own. At any rate, the design was originally German, but they've moved away from nuclear power.
Eskom, the South African energy parastatal, is actually building one of these things at Pelindaba, although it's fairly small (~165MW, I think). If it's a success, I expect we'll see a lot more of these.
I'd be very hesitant to make such a bold assertion. Define "isn't safe"! As I said, C++ programs can be made a lot safer than Java programs. They also can be made a lot less safe. It depends on who's writing them.
That sounds suspiciously like an advertising jingo to me. Safety is most certainly a property of programs. Either a program is "safe", or it isn't. How the program was developed is another matter: some languages certainly promote safe practises more than others. Java promotes some safe practises, but in the process rides roughshod over a lot of other safety considerations. This makes it good for some applications (where the first set of safety criteria is all-important) and less than good for others (where the second set comes into play). Does this surprise anyone?
That may or may not be the case. On the other hand, with C++ I have a lot of choice as to exactly which code that is not under my control I use. So "not under my control" is a relative thing ;-).
Once again, I'd hesitate before making such an assertion. Here is a code fragment that may make you think twice:
As always, it depends on what you're trying to achieve, and most importantly, on who is writing the code. Use the right tool for the right job.
I agree that there are some resource management issues that are more difficult to deal with in C++ than in a garbage collected language (i.e. those for which shared_ptr and weak_ptr are not sufficient). However, these are very, very few and far between. Also, they tend to arise in situations where careful thought about the design is required in any case. I'd rather explicitly think about lifetime and ownership issues in these cases than just sweep the problems under the rug that is garbage collection.
C++ is just as efficient and easy to use in the vast majority of memory management cases as Java or C#. What's more, it trumps those languages when it comes to managing other types of resources.
For those who are about to point out C#'s using statement: yes, this is not a bad idea, but you still have to remember to use it, and it's still therefore error-prone. In C++, we can make our lock() and unlock() methods accessible only to the RAII proxy, thus ensuring that there is exactly one unlock() for every lock(). Try enforcing usage contracts like that in Java/C#.
Which brings me to my next point: properly written C++ programs are much safer than Java/C# programs. One reason for this is that the C++ compiler is capable of forcing usage patterns in the manner described above. Another reason is that the judicious use of generic programming and encapsulated types significantly reduces the scope for the sins of ommission that are all too common amongst programmers.
Yes, it's still far easier to produce a core dump in C++. On the other hand, it's also far easier to produce a provably correct C++ program of any complexity than to produce the equivalent Java/C# program.
Java doesn't have destructors. It has finalizers, but they are called at unpredictable and occasionally awkward times (if at all). This presents a whole new challenge in terms of establishing invariants.
Consider, for example, the case of a mutex. In C++ I can encapsulate the acquisition and release of the mutex in an object (for an example of this, see boost::mutex::scoped_lock at www.boost.org), and know for certain that I will own the mutex object for the duration of the scope of the locking object. This invariant is maintained even in the presence of exceptions, break or continue statements, early returns, or other surprises.
The net effect is that the code is (a) robust, (b) maintainable, and (c) easy to read.
Contrast:
with:
Okie dokie (pardon the bad formatting):
I think you'll find that there's no equivalent to the above in Java.
This may prove to be good reading, if you are interested in learning more.
Well put!
Another important consideration is that where the programmer has the expectation that his garbage will be cleaned up for him, he will tend to assume that all of his resources will be cleaned up. This is clearly not the case. The seminal example for me was the use of database query result sets in C# - if you don't explicitly close them, they tend hang around, and the next time you try to perform a query on the same connection, you'll as likely as not get an exception. Surprise!
Also, as some other posters have pointed out, not all garbage collection is automatically bad. It works pretty well in Lisp, Scheme, Haskell, and friends. However in the cases of Java and C# it is certainly detrimental, as it disables the only really effective mechanism for managing resources in those languages - destructors.
Perhaps the thing to do is introduce an analogue for Lisp unwind-protect mechanisms. I suggested this a while back on the Java community forums, in the form of having sentry objects with the lifetime semantics of C++ automatic objects. Someone made the suggestion that the volatile keyword could be twisted to serve this purpose.
...sell SCO stock short. Anybody over there in the States want to be my broker?
In Soviet Russia, you say Da-Nyet. In South Africa, it's No-Ja (no-yes), or if you're really trying to make a point, "Ja Well No Fine", or "No Ja Well Fine" or any other combination of the above. Basically, it's an emphatic way of saying, "whatever".
As some of you inferred (and others didn't), the OpenGL requirements are purely on the UI side ;-).
My concern about interface contracts was this: it is very easy to accidentally change a .NET interface, since they aren't explicitly separated from the code. However, it should be possible to just make a bunch of read-only interface definitions in a common directory.
I think the biggest issue is (sadly) rapid development, and it is here that .NET establishes a clear dominance over the CORBA route. For the record, I love CORBA - IMHO it's the greatest middleware technology available.
Our cross platform requirement is not critical - we will likely not deploy the client-side on *nix for some years, and the back-end is of course much easier to port.
I am very concerned at the thought of having to host my services in IIS. Then again, connections are managed by a fairly thorough cryptographic challenge process.
Not an easy decision! :-)
I think NASA's current paralysis can be explained in part by their attitude towards money. What I have in mind is the famous space pen story - the Americans spend millions of dollars developing a space-pen, the Russians use a pencil. The article makes some interesting comparisons between the two programs, and it seems that the very budgetary constraints that are causing the Russian program to decay were the driving force behind some of its better/safer innovations. The Russians have always done clever things on a shoe-string, whereas the Americans have tended to go for the white elephants. Perhaps NASA should employ some of those Russian rocket scientists? IN SOVIET RUSSIA.... naah.
Another big one which you've missed is the GTK. It has a glarea module for OpenGL drawing areas, and has the advantage of a very strong design. On the other hand, since your focus is on building an OpenGL-based system, why bother with the overhead of a widget set at all? Don't reject the idea out of hand. Not having a pre-designed widget set will force you to think carefully about your interface. In my opinion, this is the major shortcoming of most commercial modelling systems - a counter-intuitive UI.