I'm hard pressed to think of anything really innovative Microsoft has done in years -- mostly they look at what others are doing and copy it (or buy it).
I wasn't part of the X3J11 committee. I don't know. The issues with it are in the c-spec. I'm considering that an authoritative source. Feel free to do your own research beyond that. I'll take there word for it there was a problem.
That being said I know that even x86 violates the standards in several places. INT_MIN div -1 is supposed to be 0 but it yields SIGFPE. As for a compiler that does this correction. Microsoft Visual Studio 2005 which had a comment on this specific issue.
They don't have the same unsigned arithmetic. C wants a defined standard so the compiler has to often implement as a short function not a primitive operation.
I don't agree that's the only correct behavior. But regardless that's also easy to implement in an arithmetic library. Java handles unsigned arithmetic in the JVM fine. The debate is over whether to give direct access to CPU primitive unsigned operation.
Java has found some masterful ways of getting performance well above scripting engines for some things. They might have been able to pull it off with weird unsigned types. But ultimately the reason for C to have all these complex binary types is they encourage bit level thinking about programs. Java for safety reasons can't. I don't really see how a primitive unsigned type is useful for anything other than speed. Generally what people want unsigned for would be better to implement the way.NET does it where you get reach features so that 3 - 7 throw an exception rather than say returning 4 billion or 2 billion or something.
Take a look at any CPU architecture where the addition or subtraction isn't defined the same as the standard. The "addition" used by the C compiler is a short function. Similarly for subtraction... Just look at the assembler.
A lot of this conversation happened in the late 1980s during the X3J11 meetings in places like the discussion of limits.h as far as the standard. I'd say Plauger's book is a good source I don't know what's online.
I agree. I'd argue that C++ is more LISP like than Java. Certainly if you look at the research.microsoft group which does great LISPy things with language they often port it over to C# as their "mainstream language test".
I don't buy it. Java is a static typed language arguably moreso than the C's were. The LAMP paradigm is what created the dynamic languages by having huge numbers of people exposed to Perl-CGI and later PHP.
Almost all the programming I do I would rather use a Decimal data type rather than a float data type, but very few languages support it as a native data type.
Because CPUs don't support it in a system independent way. Also for finance there is rarely enough data to make efficiency on decimal make sense. Either there is a limited (say millions of rows) amount of data in which case a library is fine or there are huge swarms and or it needs to be recomputed frequently and it makes sense to convert the data to integer and store it that way.
Decimal types are really a holdover of a vision of computers doing math like humans on the CPU.
Java is cross platform. Unsigned arithmetic isn't cross platform. If you want primitive behavior that varies by platform in a language a lot like Java, C++ will be happy to speak to you.
For signed arithmetic JAVA uses CPU primitives. The result is that arithmetic operations happen often in 1 or a few simple operations (on a 3GHZ processor a simple operation =.33 nanoseconds). What I was saying above though is that these are done in CPU specific ways. Basically if you offer primitive unsigned ints you allow for some flexibility at the expense of introducing CPU specific behaviors which diminish cross platform.
It is easy to offer a unsigned types on the JVM, that's not an issue. But there is no particular reason to build that into the language you just build libraries that handle it if you want them. Unsigned ints would just be like any other non-CPU supported object with an arithmetic structure. However, if unsigned are virtualized, you could be looking at performance of 1/100th of the CPU.
I'm not sure how that connects to the GPs request. Anyway Gosling didn't include it because the behavior aren't defined in CPU independent ways.
32-unsigned 0 minus 32-unsigned 1 = ? where ? is CPU dependent. Some you'll 0xFFFF other 0x8001 others 0xFFFE. That's precisely the sort of thing JAVA was designed to abstract away. And if you don't want unsigned to be doing raw CPU arithmetic on primitives then you can just use a library.
Sure the classic discussion is in Mythical Man Month. Here (http://sequoia.cs.byu.edu/lab/files/pubs/Delorey2007a.pdf) is a paper from 2007 which has references to many of the classic discussion. And Brooks I believe cites the original FORTRAN vs. assembler tests.
There are lots of languages built on top of the JVM that can even use Java libraries which have totally different syntax. Clojure being a great example, and Scala another.
If you think that all programming languages are the same it is perhaps time you get out of your mom's basement and look at 60 years of efficiency studies which show much the opposite.
Or Google could itself organize an Android kernel which works back and forth with Linus the way RedHat maintains their own separate features kernels. That would allow Androidisms to be in their kernel but have it ported forward. The hardware vendors will hopefully get the spirt of the GPL at some point.
Embedded requires drivers Linux is a huge player Server requires drivers Linux is a huge player Android requires drivers Linux is the kernel Tizen will require drivers and Linux is the kernel of that too
So obviously the model does work. It doesn't work well for low end Windows hardware. The Linux community, including Linus has mostly given up on that community. Linux failed at its original goal of a desktop replacement for Windows and was hugely successful at a dozen others. The kernel group is not going to damager the more important products like server and embedded to do better running on $300 machines. They just don't care that much.
As for iOS it most certainly does use the Linux model as does OSX. And heck yeah a GPLed operating system does not want closed source components becoming crucial. If you disagree with the GPL, here is Microsoft's business card.
Slashdot Mirror
Spend some time at http://research.microsoft.com/ . They do a ton that is innovative in many areas.
I wasn't part of the X3J11 committee. I don't know. The issues with it are in the c-spec. I'm considering that an authoritative source. Feel free to do your own research beyond that. I'll take there word for it there was a problem.
That being said I know that even x86 violates the standards in several places. INT_MIN div -1 is supposed to be 0 but it yields SIGFPE. As for a compiler that does this correction. Microsoft Visual Studio 2005 which had a comment on this specific issue.
Wrap around is more likely to happen. 3 - 7 happens a lot. 1.2billion + 2 billion not so much. Anyway that's the reason Gosling didn't do it.
Java supports that in a library fine. Not an issue.
They don't have the same unsigned arithmetic. C wants a defined standard so the compiler has to often implement as a short function not a primitive operation.
Your HTML got screwed up. As far as signed (which I think you were asking about) I suspect what they want is sane subtraction 3 - 7 = -4.
If you "do it right" that's a library. Java supports libraries fine.
You should talk to the guy whose saying most CPUs do rollover as per the C definition.
I don't agree that's the only correct behavior. But regardless that's also easy to implement in an arithmetic library. Java handles unsigned arithmetic in the JVM fine. The debate is over whether to give direct access to CPU primitive unsigned operation.
Java has found some masterful ways of getting performance well above scripting engines for some things. They might have been able to pull it off with weird unsigned types. But ultimately the reason for C to have all these complex binary types is they encourage bit level thinking about programs. Java for safety reasons can't. I don't really see how a primitive unsigned type is useful for anything other than speed. Generally what people want unsigned for would be better to implement the way .NET does it where you get reach features so that 3 - 7 throw an exception rather than say returning 4 billion or 2 billion or something.
How are changes to compilers going to alter statistics on programmer efficiency?
Take a look at any CPU architecture where the addition or subtraction isn't defined the same as the standard. The "addition" used by the C compiler is a short function. Similarly for subtraction... Just look at the assembler.
A lot of this conversation happened in the late 1980s during the X3J11 meetings in places like the discussion of limits.h as far as the standard. I'd say Plauger's book is a good source I don't know what's online.
The well defined unsigned types in C quite often aren't primitives. They are a library though one built into the compilers.
I agree. I'd argue that C++ is more LISP like than Java. Certainly if you look at the research.microsoft group which does great LISPy things with language they often port it over to C# as their "mainstream language test".
I don't buy it. Java is a static typed language arguably moreso than the C's were. The LAMP paradigm is what created the dynamic languages by having huge numbers of people exposed to Perl-CGI and later PHP.
Because CPUs don't support it in a system independent way. Also for finance there is rarely enough data to make efficiency on decimal make sense. Either there is a limited (say millions of rows) amount of data in which case a library is fine or there are huge swarms and or it needs to be recomputed frequently and it makes sense to convert the data to integer and store it that way.
Decimal types are really a holdover of a vision of computers doing math like humans on the CPU.
Which is very slow. If you are going to do that sort of stuff why not just use a library why do you need it built in?
Java is cross platform. Unsigned arithmetic isn't cross platform. If you want primitive behavior that varies by platform in a language a lot like Java, C++ will be happy to speak to you.
For signed arithmetic JAVA uses CPU primitives. The result is that arithmetic operations happen often in 1 or a few simple operations (on a 3GHZ processor a simple operation = .33 nanoseconds). What I was saying above though is that these are done in CPU specific ways. Basically if you offer primitive unsigned ints you allow for some flexibility at the expense of introducing CPU specific behaviors which diminish cross platform.
It is easy to offer a unsigned types on the JVM, that's not an issue. But there is no particular reason to build that into the language you just build libraries that handle it if you want them. Unsigned ints would just be like any other non-CPU supported object with an arithmetic structure. However, if unsigned are virtualized, you could be looking at performance of 1/100th of the CPU.
I'm not sure how that connects to the GPs request. Anyway Gosling didn't include it because the behavior aren't defined in CPU independent ways.
32-unsigned 0 minus 32-unsigned 1 = ?
where ? is CPU dependent. Some you'll 0xFFFF other 0x8001 others 0xFFFE. That's precisely the sort of thing JAVA was designed to abstract away. And if you don't want unsigned to be doing raw CPU arithmetic on primitives then you can just use a library.
Sure the classic discussion is in Mythical Man Month. Here (http://sequoia.cs.byu.edu/lab/files/pubs/Delorey2007a.pdf) is a paper from 2007 which has references to many of the classic discussion. And Brooks I believe cites the original FORTRAN vs. assembler tests.
There are lots of languages built on top of the JVM that can even use Java libraries which have totally different syntax. Clojure being a great example, and Scala another.
If you think that all programming languages are the same it is perhaps time you get out of your mom's basement and look at 60 years of efficiency studies which show much the opposite.
Or Google could itself organize an Android kernel which works back and forth with Linus the way RedHat maintains their own separate features kernels. That would allow Androidisms to be in their kernel but have it ported forward. The hardware vendors will hopefully get the spirt of the GPL at some point.
But regardless Linux on embedded is successful.
Hairy --
Embedded requires drivers Linux is a huge player
Server requires drivers Linux is a huge player
Android requires drivers Linux is the kernel
Tizen will require drivers and Linux is the kernel of that too
So obviously the model does work. It doesn't work well for low end Windows hardware. The Linux community, including Linus has mostly given up on that community. Linux failed at its original goal of a desktop replacement for Windows and was hugely successful at a dozen others. The kernel group is not going to damager the more important products like server and embedded to do better running on $300 machines. They just don't care that much.
As for iOS it most certainly does use the Linux model as does OSX. And heck yeah a GPLed operating system does not want closed source components becoming crucial. If you disagree with the GPL, here is Microsoft's business card.