Text is not a magical thing that just works out of the blue. Text requires as much support as objects do. Text requires encoding specifications, fonts that reflect those encoding specifications, editors that understand those encoding specifications and use that fonts, etc.
Even if text is simple ASCII, you still need a program to print those bytes to the console. You still need ASCII, in the first place, to be understood by all subsystems in the same way. If you had two computers or two programs that used a different encoding, they couldn't talk to each other, even if text was all they exchanged. You still need a font. You still need a console display.
It just happens that text was there first before objects, and therefore the infrastructure to support text is already up and running. Had objects been invented first, you would not have said that text is the universal interface; you would have said that objects is the universal interface, because everyone would understand objects.
Is it sooo difficult to have the Metro UI on tablets and the classic UI on desktops? As a desktop user, I am not going to run Metro apps, because the mouse works better than touch in most cases.
So why do you have the Metro UI as the default for desktops? it doesn't make sense.
It's not the rule, of course. There are fat men who are bold. But, from what I see, the majority of bald men have little fat on their bodies; they are usually slim.
I do not understand how older people cannot code but they can be managers.
If the job of a manager is more difficult than the job of a programmer, then why is the older person incapable of being a programmer? if he can be a manager, then he can be a programmer, since management is more difficult then programming.
Or is it not?
Perhaps this situation (you are old, you can't code any more), is an indirect way to admit that programming is, in fact, more difficult than management: you can't do the more difficult job, so we put you in the easier one.
However, the above is not verified by the numbers: managers have bigger salaries than programmers, therefore management is considered more difficult than programming.
So, the question is: how come older people can do the most difficult of the tasks (i.e. management), but cannot do the easiest of the tasks (i.e. development)?
I am currently working on a Word document that has all the usual bells and whistles: tables, multiple styles, bullets, pictures, drawigs, etc.
It is awful.
Most of the time is spent moving the mouse around and switchings tabs.
Sure, it is easier to find the various commands with the Ribbon, but it takes a lot more time than toolbars. With toolbars, whatever you needed was there, you just had to move the mouse to reach it. Now, with the Ribbon, you have to move the mouse, click the appropriate tab AND move the mouse to the appropriate command.
Whoever designed the Ribbon is a complete moron. It now takes double the time to do the same work.
But anonymous classes is not a convenient way to do it. They require the definition of a super class or an interface, they require typing the super class or interface they implement, etc.
This new Java statement, C#'s blocks and C++'s destructors are all hacks that solve a problem that would not exist in the first place if those languages had lazy evaluation: the code that uses those resources could have been passed as a functor to another function that opened the resources, called the functor and then closed the resources.
It it amazing that in this day and age, language designers ignore language design and compiler basics this much.
Please, when you go around the moon, take some time to get some good photos of the Apollo missions remains. When I say "good photos", I mean photos that show stuff almost as good as they are shown on NASA's videos from the moon.
It would shut the Apollo conspiracy advocators up for good, and close this silly subject.
Perhaps the aliens have also made such a study and decided that it is best for them to stay silent too.
And thus we have the following paradox: while the galaxy has a lot of planets with intelligent life, none of them dares try communicate with others, fearing that the others will be so much more advanced than them that they will obliterate them.
This "intergalactic" fear should actually be one of the stages of development for any civilization that develops radio communication and early forms of space travel. Just like us, they suddenly realize that a vastly superior hostile civilization may be out there, looking for signals from other civilizations, and therefore decide to "keep it low".
And thus, there is no contact between civilizations in different planetary systems.
(Incidentally, I think that the above explains the Fermi Paradox: there are many intelligent life forms out there, none of which wants to contact the others).
but I've written commercial C++ code for years and I've not had memory management issues.
I can attest to that with some numbers: I am the only developer in a C++ realtime defense application that has 250K lines of code, and I don't have a single issue with memory from 2008 when I started using smart pointers. And the application does quite a lot of complicated things (at one point, more than 30 different threads are running at the same time).
Really, the difference smart pointers make is enormous.
Being a fully managed environment has nothing to so with being error prone or not. You can have a fully managed environment, and your application may stop working (either by a deadlock or an exception), and vice versa.
The actual scope of knowledge required to write safe C++ is small. It's mostly to use shared pointers and iterators properly. It can be comparable to the Java set of knowledge, where one needs to know how the collector finalizes objects in order to avoid deadlocks or null pointer exceptions.
The crashes are solely due to using C++ as C, i.e. manual memory management, C casts, pointer arithmetic and C arrays. If none of the C features are used, then C++ is as safe as the languages you mention.
Before modding me to oblivion, please hear what I have to say.
The whole concept of browser is wrong. Browsers are a good solution for serving static documents; it is not a good solution for delivering cross platform dynamic applications.
This article about HTML5 proves that no matter what functionality is hardcoded into the specifications, developers might need more or different functionality.
What is required for serving today's distributed world is a mechanism (a service) that does the following:
- lazy downloading of software components (data and code). Code and data are downloaded only when requested. The mechanism makes sure the code/data are cached locally, so as that if the network fails, the application is still usable.
The current technology fails at this because the downloaded software components can only be one of these:
a) Javascript, which comes with a lot of disadvantages (browser needs to have a Javascript interpreter/compiler, Javascript itself has lots of disadvantages etc).
b) a binary file that requires the installation and maintenance of an add on (flash, Java, etc), which in turn does its own maintenance, adding services to the core O/S etc.
All the above could be avoided with a unified component management mechanism.
- automatic versioning of components. Code components should be automatically versioned by the compiler, so as that the linker at the client side can request an updated component only if the available version is newer than the locally cached version. Downgrading would be automatic if the newer component's symbols do not match the symbols required by another component. The mechanism should keep the old versions of components around in case some component cannot work with the newest versions.
The current technology fails at this, because although the browsers check the version numbers of the add ons against the browser, user interaction is required for the acceptance of a solution (i.e. the users have to accept the new versions by clicking OK, meaning that they know if the new version is appropriate for them).
- both native and bytecode components. The component service should be available for native as well as bytecode components. The service will run a virtual machine, the definition of which should be a native component downloaded lazily and cached as described above.
The current technology fails at this, because it doesn't even have the concept of a component, let alone the concept of native or bytecode component. Browsers only know of addons and extensions, and each browser comes with its own addon and extension model.
- a binary (i.e. non-text) metadata protocol. All information exchanged over the network, including software components and data components, should be written in a unified metadata protocol. The protocol itself will not specify semantics, it will only specify structure. Think about this protocol as a binary version of JSON or XML.
The current technology fails at this, because all the used formats are text-based.
I know many people will disagree with the binary protocol and prefer a text protocol. The text protocol doesn't really offer any advantages over such a simple binary protocol. The main advantage of the binary protocol is speed, because of the much less data required to cross the wires compared to text. The main advantage of the text protocol is that the text buffers can be inspected as they are, but if the binary protocol is simple enough (as is JSON, for example), then very little work would be required to make a tool that displays the contents of a binary buffer.
Think about it this way: the cost of writing a tool that displays the above-described binary protocol's contents is extremely minimal when compared to the savings from using the binary protocol.
A unified communication language between computers is extremely necessary as the first basic step for inter-operation between computers: computers may not understand the semantics of the data, but at leas
Heavy lift rockets that can only be used once is a bad idea economically. What NASA needs to build in space is a non-landing spaceship that is used for travelling between planetary bodies of our solar system. It will be more expensive than a heavy lift rocket, but once it is up there, the cost of space travel for humans will be greatly minimized.
The spaceship could harness power from external resources like the Sun, and therefore help avoid carrying all that fuel to orbit, as with heavy lift rockets.
If we are to rewrite our software to fix flickering, why not change X to support buffering per window? two simple commands (enable buffering / switch buffer) would be more than enough.
If buffering was enabled, the X server would execute the drawing commands on the buffer, and then draw the complete buffer on the screen on switching buffers.
The Wayland people say "we should get rid of X, it is too complicated", but what they offer does not have X's features, and they say that most probably X will always be there. So why bother with Wayland?
Slashdot Mirror
MFC is shit and .NET requires a VM. Qt is a much better choice when all you need is a barebones GUI application executable programmed quickly.
Text is not a magical thing that just works out of the blue. Text requires as much support as objects do. Text requires encoding specifications, fonts that reflect those encoding specifications, editors that understand those encoding specifications and use that fonts, etc.
Even if text is simple ASCII, you still need a program to print those bytes to the console. You still need ASCII, in the first place, to be understood by all subsystems in the same way. If you had two computers or two programs that used a different encoding, they couldn't talk to each other, even if text was all they exchanged. You still need a font. You still need a console display.
It just happens that text was there first before objects, and therefore the infrastructure to support text is already up and running. Had objects been invented first, you would not have said that text is the universal interface; you would have said that objects is the universal interface, because everyone would understand objects.
Is it sooo difficult to have the Metro UI on tablets and the classic UI on desktops? As a desktop user, I am not going to run Metro apps, because the mouse works better than touch in most cases.
So why do you have the Metro UI as the default for desktops? it doesn't make sense.
It's not the rule, of course. There are fat men who are bold. But, from what I see, the majority of bald men have little fat on their bodies; they are usually slim.
I do not understand how older people cannot code but they can be managers.
If the job of a manager is more difficult than the job of a programmer, then why is the older person incapable of being a programmer? if he can be a manager, then he can be a programmer, since management is more difficult then programming.
Or is it not?
Perhaps this situation (you are old, you can't code any more), is an indirect way to admit that programming is, in fact, more difficult than management: you can't do the more difficult job, so we put you in the easier one.
However, the above is not verified by the numbers: managers have bigger salaries than programmers, therefore management is considered more difficult than programming.
So, the question is: how come older people can do the most difficult of the tasks (i.e. management), but cannot do the easiest of the tasks (i.e. development)?
I am currently working on a Word document that has all the usual bells and whistles: tables, multiple styles, bullets, pictures, drawigs, etc.
It is awful.
Most of the time is spent moving the mouse around and switchings tabs.
Sure, it is easier to find the various commands with the Ribbon, but it takes a lot more time than toolbars. With toolbars, whatever you needed was there, you just had to move the mouse to reach it. Now, with the Ribbon, you have to move the mouse, click the appropriate tab AND move the mouse to the appropriate command.
Whoever designed the Ribbon is a complete moron. It now takes double the time to do the same work.
But anonymous classes is not a convenient way to do it. They require the definition of a super class or an interface, they require typing the super class or interface they implement, etc.
This new Java statement, C#'s blocks and C++'s destructors are all hacks that solve a problem that would not exist in the first place if those languages had lazy evaluation: the code that uses those resources could have been passed as a functor to another function that opened the resources, called the functor and then closed the resources.
It it amazing that in this day and age, language designers ignore language design and compiler basics this much.
You see, the iPad does not play Flash Video ;-).
With all the things you describe, life in America seems extremely freightening. In comparison, life in Europe seems utopian, when compared to America.
If there is no such law, then what they are doing is illegal.
Just like Earth, a nice electromagnetic layer around spacecraft will do the trick.
Please, when you go around the moon, take some time to get some good photos of the Apollo missions remains. When I say "good photos", I mean photos that show stuff almost as good as they are shown on NASA's videos from the moon.
It would shut the Apollo conspiracy advocators up for good, and close this silly subject.
Perhaps the aliens have also made such a study and decided that it is best for them to stay silent too.
And thus we have the following paradox: while the galaxy has a lot of planets with intelligent life, none of them dares try communicate with others, fearing that the others will be so much more advanced than them that they will obliterate them.
This "intergalactic" fear should actually be one of the stages of development for any civilization that develops radio communication and early forms of space travel. Just like us, they suddenly realize that a vastly superior hostile civilization may be out there, looking for signals from other civilizations, and therefore decide to "keep it low".
And thus, there is no contact between civilizations in different planetary systems.
(Incidentally, I think that the above explains the Fermi Paradox: there are many intelligent life forms out there, none of which wants to contact the others).
but I've written commercial C++ code for years and I've not had memory management issues.
I can attest to that with some numbers: I am the only developer in a C++ realtime defense application that has 250K lines of code, and I don't have a single issue with memory from 2008 when I started using smart pointers. And the application does quite a lot of complicated things (at one point, more than 30 different threads are running at the same time).
Really, the difference smart pointers make is enormous.
Being a fully managed environment has nothing to so with being error prone or not. You can have a fully managed environment, and your application may stop working (either by a deadlock or an exception), and vice versa.
The actual scope of knowledge required to write safe C++ is small. It's mostly to use shared pointers and iterators properly. It can be comparable to the Java set of knowledge, where one needs to know how the collector finalizes objects in order to avoid deadlocks or null pointer exceptions.
Last I checked, you can crash just as well when e.g. a vector iterator becomes invalid as with raw pointers.
That is a choice made by STL. It's not the language that's at fault. There are (or can be) other collection libraries that are safe.
Heck, just count the number of times "undefined behavior" appears in the spec.
Most of the undefined behavior cases are corner cases and do not affect 99% of development, especially when libraries take care of the details.
You are wrong on quite a lot of points.
C++ does not have any garbage collections. Boehm's collector is unusable from C++ due to preprocessor tricks.
STL collections do not do bounds checking in the array operators or iterator ownership checking.
The crashes are solely due to using C++ as C, i.e. manual memory management, C casts, pointer arithmetic and C arrays. If none of the C features are used, then C++ is as safe as the languages you mention.
Before modding me to oblivion, please hear what I have to say.
The whole concept of browser is wrong. Browsers are a good solution for serving static documents; it is not a good solution for delivering cross platform dynamic applications.
This article about HTML5 proves that no matter what functionality is hardcoded into the specifications, developers might need more or different functionality.
What is required for serving today's distributed world is a mechanism (a service) that does the following:
- lazy downloading of software components (data and code). Code and data are downloaded only when requested. The mechanism makes sure the code/data are cached locally, so as that if the network fails, the application is still usable.
The current technology fails at this because the downloaded software components can only be one of these:
a) Javascript, which comes with a lot of disadvantages (browser needs to have a Javascript interpreter/compiler, Javascript itself has lots of disadvantages etc).
b) a binary file that requires the installation and maintenance of an add on (flash, Java, etc), which in turn does its own maintenance, adding services to the core O/S etc.
All the above could be avoided with a unified component management mechanism.
- automatic versioning of components. Code components should be automatically versioned by the compiler, so as that the linker at the client side can request an updated component only if the available version is newer than the locally cached version. Downgrading would be automatic if the newer component's symbols do not match the symbols required by another component. The mechanism should keep the old versions of components around in case some component cannot work with the newest versions.
The current technology fails at this, because although the browsers check the version numbers of the add ons against the browser, user interaction is required for the acceptance of a solution (i.e. the users have to accept the new versions by clicking OK, meaning that they know if the new version is appropriate for them).
- both native and bytecode components. The component service should be available for native as well as bytecode components. The service will run a virtual machine, the definition of which should be a native component downloaded lazily and cached as described above.
The current technology fails at this, because it doesn't even have the concept of a component, let alone the concept of native or bytecode component. Browsers only know of addons and extensions, and each browser comes with its own addon and extension model.
- a binary (i.e. non-text) metadata protocol. All information exchanged over the network, including software components and data components, should be written in a unified metadata protocol. The protocol itself will not specify semantics, it will only specify structure. Think about this protocol as a binary version of JSON or XML.
The current technology fails at this, because all the used formats are text-based.
I know many people will disagree with the binary protocol and prefer a text protocol. The text protocol doesn't really offer any advantages over such a simple binary protocol. The main advantage of the binary protocol is speed, because of the much less data required to cross the wires compared to text. The main advantage of the text protocol is that the text buffers can be inspected as they are, but if the binary protocol is simple enough (as is JSON, for example), then very little work would be required to make a tool that displays the contents of a binary buffer.
Think about it this way: the cost of writing a tool that displays the above-described binary protocol's contents is extremely minimal when compared to the savings from using the binary protocol.
A unified communication language between computers is extremely necessary as the first basic step for inter-operation between computers: computers may not understand the semantics of the data, but at leas
Or we, as humans, could ban economic activities in which money itself is traded as if it was a product.
But no, it makes too much sense.
Heavy lift rockets that can only be used once is a bad idea economically. What NASA needs to build in space is a non-landing spaceship that is used for travelling between planetary bodies of our solar system. It will be more expensive than a heavy lift rocket, but once it is up there, the cost of space travel for humans will be greatly minimized.
The spaceship could harness power from external resources like the Sun, and therefore help avoid carrying all that fuel to orbit, as with heavy lift rockets.
According to the article, if quantum dipoles are polarized, then tney produce an additional gravity field.
Does this mean that if this can happen artificially, we can control gravity?
If we are to rewrite our software to fix flickering, why not change X to support buffering per window? two simple commands (enable buffering / switch buffer) would be more than enough.
If buffering was enabled, the X server would execute the drawing commands on the buffer, and then draw the complete buffer on the screen on switching buffers.
The Wayland people say "we should get rid of X, it is too complicated", but what they offer does not have X's features, and they say that most probably X will always be there. So why bother with Wayland?
Sorry, couldn't resist.