In C and C++, on the other hand, dangling pointers are a common and routine source of problems; in C++ especially, dangling pointers tend to creep up in all sorts of unexpected ways.
Dangling pointers are not nearly as much of an issue in C/C++ development as made out to be. They are an issue for people that don't understand pointers. But I would say that for the majority of C/C++ programmers that are not inexperienced they are not an issue.
You can interface any language to any OS regardless of the API and documentation
Only if your language has a suitable FFI or if interfacing with an OS is actually a language feature. Some high level languages do not have such an FFI, and in many high level languages the FFI is cumbersome to use.
That is an issue of the language you are using, not the language the OS is written in. Thus they are niche use languages.
OS documentation usually assumes the programmer will be using the same language that the API is written for (nothing else would make sense), which adds yet another hurdle for programmers using another language.
If you know how to use documentation that is not a hinderance. Writing Windows Scripts in JavaScript with Windows Scripting Host (WSH) is a pain because the documentation for WSH primarily written for use with VBScript. Yet it is not impossible to use JavaScript, Perl, or Python with WSH - not even very hard; just a bit more painful as you have to figure out a couple things. (Personally I prefer WSH+JS over WSH+VBscript.)
I am not saying that it is impossible, I am saying that it is harder to do and that there is an advantage to using the same language that the OS was written in. OSes have been written in Lisp in the past -- and unsurprisingly, most of the applications for those OSes was also written in Lisp (as opposed to some ML, Ada, or C++).
It's advantage is only in not having to write the Language Bindings for other languages. Many toolkits do that kind of things. It's just a task that has to be done to use languages on top of those OSes.
The reason that C and C++ continue to be popular - even in the face of C# and Java - is that they enable the programmer to actually get their tasks done because of how flexible the language is. What language fix-its call ambiguities are actually strengths for C and C++.
Except that C++ doesn't limit undefined behavior to situations that make sense -- for example, converting from a numeric type to a pointer type (this may not make sense on all architectures, but it does make sense on some). In C++, you have undefined behavior that could not possibly make sense no matter what architecture you are using.
Again, it depends on what you are doing. The memset() and memcpy() functions takes a void pointer; would it make sense to write an infinite number of them for each type? No. Yet they are very fast ways to clear and copy data and data references. Misused, they can wreak havoc.
Converesly, C# and even Managed C++ (C++/CLI) which tries to solve problems related to the misuse of functions like memset()/memcpy() makes it very difficult to copy a buffer of data in at least some situations - e.g. sending it to the network. So instead of having a send(), one has to convert the first chunk to a integer and then use pointer arithmetic to copy the whole buffer.
In what system does it make sense to allow control flow to reach the of a non-void function?
You do realize that compilers notify programmers about that?
And of course, there are ways to set up the function so that the return value is there without the compiler really knowing about it - but then you're getting into Obfuscated C territory.
And there are also times when the API changes but you can't really change it - so documentation gets update (hopefully) to matc
Personally I have no problem with them using a dog, as long as the dog is willing to testify in court with regard to the accuracy of their nose.
If the dog could do that, then it'd also be capable of suing the police for getting it hooked on the substances to start with. That is, after all, how substance detection dogs work - they get them addicted to the substances.
Says someone whose obviously never worked with MS APIs.
No, they're much worse than that.
Yes, I've worked with MS APIs. Yes, there are a good number that haven't really changed that much on the Desktop or Server platforms in a while; but each version of Windows does introduce subtle differences, and Microsoft's mobile platform is much worse in the changes.
Try writing a REPL for C++, and see how well that works for you.
I've done that quite a bit in both C and C++ without issues - and I'm not talking about doing things using toolkits such as Gtk, Qt, MFC, etc. Then again, I'm more a fan of Defensive Programming and Secure Programming...
The difference is that the solutions written in high-level languages are fast, closer to optimal (or actually optimal), and will not bog programmers down with debugging low-level pointer mechanics.
Any time I hear this argument, I know the writer/commentator is usually full of it. Namely because no matter what language you use, you'll end up with those kinds of issues in some form. It's just a matter of how easy it is to actually do something about it or even diagnose that that is the issue.
Comparatively C/C++ have continued to been used for a majority of application development
Which has more to do with the fact that most popular OSes are written in C or C++, and have APIs and documentation written for those languages.
It has nothing to do with that. You can interface any language to any OS regardless of the API and documentation. It's done by defining to the language the interface in a way that both understand and agree on - sometimes requiring intermediate steps to make the switch. But it is not impossible. The Windows API actually has numerous calls that use the PASCAL calling convention as opposed to the C Calling convention; yet that does not prevent people from using those APIs in C, C++, C#, Visual Basic, or number of other languages.
The reason that C and C++ continue to be popular - even in the face of C# and Java - is that they enable the programmer to actually get their tasks done because of how flexible the language is. What language fix-its call ambiguities are actually strengths for C and C++.
Were it not for these historical realities, C and C++ would already be an obscure, legacy languages like COBOL, comfortably placed at the tail end of jokes told on sites like Slashdot. C and C++ are "good enough" languages -- just good enough to accomplish what their creators and users are trying to do, but still inferior as languages.
C, and its extentions C++ and object-C, have withstood history because they have met and exceeded their target goals. They were designed as systems languages - designed for doing operating systems and systems applications, and that design continues to match the needs of that field. Their design also enables them to exceed being simply relegated to systems and build the rest of the user experience as well. It's little wonder that they are there and are still around. It only amazes the people who don't have much clue about systems programming.
I am Lisp programmer
That explains a lot. Lisp is like writing for the Obfuscated C contest in everything you do. It serves little to no purpose in real world computing, code maintainance, etc. Yes, it serves a purpose for some fields and does that well, but that's it.
So what is C++ doing that is so special? What are you doing with templates that even compares to Lisp metaprogramming? Where are the programming languages being embedded in C++? It takes a new C++ compiler to get a simple feature like lexical closures in C++; yet it is possible to implement a completely new Lisp dialect using only macros in an existing Lisp, without requiring a new Lisp compiler (e.g. Qi).
Lisp, as you note, is a meta programmer - more akin to Java and Smalltalk in that it runs in a virtual machine. Like SmallTalk the language itself defines the virtual machine so writing a new function extends the functionality of the VM and thereby the language. The nature of the virtual machine itself is a simple interpreter - like running JavaScript in a web browser with the V8 engine. However, these very features - the v
Languages like C and C++ will never go the way of the Dodo as they fill an area of computing that no other language has been capable of achieving nearly as well
What would that niche be, exactly? Time and time again I hear people say that C or C++ is the best language for some situation, but I am not really sure what that situation is. There are low-level languages that do not have so many kinds of undefined behavior and which are easier to formally analyze. There are certainly high-level languages that beat C and C++. CL-PPCRE is twice as fast as libpcre, and high level languages are being used in demanding environments where speed, reliability, and optimal solutions are required (Orbitz, Galois inc., various banking and investment companies' analysis tools, DART, etc.).
So what is that compelling reason to keep writing C and C++ code? Legacy code is all that comes to mind, and all it will take is a major shift in how computers are used to wipe away most of that legacy code. There is a reason that most software is not written in assembly language (and outside of a few very specific cases, hand-rolled assembly tends to be slower than what a compiler produces).
Embedded environments, systems development, OS development, to name just a few.
Most High Level Languages don't like it when a pointer is set to ZERO (aka NULL), yet there are some situations where that is a valid pointer, typically in the kernel. For example, the Interrupt Table on all modes of the x86 processor family (e.g. 8-bit, 16-bit, 32-bit, 64-bit) is stored at address 0x0; if you need to reference the interrupt table then you need to use a pointer that validly points to that address. If you cannot reference such a pointer then the language is useless for that kind of development - e.g. OS Kernel Development, Device Driver Development, etc.
Yes, one could write assembly to manage those gaps, but why when there is no need to? (Yes, the Linux Kernel uses C code for those things IIRC.)
That is the same reason that C and C++ will be in the same bucket as COBOL in the future. It is going to be far too difficult to use C, C++, Java, etc. express solutions to the big software problems we'll be solving over the next decade, and it is going to be even harder to express efficient solutions to those problems (in both the running time and optimal solution sense).
People have been saying that for a long time and it simply hasn't come to fruition; yet it is the ambiguities within C/C++ that allows it to continue to meet the needs.
Language developers have tried to lock down languages, eliminating ambiguities only to have those language relegated to small niches in the market since they are not flexible enough for most application development. Comparatively C/C++ have continued to been used for a majority of application development precisely because you can utilize the ambiguities in the languages to achieve some remarkable things that the language developers couldn't have thought of at the time.
It's kind of like War. You maintain a strong centralized command, and no one under you knows what to do when their superior officer is taken out by the enemy; or you play like the European contingents did in the 1700's and 1800's and do line formations where you just shoot at each other until one side doesn't have enough people and then you charge them, following the rules of War without any thought to what you're doing - and not even trying to protect yourself against the enemy. Or you utilize a highly decentralized command where each unit knows its goals, and the general big picture; and is fully charged with them and given the power to do what they want to achieve it - the officer is taken out and someone else steps up to take charge.
All the languages that try to lock down how things are done are like the highly centralized military armies following the first two examples. They'll do well as long
Languages like C and C++ will never go the way of the Dodo as they fill an area of computing that no other language has been capable of achieving nearly as well. They will oscillate in how much they get used in other areas - and in full application development - as people try other things (e.g. D, Java, C#); but will never actually go away.
Exceptions are intended to be used when a program hits unexpected or fatal issues which cannot be handled locally, and often the low-level library code isn't in a position to be able to judge whether something qualifies as worthy of an exception or whether it's an expected part of the processing cycle and can be safely be ignored.
Exceptions are very much overused and very well misunderstood. They are one form of returning errors with additional information.
Essentially you have several choices on how to return errors:
1. Return and do nothing about it - no information, etc.
2. Return an error code that needs to be looked up for a user-readable string to log and/or display.
3. Generate an exception - which contains an exception type and a user-readable string.
Now #1 is absolutely the worst thing to do as nothing will know about the error. This is kind of what Compaq did with their floppy controllers back in the 1990's - and they ended up in a big lawsuit (and lost) over it. So while it's an option, its not a viable option.
#2 is what the standard C library does. Many OO programmers don't like it because you have to query for the strings, and its more Functional programming in form.
#3 tends to be favored by OO programmers as things are encapulated into objects/structures when the error returns.
But, #3 is also the most abused as programmers tend to handle a few cases, but then just let most of the exceptions fall thru to the caller. Except, typically the caller won't be able to do much about the exception at all because the farther up the stack the exception has to go to get handled, the less ability that the "caller" will have to do anything about it - so #3 tends to become what you describe since the error ends up so far removed from what generated it that nothing can be done even when something could have actually been done in the first frame or two around the actual error. This issue is due to (i) the laziness of the programmers at each frame level, and (ii) the indefiniteness of how to actually handle exceptions.
That is, to handle an exception properly you have to capture every kind of possible exception that could be thrown by the code you are wrapping the in the try block. However, programmers are lazy so they only handle the ones they want to or know about, thus others fall through to next frame up the stack, making the next level that much harder to capture the exceptions on. But this is also the nature of exceptions as each different kind of error can have a different kind of exception - there's an exception for memory errors, for file i/o errors, for general i/o errors, for object recognition errors, and so forth. So once you start using exceptions you start building up tens of different exceptions you have to watch out for.
At least #2 was consistently designed even if not consistently handled - that is, the return code was always the return code and you might have had to check errno as well, but that was about it. Programmers might have not checked the return codes and just directly checked errno, or they might not have done that at all; but it was generally a lot simpler to track down and how hard it was was dependent on how lazy you were when you wrote the code.
Take for example asking to open a file for reading and the file not being available for some reason. If I'm just copying a large directory structure then I can reasonably expect to not be able to open a few files due to permissions and, while I'll likely want to log these and display them, treating it as an exception wouldn't be suitable. If my code is part of an online application and it was failing to open a configuration file which it needed to connect to the database then the error would be worthy of promoting to an exception if it could not rectified in the code which detected it. Ultimately though for this type of 'It could be serious, it could be nothing' then the decision should be lef
It would help if we actually had a left wing. Currently, we've got a center-right and far-right wing. I'm admittedly on the far-left, making me a bit out of step with the rest of the country, but it's deeply frustrating to any socialist when people call Barack Obama, a center-right politician, a Marxist or socialist.
Obama is very friendly to Wall Street. Very, very friendly.
True, compared to most of the world, the far right in the US (typically on the West Coast - California, Oregon, and Washington State) are a lot closer to center than those that are far right in Europe and Asia. That's in part due to the U.S. Constitution which does limit how far right or left the country can go - Nazi/Facist/Stalinist/Marxist forms of government would all be equally disallowed since they would all be unconstitutional forms of government. So no matter how much Obama may want to transform the US into a Marxist state, he can't by law.
But that's kind of true in the US too. The most conservative in the US are typically along the East Coast - most of the states east of the Mississippi River, and someone that is far right on the East Coast is either center or center-right on the West Coast; while someone that is right-wing on the left coast is typically center or center-left on the East Coast. The mid-west (between the Mississippi and the Rocky Mountains) tends to be more center, but still probably right leaning.
That is simply, factually, incorrect. Win8, including Windows RT, supports sideloading. It's free and can be enabled via a simple command in Powershell. Third-party software must be packaged as.appx bundles, but it doesn't have to be approved for distribution in the app store. In fact, one explicit use case for unlocking Windows RT devices in this manner is to allow installing corporate or other organization-internal apps.
Android and iOS support sideloading too. However, your average Joe user will not understand that or be capable of it. The fact that you would have to go to the PowerShell is even worse - since now you're doing things that even most Windows Programmers don't do - e.g. it's there for the corporates not your average user.
That is indeed true -- the differences is that companies (tend) to go out of business if they don't value their product, i.e. fix bugs.
Maybe the point is open is just as bad as closed but open has one small advantage: transparency.
In the end, that is what will eventually win out.
That, and sharing of software / algorithms.
Agreed. With Open you have the ability to get your bugs fixed in spite of the company going out of business. Of course, if you don't fix enough relevant bugs, then you will lose your customers (users) too, or someone will fork it and fix them for you.
As great as open source is that indeed is one of the two elephants in the room (the other being documentation*.) Bugs get completely ignored as new versions get rolled out and then later marked as "Won't Fix". Firefox fixing their memory leak "any day now" is the running joke.
It's no different from commercial version in that respect; only commercial software vendors won't communicate that they're not going to fix it or that its a bug at all to start with, and you have no visibility to their bug databases.
And, FYI, many security vulnerabilities present in Win7 have been reported or related to reported bugs in Windows going back over 15 years.
It does win on flash storage. Of course the amount of that storage taken up by each relevant OS and required software is not considered, but it's probably not significantly different. Hopefully this will drive Apple to actually stop pissing about profiteering from including a crappy amount of flash memory in the iPad by default.
It is also manufacturer dependent.
For example, my Nexus One has 512MB Flash; the OS takes ~300MB of it, leaving ~200MB for me; but I can also pop-in a microSD card up to 32GB - which you cannot do on an iPhone. However, the Kindle and Nook while they supply a 16 GB flash drive, and take 1 GB for the OS, they also take 12 GB for content from their respective stores; ultimately leaving the user with only 1 or 2 GB for content from other sources. I don't know how Apple manages the space. Needless to say, those things make a big difference.
They will use the tech specs to show that their new device is faster than the old one. But not comparing it to another product. Why? First when you compare different architectures you are comparing apples with oranges.
The available features is really more important to purchase a Table. What do you get for your money in terms of expandability, experience, future use.
Only to a degree. Technical specifications for everything other than the processor speed are still relevant. Does it have 802.11a/b/g/n, WiMax? how much storage? how much is reserved for the OS versus user? etc, etc.
One reason I have not yet bought a Kindle or Nook is due to their allocation of disk space solely for Amazon/BN purchased content. When I bought my Nexus One with its 6 megapixel camera, the top of the line iPhone only had a 2 megapixel camera. So there are quite a few technical specifications that are really valid in the comparison.
I give people OpenOffice. While my Linux computers (Gentoo and Kubuntu) have LibreOffice on them for the time being, I'll be moving them back to OpenOffice once an AOO package is available.
The people that used Ethereal were not tied to brands; further, IIRC there was a legal reason for the name change and the people that used Ethereal would have been aware of the reasons behind it.
Or Windows 98 to Windows Millenium Edition. That was a kind of name change. Maybe not the luckiest one. XP to Vista to 7 and 8.
While (as you admit) it's just a suffix change, people understood that those suffixes (95, 98, 98SE, ME, XP, Vista, 7) were just version branding. So they didn't think twice of it. The brand they were buying, however, was Windows and Microsoft.
That was a suffix change, this (*Office*) is a prefix. Not so different but I understand your concerns. Just tell them the development team moved to a new "home" and changed name. If they want to know more, development on the original OpenOffice code stagnated for a while and eventually restarted this year.
The OpenOffice vs. LibreOffice name change is quite a bit harder to instill - especially if they ask the reason, and even more so since OpenOffice is still around.
OpenOffice will probably (probably already has) get the larger brunt of resources behind it than LibreOffice will (has).
If you don't think tagging people and tracking their every move electronically is oppressive there are other reasons to be against it.
Yep, the show Numb3rs did an episode that way where one of the gunman (having entered through the broken metal detector that was down for maintenance) used the RFIDs to track certain targets...just wait until it happens in real life.
Its why the shuttles ran off of 386's, and the current mars rover uses something kin to a 233mhz G3, now all of a sudden we can stick a super-computer on the moon? Set aside the repair bill when it blows something, how many radiation hardened super-computers are available, and more importantly how old are they?
Well, you're building on the moon - so you need a building to store it in. That building itself can be sufficiently made to be shielded from the radiation; even if on the surface; let alone partially or wholly underground. So I don't think radiation hardened components would be an issue as you would only need them near the access points - to control the doors, pressurization, etc. You're bigger issue with the building will be protecting it against the various metorite impacts that the moon regularly gets as it doesn't have an atmosphere for them to burn up in.
So, you're biggests costs to such a venture are going to be: (i) building the building to store it in, and (ii) transporting and maintaining the equipment on the moon. You'll also need a re-usuable radiation hardened capsule that can keep its fragile contents intact to deliver the components without them being destroyed on the way, and all the construction equipment necessary to assemble (and even possibly build) the building to start with.
In the end, you're essentially advocating a Lunar base, manned by a few people at least periodically if not full time.
You don't even seem to know the basic rules of the road.
There's a lot more to knowing the rules of the roads and participating safely than simply knowing who has the right of way.
And just because you have the right of way, does not mean you are not at fault for using it. It's called contributorynegligence. If you fail to do something that could have stopped the problem from occurring then you are partially at fault as well. It doesn't excuse the other individual, but however much they are at fault doesn't excuse your negligence in the situation either.
IANAL, but that's part of how fault is determined.
your statement makes no sense: they're talking about a situation where all the fault is entirely and utterly 100% on one side: car drivers who pull out without looking for cyclists.
Except that that is still not a situation where 100% of the fault is the drivers. It is just a much your own (the cyclist's own) responsibility to make sure that they don't get in the way of a vehicle too. If you're crossing a road - it's your job to make sure someone isn't going to pull out when you do; same with a drive way, etc.
And it's not different from whether you're walking/running/jogging/skating or driving a car/truck/semi.
The situations where it is 100% the fault of the driver is when they're not even attempting to stop to look for any traffic - e.g. running the red light at 55 MPH, etc.
and it's not a game. if you get hit by one you don't get to shout "no fair" becuse you're dead.
No, it's not a game; and fairness has no role in the matter.
Whether you live or die is not simply up to others. It's up to you and how much responsibility you take for your own actions. Take the responsibity to make sure you're in the right place, paying attention to what is going on around you, following the laws, etc. and you'll find you won't get into those situations that may cost you your life.
You can't make assumptions about what vehicles are going to do - whether walking or driving.
The problem is, too many don't want to take responsibility. They want to blame everyone else.
Is it the driver's fault when someone runs out in the road in front of them and gets hit? Certainly to a degree, but the vast majority of the blame lies with the person who ran out into the road to start with. It's no different for cyclists.
Slashdot Mirror
In C and C++, on the other hand, dangling pointers are a common and routine source of problems; in C++ especially, dangling pointers tend to creep up in all sorts of unexpected ways.
Dangling pointers are not nearly as much of an issue in C/C++ development as made out to be. They are an issue for people that don't understand pointers. But I would say that for the majority of C/C++ programmers that are not inexperienced they are not an issue.
You can interface any language to any OS regardless of the API and documentation
Only if your language has a suitable FFI or if interfacing with an OS is actually a language feature. Some high level languages do not have such an FFI, and in many high level languages the FFI is cumbersome to use.
That is an issue of the language you are using, not the language the OS is written in. Thus they are niche use languages.
OS documentation usually assumes the programmer will be using the same language that the API is written for (nothing else would make sense), which adds yet another hurdle for programmers using another language.
If you know how to use documentation that is not a hinderance. Writing Windows Scripts in JavaScript with Windows Scripting Host (WSH) is a pain because the documentation for WSH primarily written for use with VBScript. Yet it is not impossible to use JavaScript, Perl, or Python with WSH - not even very hard; just a bit more painful as you have to figure out a couple things. (Personally I prefer WSH+JS over WSH+VBscript.)
I am not saying that it is impossible, I am saying that it is harder to do and that there is an advantage to using the same language that the OS was written in. OSes have been written in Lisp in the past -- and unsurprisingly, most of the applications for those OSes was also written in Lisp (as opposed to some ML, Ada, or C++).
It's advantage is only in not having to write the Language Bindings for other languages. Many toolkits do that kind of things. It's just a task that has to be done to use languages on top of those OSes.
The reason that C and C++ continue to be popular - even in the face of C# and Java - is that they enable the programmer to actually get their tasks done because of how flexible the language is. What language fix-its call ambiguities are actually strengths for C and C++.
Except that C++ doesn't limit undefined behavior to situations that make sense -- for example, converting from a numeric type to a pointer type (this may not make sense on all architectures, but it does make sense on some). In C++, you have undefined behavior that could not possibly make sense no matter what architecture you are using.
Again, it depends on what you are doing. The memset() and memcpy() functions takes a void pointer; would it make sense to write an infinite number of them for each type? No. Yet they are very fast ways to clear and copy data and data references. Misused, they can wreak havoc.
Converesly, C# and even Managed C++ (C++/CLI) which tries to solve problems related to the misuse of functions like memset()/memcpy() makes it very difficult to copy a buffer of data in at least some situations - e.g. sending it to the network. So instead of having a send(), one has to convert the first chunk to a integer and then use pointer arithmetic to copy the whole buffer.
In what system does it make sense to allow control flow to reach the of a non-void function?
You do realize that compilers notify programmers about that?
And of course, there are ways to set up the function so that the return value is there without the compiler really knowing about it - but then you're getting into Obfuscated C territory.
And there are also times when the API changes but you can't really change it - so documentation gets update (hopefully) to matc
Personally I have no problem with them using a dog, as long as the dog is willing to testify in court with regard to the accuracy of their nose.
If the dog could do that, then it'd also be capable of suing the police for getting it hooked on the substances to start with. That is, after all, how substance detection dogs work - they get them addicted to the substances.
Windows 8 has only been available to devs for a little over 2 months in a capacity that is fit for production use.
Still can't download it - any version, even RTM - from my MSDN account.
Says someone whose obviously never worked with MS APIs.
No, they're much worse than that. Yes, I've worked with MS APIs. Yes, there are a good number that haven't really changed that much on the Desktop or Server platforms in a while; but each version of Windows does introduce subtle differences, and Microsoft's mobile platform is much worse in the changes.
Try writing a REPL for C++, and see how well that works for you.
I've done that quite a bit in both C and C++ without issues - and I'm not talking about doing things using toolkits such as Gtk, Qt, MFC, etc. Then again, I'm more a fan of Defensive Programming and Secure Programming...
The difference is that the solutions written in high-level languages are fast, closer to optimal (or actually optimal), and will not bog programmers down with debugging low-level pointer mechanics.
Any time I hear this argument, I know the writer/commentator is usually full of it. Namely because no matter what language you use, you'll end up with those kinds of issues in some form. It's just a matter of how easy it is to actually do something about it or even diagnose that that is the issue.
Comparatively C/C++ have continued to been used for a majority of application development
Which has more to do with the fact that most popular OSes are written in C or C++, and have APIs and documentation written for those languages.
It has nothing to do with that. You can interface any language to any OS regardless of the API and documentation. It's done by defining to the language the interface in a way that both understand and agree on - sometimes requiring intermediate steps to make the switch. But it is not impossible. The Windows API actually has numerous calls that use the PASCAL calling convention as opposed to the C Calling convention; yet that does not prevent people from using those APIs in C, C++, C#, Visual Basic, or number of other languages.
The reason that C and C++ continue to be popular - even in the face of C# and Java - is that they enable the programmer to actually get their tasks done because of how flexible the language is. What language fix-its call ambiguities are actually strengths for C and C++.
Were it not for these historical realities, C and C++ would already be an obscure, legacy languages like COBOL, comfortably placed at the tail end of jokes told on sites like Slashdot. C and C++ are "good enough" languages -- just good enough to accomplish what their creators and users are trying to do, but still inferior as languages.
C, and its extentions C++ and object-C, have withstood history because they have met and exceeded their target goals. They were designed as systems languages - designed for doing operating systems and systems applications, and that design continues to match the needs of that field. Their design also enables them to exceed being simply relegated to systems and build the rest of the user experience as well. It's little wonder that they are there and are still around. It only amazes the people who don't have much clue about systems programming.
I am Lisp programmer
That explains a lot. Lisp is like writing for the Obfuscated C contest in everything you do. It serves little to no purpose in real world computing, code maintainance, etc. Yes, it serves a purpose for some fields and does that well, but that's it.
So what is C++ doing that is so special? What are you doing with templates that even compares to Lisp metaprogramming? Where are the programming languages being embedded in C++? It takes a new C++ compiler to get a simple feature like lexical closures in C++; yet it is possible to implement a completely new Lisp dialect using only macros in an existing Lisp, without requiring a new Lisp compiler (e.g. Qi).
Lisp, as you note, is a meta programmer - more akin to Java and Smalltalk in that it runs in a virtual machine. Like SmallTalk the language itself defines the virtual machine so writing a new function extends the functionality of the VM and thereby the language. The nature of the virtual machine itself is a simple interpreter - like running JavaScript in a web browser with the V8 engine. However, these very features - the v
Languages like C and C++ will never go the way of the Dodo as they fill an area of computing that no other language has been capable of achieving nearly as well
What would that niche be, exactly? Time and time again I hear people say that C or C++ is the best language for some situation, but I am not really sure what that situation is. There are low-level languages that do not have so many kinds of undefined behavior and which are easier to formally analyze. There are certainly high-level languages that beat C and C++. CL-PPCRE is twice as fast as libpcre, and high level languages are being used in demanding environments where speed, reliability, and optimal solutions are required (Orbitz, Galois inc., various banking and investment companies' analysis tools, DART, etc.).
So what is that compelling reason to keep writing C and C++ code? Legacy code is all that comes to mind, and all it will take is a major shift in how computers are used to wipe away most of that legacy code. There is a reason that most software is not written in assembly language (and outside of a few very specific cases, hand-rolled assembly tends to be slower than what a compiler produces).
Embedded environments, systems development, OS development, to name just a few.
Most High Level Languages don't like it when a pointer is set to ZERO (aka NULL), yet there are some situations where that is a valid pointer, typically in the kernel. For example, the Interrupt Table on all modes of the x86 processor family (e.g. 8-bit, 16-bit, 32-bit, 64-bit) is stored at address 0x0; if you need to reference the interrupt table then you need to use a pointer that validly points to that address. If you cannot reference such a pointer then the language is useless for that kind of development - e.g. OS Kernel Development, Device Driver Development, etc.
Yes, one could write assembly to manage those gaps, but why when there is no need to? (Yes, the Linux Kernel uses C code for those things IIRC.)
That is the same reason that C and C++ will be in the same bucket as COBOL in the future. It is going to be far too difficult to use C, C++, Java, etc. express solutions to the big software problems we'll be solving over the next decade, and it is going to be even harder to express efficient solutions to those problems (in both the running time and optimal solution sense).
People have been saying that for a long time and it simply hasn't come to fruition; yet it is the ambiguities within C/C++ that allows it to continue to meet the needs.
Language developers have tried to lock down languages, eliminating ambiguities only to have those language relegated to small niches in the market since they are not flexible enough for most application development. Comparatively C/C++ have continued to been used for a majority of application development precisely because you can utilize the ambiguities in the languages to achieve some remarkable things that the language developers couldn't have thought of at the time.
It's kind of like War. You maintain a strong centralized command, and no one under you knows what to do when their superior officer is taken out by the enemy; or you play like the European contingents did in the 1700's and 1800's and do line formations where you just shoot at each other until one side doesn't have enough people and then you charge them, following the rules of War without any thought to what you're doing - and not even trying to protect yourself against the enemy. Or you utilize a highly decentralized command where each unit knows its goals, and the general big picture; and is fully charged with them and given the power to do what they want to achieve it - the officer is taken out and someone else steps up to take charge.
All the languages that try to lock down how things are done are like the highly centralized military armies following the first two examples. They'll do well as long
Languages like C and C++ will never go the way of the Dodo as they fill an area of computing that no other language has been capable of achieving nearly as well. They will oscillate in how much they get used in other areas - and in full application development - as people try other things (e.g. D, Java, C#); but will never actually go away.
Exceptions are intended to be used when a program hits unexpected or fatal issues which cannot be handled locally, and often the low-level library code isn't in a position to be able to judge whether something qualifies as worthy of an exception or whether it's an expected part of the processing cycle and can be safely be ignored.
Exceptions are very much overused and very well misunderstood. They are one form of returning errors with additional information.
Essentially you have several choices on how to return errors:
1. Return and do nothing about it - no information, etc.
2. Return an error code that needs to be looked up for a user-readable string to log and/or display.
3. Generate an exception - which contains an exception type and a user-readable string.
Now #1 is absolutely the worst thing to do as nothing will know about the error. This is kind of what Compaq did with their floppy controllers back in the 1990's - and they ended up in a big lawsuit (and lost) over it. So while it's an option, its not a viable option.
#2 is what the standard C library does. Many OO programmers don't like it because you have to query for the strings, and its more Functional programming in form.
#3 tends to be favored by OO programmers as things are encapulated into objects/structures when the error returns.
But, #3 is also the most abused as programmers tend to handle a few cases, but then just let most of the exceptions fall thru to the caller. Except, typically the caller won't be able to do much about the exception at all because the farther up the stack the exception has to go to get handled, the less ability that the "caller" will have to do anything about it - so #3 tends to become what you describe since the error ends up so far removed from what generated it that nothing can be done even when something could have actually been done in the first frame or two around the actual error. This issue is due to (i) the laziness of the programmers at each frame level, and (ii) the indefiniteness of how to actually handle exceptions.
That is, to handle an exception properly you have to capture every kind of possible exception that could be thrown by the code you are wrapping the in the try block. However, programmers are lazy so they only handle the ones they want to or know about, thus others fall through to next frame up the stack, making the next level that much harder to capture the exceptions on. But this is also the nature of exceptions as each different kind of error can have a different kind of exception - there's an exception for memory errors, for file i/o errors, for general i/o errors, for object recognition errors, and so forth. So once you start using exceptions you start building up tens of different exceptions you have to watch out for.
At least #2 was consistently designed even if not consistently handled - that is, the return code was always the return code and you might have had to check errno as well, but that was about it. Programmers might have not checked the return codes and just directly checked errno, or they might not have done that at all; but it was generally a lot simpler to track down and how hard it was was dependent on how lazy you were when you wrote the code.
Take for example asking to open a file for reading and the file not being available for some reason. If I'm just copying a large directory structure then I can reasonably expect to not be able to open a few files due to permissions and, while I'll likely want to log these and display them, treating it as an exception wouldn't be suitable. If my code is part of an online application and it was failing to open a configuration file which it needed to connect to the database then the error would be worthy of promoting to an exception if it could not rectified in the code which detected it. Ultimately though for this type of 'It could be serious, it could be nothing' then the decision should be lef
It would help if we actually had a left wing. Currently, we've got a center-right and far-right wing. I'm admittedly on the far-left, making me a bit out of step with the rest of the country, but it's deeply frustrating to any socialist when people call Barack Obama, a center-right politician, a Marxist or socialist.
Obama is very friendly to Wall Street. Very, very friendly.
True, compared to most of the world, the far right in the US (typically on the West Coast - California, Oregon, and Washington State) are a lot closer to center than those that are far right in Europe and Asia. That's in part due to the U.S. Constitution which does limit how far right or left the country can go - Nazi/Facist/Stalinist/Marxist forms of government would all be equally disallowed since they would all be unconstitutional forms of government. So no matter how much Obama may want to transform the US into a Marxist state, he can't by law.
But that's kind of true in the US too. The most conservative in the US are typically along the East Coast - most of the states east of the Mississippi River, and someone that is far right on the East Coast is either center or center-right on the West Coast; while someone that is right-wing on the left coast is typically center or center-left on the East Coast. The mid-west (between the Mississippi and the Rocky Mountains) tends to be more center, but still probably right leaning.
Is it just me, or does everyone on the entire internet claim to have an IQ ~150? Where is the other 99.9663019177% of the population?
Not on Slashdot; not writing computer software.
That is simply, factually, incorrect. Win8, including Windows RT, supports sideloading. It's free and can be enabled via a simple command in Powershell. Third-party software must be packaged as .appx bundles, but it doesn't have to be approved for distribution in the app store. In fact, one explicit use case for unlocking Windows RT devices in this manner is to allow installing corporate or other organization-internal apps.
http://msdn.microsoft.com/en-us/library/windows/apps/Hh974578.aspx
Android and iOS support sideloading too. However, your average Joe user will not understand that or be capable of it. The fact that you would have to go to the PowerShell is even worse - since now you're doing things that even most Windows Programmers don't do - e.g. it's there for the corporates not your average user.
That is indeed true -- the differences is that companies (tend) to go out of business if they don't value their product, i.e. fix bugs.
Maybe the point is open is just as bad as closed but open has one small advantage: transparency.
In the end, that is what will eventually win out.
That, and sharing of software / algorithms.
Agreed. With Open you have the ability to get your bugs fixed in spite of the company going out of business. Of course, if you don't fix enough relevant bugs, then you will lose your customers (users) too, or someone will fork it and fix them for you.
rename it Raving Rottweiler and I might give it a try.
That would be good...considering Rottweiler's brains get crushed by their skull as they grow older...thus making them go crazy.
As great as open source is that indeed is one of the two elephants in the room (the other being documentation*.) Bugs get completely ignored as new versions get rolled out and then later marked as "Won't Fix". Firefox fixing their memory leak "any day now" is the running joke.
It's no different from commercial version in that respect; only commercial software vendors won't communicate that they're not going to fix it or that its a bug at all to start with, and you have no visibility to their bug databases.
And, FYI, many security vulnerabilities present in Win7 have been reported or related to reported bugs in Windows going back over 15 years.
The fact that it is using Windows 8 (A desktop level OS?) means it may fill the void about software.
Except that Windows RT can't run x86 Windows apps since it uses an ARM processor.
Nor can it install software from sources other than Microsoft's app store.
It is also manufacturer dependent.
For example, my Nexus One has 512MB Flash; the OS takes ~300MB of it, leaving ~200MB for me; but I can also pop-in a microSD card up to 32GB - which you cannot do on an iPhone. However, the Kindle and Nook while they supply a 16 GB flash drive, and take 1 GB for the OS, they also take 12 GB for content from their respective stores; ultimately leaving the user with only 1 or 2 GB for content from other sources. I don't know how Apple manages the space. Needless to say, those things make a big difference.
They will use the tech specs to show that their new device is faster than the old one. But not comparing it to another product. Why? First when you compare different architectures you are comparing apples with oranges.
The available features is really more important to purchase a Table. What do you get for your money in terms of expandability, experience, future use.
Only to a degree. Technical specifications for everything other than the processor speed are still relevant. Does it have 802.11a/b/g/n, WiMax? how much storage? how much is reserved for the OS versus user? etc, etc.
One reason I have not yet bought a Kindle or Nook is due to their allocation of disk space solely for Amazon/BN purchased content. When I bought my Nexus One with its 6 megapixel camera, the top of the line iPhone only had a 2 megapixel camera. So there are quite a few technical specifications that are really valid in the comparison.
we all moved to LibreOffice
I give people OpenOffice. While my Linux computers (Gentoo and Kubuntu) have LibreOffice on them for the time being, I'll be moving them back to OpenOffice once an AOO package is available.
Ethereal to Wireshark.
The people that used Ethereal were not tied to brands; further, IIRC there was a legal reason for the name change and the people that used Ethereal would have been aware of the reasons behind it.
Or Windows 98 to Windows Millenium Edition. That was a kind of name change. Maybe not the luckiest one. XP to Vista to 7 and 8.
While (as you admit) it's just a suffix change, people understood that those suffixes (95, 98, 98SE, ME, XP, Vista, 7) were just version branding. So they didn't think twice of it. The brand they were buying, however, was Windows and Microsoft.
That was a suffix change, this (*Office*) is a prefix. Not so different but I understand your concerns. Just tell them the development team moved to a new "home" and changed name. If they want to know more, development on the original OpenOffice code stagnated for a while and eventually restarted this year.
The OpenOffice vs. LibreOffice name change is quite a bit harder to instill - especially if they ask the reason, and even more so since OpenOffice is still around. OpenOffice will probably (probably already has) get the larger brunt of resources behind it than LibreOffice will (has).
If you don't think tagging people and tracking their every move electronically is oppressive there are other reasons to be against it.
Yep, the show Numb3rs did an episode that way where one of the gunman (having entered through the broken metal detector that was down for maintenance) used the RFIDs to track certain targets...just wait until it happens in real life.
Its why the shuttles ran off of 386's, and the current mars rover uses something kin to a 233mhz G3, now all of a sudden we can stick a super-computer on the moon? Set aside the repair bill when it blows something, how many radiation hardened super-computers are available, and more importantly how old are they?
Well, you're building on the moon - so you need a building to store it in. That building itself can be sufficiently made to be shielded from the radiation; even if on the surface; let alone partially or wholly underground. So I don't think radiation hardened components would be an issue as you would only need them near the access points - to control the doors, pressurization, etc. You're bigger issue with the building will be protecting it against the various metorite impacts that the moon regularly gets as it doesn't have an atmosphere for them to burn up in.
So, you're biggests costs to such a venture are going to be: (i) building the building to store it in, and (ii) transporting and maintaining the equipment on the moon. You'll also need a re-usuable radiation hardened capsule that can keep its fragile contents intact to deliver the components without them being destroyed on the way, and all the construction equipment necessary to assemble (and even possibly build) the building to start with.
In the end, you're essentially advocating a Lunar base, manned by a few people at least periodically if not full time.
And the computing output would be # of devices on the moon divided by number of media consumers on the moon....DIV BY ZERO....
You forget that it takes time for some policies to work their way through.
You don't even seem to know the basic rules of the road.
There's a lot more to knowing the rules of the roads and participating safely than simply knowing who has the right of way.
And just because you have the right of way, does not mean you are not at fault for using it. It's called contributory negligence. If you fail to do something that could have stopped the problem from occurring then you are partially at fault as well. It doesn't excuse the other individual, but however much they are at fault doesn't excuse your negligence in the situation either.
IANAL, but that's part of how fault is determined.
your statement makes no sense: they're talking about a situation where all the fault is entirely and utterly 100% on one side: car drivers who pull out without looking for cyclists.
Except that that is still not a situation where 100% of the fault is the drivers. It is just a much your own (the cyclist's own) responsibility to make sure that they don't get in the way of a vehicle too. If you're crossing a road - it's your job to make sure someone isn't going to pull out when you do; same with a drive way, etc.
And it's not different from whether you're walking/running/jogging/skating or driving a car/truck/semi.
The situations where it is 100% the fault of the driver is when they're not even attempting to stop to look for any traffic - e.g. running the red light at 55 MPH, etc.
and it's not a game. if you get hit by one you don't get to shout "no fair" becuse you're dead.
No, it's not a game; and fairness has no role in the matter.
Whether you live or die is not simply up to others. It's up to you and how much responsibility you take for your own actions. Take the responsibity to make sure you're in the right place, paying attention to what is going on around you, following the laws, etc. and you'll find you won't get into those situations that may cost you your life.
You can't make assumptions about what vehicles are going to do - whether walking or driving.
The problem is, too many don't want to take responsibility. They want to blame everyone else.
Is it the driver's fault when someone runs out in the road in front of them and gets hit? Certainly to a degree, but the vast majority of the blame lies with the person who ran out into the road to start with. It's no different for cyclists.