UI lag is when you press the button and the button press animation doesn't happen immediately, or you drag something and the screen is not updated immediately. If you press a button and nothing other than the UI being updated happens then it's just slow code, not a laggy UI.
No, it talks complete bullshit. The idle power consumption is 2W! The full-load power consumption of a typical ARM SoC (including CPU and GPU) is usually under 2W. Idle power consumption is generally well under 100mW, typically closer to 20mW. It's 'pretty close' if you mean 'within two orders of magnitude'. Or as we would normally say 'not close at all.'
Everyone says this, but really, CISC is more efficient. CISC code is more compact than RISC code, which helps cache hit rates. Additionally, the most used opcodes tend to be the shortest.
Actually, this is the everyone-says-it-but-it's-wrong thing. At least, when the RISC in question is ARM. Most 32-bit ARM instructions are 16-bits in Thumb-2 (ARMv8 doesn't have a Thumb mode yet, so all 64-bit instructions are 32 bits). Even without using Thumb-2, I find I get about the same instruction density for both hand-written and compiler-generated assembly for ARM and x86, often with ARM code being 5-10% smaller.
For example, ARM code supports predicated instructions so a simple if statement can be just a single predicated instruction on ARM while it would need to be a branch on x86. ARM addressing modes are also very rich, which was the place where CISC usually won a lot over RISC. Things like computing the address of an array or structure element can be half a dozen instructions on a traditional RISC architecture, but just one on ARM (x86 is almost as good, but seems to have a lot of addressing modes for things you don't use and, until x86-64, miss a lot of ones that you did want).
But, more importantly, ARM instruction encodings are very simple. Decoding the opcode is just a mask, as is selecting the registers. This means that the die area used by the instruction decoder is much smaller. This is really important in low power applications, because execution units can employ all sorts of power saving techniques when they're not in use, but the instruction decoder is always on and always in use (except on the Xeons, where micro-ops are cached in loops, but the micro-op decoder in the Xeon is about as complex as the real instruction decoder in an ARM chip so that doesn't actually save anything relative to ARM).
If you wanted to leave a lasting indication of your existence, the moon would be a good place for it. It's unusual in our solar system (the only large moon around a rocky planet). If they visited in the last few billion years, then it would have been in orbit around a planet with life. It also lacks the surface erosion that you get on Earth (no water freezing and melting, no atmospheric effects), so an artefact left there would last for a long time. The stuff the Apollo crews left there is still in good condition - imagine what state it would be in if it were left almost anywhere on Earth (with the possible exception of Antarctica) for the same length of time...
The Darwin kernel sources were at one time removed from the available downloads,
That's simply untrue. The sources for the new version took a couple of weeks to appear after the release, and do for every release. The old ones were never removed from opensource.apple.com. Lots of FUD was spread on this topic.
There is a difference between accidental and crafted collisions. Having a collision in a hash between two random documents is not nearly as big a security problem as having a collision in a hash between one chosen document and one constructed one.
I can give some real examples. First, there's the fact that Python uses spaces for indenting. Two characters to indent one level. Fine... except when someone's editor inserts a tab. Then they've got code that looks correct visually but does the wrong thing. I spent ages chasing a Python bug where this was exactly what had happened - the code where it was dying looked fine when inspected it, but it was a code path that wasn't tested by the original developer - it looked right to him, it looked right to me, and it broke. That would not happen with explicit blocks. That's more of a problem with Python than with the idea though: you could use tabs, one tab per indent level, and have the parser error on any statement that had any spaces before the first non-whitespace character.
Then there's the matter of line continuations. In both C and Python, it's quite common to have a flow control statement (for / if / whatever) with a condition that you want to wrap, so you put it on the next line. Python allows you to implicitly break lines in the middle of parenthetical expressions without needing an explicit continuation character (which is actually quite nice), but this means that you then - in both C and Python - have a second line that is indented but is part of the same block. This is not a problem in C, because you then have an explicit start-of-block marker. In Python, the next line can have the same indent level as the one above it, but be in a different block.
The human visual system is very good at matching symmetrical pairs of things, especially if they are lined up. If you put braces on their own lines, you can spot the start and end of a block very quickly. This makes navigating a big chunk of code trivial - you can quickly see where the start and end are. You can only do this in Python (or any other whitespace-sensitive language) if you have no blank lines (they break the visual flow, but are usually encouraged to break statements into semantically related groups) and if you have no wrapped lines. These two constraints generally only apply to toy code.
Can you think of any device a young student can't play games on? If so, you may be so old that you've forgotten what it was like to be a child. We could play games on anything...
I've only seen one variable consistently correlated with pupil achievement over a variety of studies: teacher enthusiasm. Interestingly, even teacher knowledge did not show a strong correlation - an enthusiastic but ignorant teacher will motivate the students to do their own research. That said, computers are tools, just like blackboards. A teacher can make effective use of them, ignore them completely, or use them to hinder learning. Some teachers used to write things on the board for pupils to copy down - I doubt any study that looked at classrooms like this would show that the blackboard improves learning. Others use them to draw diagrams to illustrate important points, helping the more visual learners in the class. When I was 7, a teacher used a BBC Micro connected to a big TV to use logo to show us basic trigonometry. We then had a teacher cover the same material a few years later, but it stuck a lot better the first time because he'd ask us for suggestions, we'd propose sequences of angles and lengths, and the computer would immediately come back with the shape.
And where is today's LOGO equivalent for young kids to get into elementary programming?
Here it is, a complete pure object-oriented development environment where even the pixels are objects and can be introspected just by clicking on them and poking their properties.
Pick any language and look how much background knowledge you need to have to merely create a trivial program to put a pixel on a screen and draw a few lines
Nope, those are trivial tasks with Squeak. The one-hour demo lesson that VPRI does ends with the children drawing cars, writing programs to control them, and creating an event-driven object oriented system without realising that they're doing any more than playing.
If you use OpenMP, or your code benefits from autovectorisation, that's true. If not, then there's usually less than 10% in it, and much of the time LLVM does a better job than GCC.
less buggy and more mature
More mature (which means more crufty code), sure. Less buggy? Debatable. I work on one large codebase that don't support any GCC after 4.2 because they've all introduced new optimiser bugs. The same project works with ICC, XLC, Open64, and Clang / LLVM. If you do stick with 4.2.1 (the last GPLv2 one, so the last one you'll find shipped by default on most non-GNU platforms) then you have fun things like internal compiler errors if you use the atomic builtins in large functions because of a buggy register allocator.
has better standard support
Again, highly debatable. They're both close with C, although I think Clang has slightly better C11 support. Clang has more standards-compliant template instantiation behaviour for C++. Objective-C doesn't have a standard, but clang is the reference implementation and the only compiler to support nice features like automatic reference counting (and generates much better code for Objective-C than GCC). Trying to support gcc in Objective-C code is now more effort than it's worth.
supports more targets
That one is true, although only relevant if you actually use those targets. For example, I don't care about M68K support, because I haven't even seen an M68K machine for years. I do care about MIPS support (which is a little bit immature in LLVM), because there are still MIPS systems that I need to target. I care most about x86[-64] and ARM. Apple and Qualcomm have put a lot of effort into optimising LLVM's ARM back end over the last couple of years, and it generates much better code on ARMv7 than GCC in a lot of cases.
has more developers
This one I very much doubt. The GCC team is mostly employed by Google and Red Hat. Google is currently migrating to Clang, and a lot of the Google-employed GCC team is now being paid to work on clang. LLVM has significant contributions from UIUC, Apple, Qualcomm, Google, Adobe, ARM, Intel, AMD, and many others.
Since gcc is what they were probably already using, why would they suddenly change?
For one thing, for the significantly better errors. I was 'compiling' C++ code with clang for about a year before it was actually producing working binaries just for the error messages, then compiling with gcc to actually produce the.o files. GCC would print screens full of unintelligible template expansions, Clang would tell me the actual problem. Any problems in macros or templates are a bitch to find with gcc but easy with clang. Once clang was able to produce working binaries for C++, I ditched gcc entirely.
If they had failed, then one of the other motor companies would probably have been quite interested in buying that factory at a knock-down price and employing all of that experience labour...
After all the 'profit' a company accrues can/will/must be used to employ future generations to survive.
Or it can be paid out to shareholders in the form of dividends. A stable company in an established market can continue to make a profit and pay it out to shareholders without needing to grow, until someone introduces a disruptive technology into that market.
Note that the above only applies to US Federal copyright law. In some states (although generally only for a subset of types of work), and in most of Europe, copyright also includes the concept of Moral Rights. These include the right of the author to be identified with the work, so in many jurisdictions plagiarism (i.e. not giving the author credit) are explicitly covered by copyright law.
At the Federal level, the USA does not recognise moral rights - make of that what you will.
The GPLv3 also permits this. You can take someone else's GPLv3 code and sell it for $1,000,000 if you can find a buyer (although, since they could get it from someone else for free, good luck with that). What you must do, with both v2 and v3, is provide the person that you sell it to with a license to redistribute it, and with the source code (or a transferrable offer good for three years to provide the source code). The person you sell it to is then free to sell it for any amount or give it away, so selling GPL'd software more than once requires a ready supply of fools.
If Windows exception support is valuable to you, then I suggest that you consider contributing. Until Sony decided to adopt LLVM, no one within the project regularly used Windows, and no one outside was willing to fund the work. Supporting features on platforms that I don't use (and, in this case, don't even have access to) are generally a very low priority for me.
Native exceptions work fine on platforms I use, like FreeBSD, platforms people who have sent me helpful bug reports use, like OpenBSD, and platforms used by people who paid me for support, like Linux.
The C89 standard reserved identifiers starting with two underscores and ones starting with an underscore and a capital letter for future use and for the implementation. Compilers and libc implementations generally use double underscores for extensions and for semi-private identifiers in headers. The standard generally uses identifiers starting with an underscore and a capital letter for new keywords. Examples from C99 include _Bool and _Complex. C11 adds _Atomic, _Thread_local and _Noreturn. As with the C99 versions, there are headers that you can include that #define them as lower case identifiers without the leading underscore.
They will be implemented in terms of Win64 exceptions when Win64 exceptions are supported. They aren't currently. We could emit DWARF EH data for them, but there's no real point because then you'd need to ship a complete unwind stack for them. GCC emits setjmp / longjmp exceptions, but if you're going to use them you may as well use NS_DURING. I don't intend to support them, because once they're working (for a given value of working), people think implementing exceptions properly is a lower priority and it gets put off for years.
You can't have polymorphism in functions without name mangling (because functions are resolved by the linker, so if you have two functions called foo() then it will be confused, and you need them to be called _Z3fooi and _Z3foof - for example - to distinguish between different argument types). Requiring name mangling would break a lot of existing C code, since it would make taking the address of a function (for example) difficult and would mean that there is not a . Having _Generic for macros lets you do things like have a foo() macro that calls either foo() or foo_f() without needing to modify the ABI.
As I said, it doesn't yet support Win64 exceptions, although it's a work in progress. It will not support Win32 SEH, because it is patented and the patent doesn't expire for another few years (by which time I doubt anyone will care about win32) and the patent is quite aggressively enforced.
The CMake build system for LLVM / Clang can produce a visual studio project file, so you can build the compiler with that.
GNUstep is very much actively developed on Windows (although I don't have a Windows machine to test on, so reports of what breaks when you try to build the runtime are welcome). There's now a Windows theme that uses the Widnows UXTheme engine. I think it's the default with the latest Windows installer (which may still ship with gcc for some silly reason).
I don't test with Windows, as I said, but on FreeBSD we now support a superset of the Objective-C features that work on Darwin.
Depends on the level of competence required. I've had quite a few job offers recently, but I hear from the companies I work for that entry-level programming positions are very easy to fill but competent experienced developers are very rare no matter how much they're willing to pay.
Slashdot Mirror
UI lag is when you press the button and the button press animation doesn't happen immediately, or you drag something and the screen is not updated immediately. If you press a button and nothing other than the UI being updated happens then it's just slow code, not a laggy UI.
No, it talks complete bullshit. The idle power consumption is 2W! The full-load power consumption of a typical ARM SoC (including CPU and GPU) is usually under 2W. Idle power consumption is generally well under 100mW, typically closer to 20mW. It's 'pretty close' if you mean 'within two orders of magnitude'. Or as we would normally say 'not close at all.'
Everyone says this, but really, CISC is more efficient. CISC code is more compact than RISC code, which helps cache hit rates. Additionally, the most used opcodes tend to be the shortest.
Actually, this is the everyone-says-it-but-it's-wrong thing. At least, when the RISC in question is ARM. Most 32-bit ARM instructions are 16-bits in Thumb-2 (ARMv8 doesn't have a Thumb mode yet, so all 64-bit instructions are 32 bits). Even without using Thumb-2, I find I get about the same instruction density for both hand-written and compiler-generated assembly for ARM and x86, often with ARM code being 5-10% smaller.
For example, ARM code supports predicated instructions so a simple if statement can be just a single predicated instruction on ARM while it would need to be a branch on x86. ARM addressing modes are also very rich, which was the place where CISC usually won a lot over RISC. Things like computing the address of an array or structure element can be half a dozen instructions on a traditional RISC architecture, but just one on ARM (x86 is almost as good, but seems to have a lot of addressing modes for things you don't use and, until x86-64, miss a lot of ones that you did want).
But, more importantly, ARM instruction encodings are very simple. Decoding the opcode is just a mask, as is selecting the registers. This means that the die area used by the instruction decoder is much smaller. This is really important in low power applications, because execution units can employ all sorts of power saving techniques when they're not in use, but the instruction decoder is always on and always in use (except on the Xeons, where micro-ops are cached in loops, but the micro-op decoder in the Xeon is about as complex as the real instruction decoder in an ARM chip so that doesn't actually save anything relative to ARM).
If you wanted to leave a lasting indication of your existence, the moon would be a good place for it. It's unusual in our solar system (the only large moon around a rocky planet). If they visited in the last few billion years, then it would have been in orbit around a planet with life. It also lacks the surface erosion that you get on Earth (no water freezing and melting, no atmospheric effects), so an artefact left there would last for a long time. The stuff the Apollo crews left there is still in good condition - imagine what state it would be in if it were left almost anywhere on Earth (with the possible exception of Antarctica) for the same length of time...
The Darwin kernel sources were at one time removed from the available downloads,
That's simply untrue. The sources for the new version took a couple of weeks to appear after the release, and do for every release. The old ones were never removed from opensource.apple.com. Lots of FUD was spread on this topic.
There is a difference between accidental and crafted collisions. Having a collision in a hash between two random documents is not nearly as big a security problem as having a collision in a hash between one chosen document and one constructed one.
I can give some real examples. First, there's the fact that Python uses spaces for indenting. Two characters to indent one level. Fine... except when someone's editor inserts a tab. Then they've got code that looks correct visually but does the wrong thing. I spent ages chasing a Python bug where this was exactly what had happened - the code where it was dying looked fine when inspected it, but it was a code path that wasn't tested by the original developer - it looked right to him, it looked right to me, and it broke. That would not happen with explicit blocks. That's more of a problem with Python than with the idea though: you could use tabs, one tab per indent level, and have the parser error on any statement that had any spaces before the first non-whitespace character.
Then there's the matter of line continuations. In both C and Python, it's quite common to have a flow control statement (for / if / whatever) with a condition that you want to wrap, so you put it on the next line. Python allows you to implicitly break lines in the middle of parenthetical expressions without needing an explicit continuation character (which is actually quite nice), but this means that you then - in both C and Python - have a second line that is indented but is part of the same block. This is not a problem in C, because you then have an explicit start-of-block marker. In Python, the next line can have the same indent level as the one above it, but be in a different block.
The human visual system is very good at matching symmetrical pairs of things, especially if they are lined up. If you put braces on their own lines, you can spot the start and end of a block very quickly. This makes navigating a big chunk of code trivial - you can quickly see where the start and end are. You can only do this in Python (or any other whitespace-sensitive language) if you have no blank lines (they break the visual flow, but are usually encouraged to break statements into semantically related groups) and if you have no wrapped lines. These two constraints generally only apply to toy code.
Can you think of any device a young student can't play games on? If so, you may be so old that you've forgotten what it was like to be a child. We could play games on anything...
There is not much else you can do with paper, pencil, and a Maths textbook than study.
Seriously? If you think that, then I can only assume that you never went to school...
Dogs that bark at squirrels are fascists!
It starts with barking, but the next thing you know the dogs will have the squirrels in death camps and then you won't look so clever...
I've only seen one variable consistently correlated with pupil achievement over a variety of studies: teacher enthusiasm. Interestingly, even teacher knowledge did not show a strong correlation - an enthusiastic but ignorant teacher will motivate the students to do their own research. That said, computers are tools, just like blackboards. A teacher can make effective use of them, ignore them completely, or use them to hinder learning. Some teachers used to write things on the board for pupils to copy down - I doubt any study that looked at classrooms like this would show that the blackboard improves learning. Others use them to draw diagrams to illustrate important points, helping the more visual learners in the class. When I was 7, a teacher used a BBC Micro connected to a big TV to use logo to show us basic trigonometry. We then had a teacher cover the same material a few years later, but it stuck a lot better the first time because he'd ask us for suggestions, we'd propose sequences of angles and lengths, and the computer would immediately come back with the shape.
And where is today's LOGO equivalent for young kids to get into elementary programming?
Here it is, a complete pure object-oriented development environment where even the pixels are objects and can be introspected just by clicking on them and poking their properties.
Pick any language and look how much background knowledge you need to have to merely create a trivial program to put a pixel on a screen and draw a few lines
Nope, those are trivial tasks with Squeak. The one-hour demo lesson that VPRI does ends with the children drawing cars, writing programs to control them, and creating an event-driven object oriented system without realising that they're doing any more than playing.
If it's well cared for, it probably isn't a library book.
by which I mean, optimizes better
If you use OpenMP, or your code benefits from autovectorisation, that's true. If not, then there's usually less than 10% in it, and much of the time LLVM does a better job than GCC.
less buggy and more mature
More mature (which means more crufty code), sure. Less buggy? Debatable. I work on one large codebase that don't support any GCC after 4.2 because they've all introduced new optimiser bugs. The same project works with ICC, XLC, Open64, and Clang / LLVM. If you do stick with 4.2.1 (the last GPLv2 one, so the last one you'll find shipped by default on most non-GNU platforms) then you have fun things like internal compiler errors if you use the atomic builtins in large functions because of a buggy register allocator.
has better standard support
Again, highly debatable. They're both close with C, although I think Clang has slightly better C11 support. Clang has more standards-compliant template instantiation behaviour for C++. Objective-C doesn't have a standard, but clang is the reference implementation and the only compiler to support nice features like automatic reference counting (and generates much better code for Objective-C than GCC). Trying to support gcc in Objective-C code is now more effort than it's worth.
supports more targets
That one is true, although only relevant if you actually use those targets. For example, I don't care about M68K support, because I haven't even seen an M68K machine for years. I do care about MIPS support (which is a little bit immature in LLVM), because there are still MIPS systems that I need to target. I care most about x86[-64] and ARM. Apple and Qualcomm have put a lot of effort into optimising LLVM's ARM back end over the last couple of years, and it generates much better code on ARMv7 than GCC in a lot of cases.
has more developers
This one I very much doubt. The GCC team is mostly employed by Google and Red Hat. Google is currently migrating to Clang, and a lot of the Google-employed GCC team is now being paid to work on clang. LLVM has significant contributions from UIUC, Apple, Qualcomm, Google, Adobe, ARM, Intel, AMD, and many others.
Since gcc is what they were probably already using, why would they suddenly change?
For one thing, for the significantly better errors. I was 'compiling' C++ code with clang for about a year before it was actually producing working binaries just for the error messages, then compiling with gcc to actually produce the .o files. GCC would print screens full of unintelligible template expansions, Clang would tell me the actual problem. Any problems in macros or templates are a bitch to find with gcc but easy with clang. Once clang was able to produce working binaries for C++, I ditched gcc entirely.
If they had failed, then one of the other motor companies would probably have been quite interested in buying that factory at a knock-down price and employing all of that experience labour...
After all the 'profit' a company accrues can/will/must be used to employ future generations to survive.
Or it can be paid out to shareholders in the form of dividends. A stable company in an established market can continue to make a profit and pay it out to shareholders without needing to grow, until someone introduces a disruptive technology into that market.
Note that the above only applies to US Federal copyright law. In some states (although generally only for a subset of types of work), and in most of Europe, copyright also includes the concept of Moral Rights. These include the right of the author to be identified with the work, so in many jurisdictions plagiarism (i.e. not giving the author credit) are explicitly covered by copyright law.
At the Federal level, the USA does not recognise moral rights - make of that what you will.
The GPLv3 also permits this. You can take someone else's GPLv3 code and sell it for $1,000,000 if you can find a buyer (although, since they could get it from someone else for free, good luck with that). What you must do, with both v2 and v3, is provide the person that you sell it to with a license to redistribute it, and with the source code (or a transferrable offer good for three years to provide the source code). The person you sell it to is then free to sell it for any amount or give it away, so selling GPL'd software more than once requires a ready supply of fools.
If Windows exception support is valuable to you, then I suggest that you consider contributing. Until Sony decided to adopt LLVM, no one within the project regularly used Windows, and no one outside was willing to fund the work. Supporting features on platforms that I don't use (and, in this case, don't even have access to) are generally a very low priority for me.
Native exceptions work fine on platforms I use, like FreeBSD, platforms people who have sent me helpful bug reports use, like OpenBSD, and platforms used by people who paid me for support, like Linux.
The C89 standard reserved identifiers starting with two underscores and ones starting with an underscore and a capital letter for future use and for the implementation. Compilers and libc implementations generally use double underscores for extensions and for semi-private identifiers in headers. The standard generally uses identifiers starting with an underscore and a capital letter for new keywords. Examples from C99 include _Bool and _Complex. C11 adds _Atomic, _Thread_local and _Noreturn. As with the C99 versions, there are headers that you can include that #define them as lower case identifiers without the leading underscore.
They will be implemented in terms of Win64 exceptions when Win64 exceptions are supported. They aren't currently. We could emit DWARF EH data for them, but there's no real point because then you'd need to ship a complete unwind stack for them. GCC emits setjmp / longjmp exceptions, but if you're going to use them you may as well use NS_DURING. I don't intend to support them, because once they're working (for a given value of working), people think implementing exceptions properly is a lower priority and it gets put off for years.
You can't have polymorphism in functions without name mangling (because functions are resolved by the linker, so if you have two functions called foo() then it will be confused, and you need them to be called _Z3fooi and _Z3foof - for example - to distinguish between different argument types). Requiring name mangling would break a lot of existing C code, since it would make taking the address of a function (for example) difficult and would mean that there is not a . Having _Generic for macros lets you do things like have a foo() macro that calls either foo() or foo_f() without needing to modify the ABI.
As I said, it doesn't yet support Win64 exceptions, although it's a work in progress. It will not support Win32 SEH, because it is patented and the patent doesn't expire for another few years (by which time I doubt anyone will care about win32) and the patent is quite aggressively enforced.
GNUstep is very much actively developed on Windows (although I don't have a Windows machine to test on, so reports of what breaks when you try to build the runtime are welcome). There's now a Windows theme that uses the Widnows UXTheme engine. I think it's the default with the latest Windows installer (which may still ship with gcc for some silly reason).
I don't test with Windows, as I said, but on FreeBSD we now support a superset of the Objective-C features that work on Darwin.
Depends on the level of competence required. I've had quite a few job offers recently, but I hear from the companies I work for that entry-level programming positions are very easy to fill but competent experienced developers are very rare no matter how much they're willing to pay.