Actually, for the most part US English retains the older spellings, not British English. That said, dictionaries and the codification of languages was still a novelty until the mid-nineteenth century so the differences in spelling can be pretty arbitrary.
Checkstyle and PMD (which is what the new tool you mention probably is) are configurable - I turn the warnings about the ternary operator off for example. Having a "zero Checkstyle warnings" policy is daft, as static code analysis tools are a good way of potentially bad code, not an indication that something absolutely must be changed.
I think it's easier to make working documentation out of working code than working code out of non-working documentation.
Sadly not. Most hardware documentation is wrong, and errata updates are the exception rather than the norm. However, understanding what the hardware was supposed to do from reading the documentation is often better than reading a magic number filled chunk of source code. Please note that this is not a criticism of the VIA code, which may be a model of well written and documented code...
The 200MHz Pentium would be roughly four or five times of the ARM found in an iPaq, so something had to give - and that was the cache and some complexity. The ARM chip also ran much cooler and with lower power consumption than the Pentium, which needed a fan and sizable heat sink. My point about an x86 processor being inferior is that it's crippled by the instruction set, which requires a lot of decoding before the RISC-like core can actually do its work. There are diagrams that show how much real estate on a number of x86 processors from Intel is taken up by the decoder, and it's considerably more than on a processor with a more efficient and elegant instruction set.
Speed comes much further down the list of priorities in most embedded applications. Size, power consumption, heat dissipation and even code size matter more - and code size is related to instruction set. Even when it comes to performance, x86 is relatively inferior compared to something like an ARM processor - it's mostly the higher clock speed and Intel's ability to build new fabs faster than anyone else that's kept them in the game.
Not sure whether it counts as a laptop, but despite the size the Sharp Zaurus CL3200 had all the features of one and used an ARM processor. As for desktops, the Archimedes had an ARM processor (in fact the processor was invented for it) and was an amazing machine in its day. Nowadays, you can get an ARM based desktop machine from Iyonix but they're a very niche product.
Yup, but the authors argument that familiarity with development tools for x86 (and what seems like an assumption that those don't exist for other architectures) is going to be appealing also shows he's clueless. There are already excellent suites of tools for embedded development, in fact most of them are the same as you'd use for desktop or server development - particularly gcc, gdb and so forth targeted for your particular architecture, along with IDEs and emulators you can run on a typical PC. If the author thinks something like Visual Studio is going to appeal for embedded programming then he's even more of a nitwit.
The article appears to be written from the perspective of someone who knows fuck all about the embedded market. The majority of embedded products that have something more sophisticated than an 8bit processor are using Motorola M68K, ARM or MIPS derivatives. That's likely to stay that way, as x86 processors tend to be large, comparatively power hungry and focused on high clock speeds - especially the ones from Intel and AMD. In fact, the only vaguely embedded device I've come across with an x86 chip was using a 486 clone (from Cyrix I think).
Problem with Java is the way that Beans have become so important, at least in the EE framework. These are the devil if you are a proponent of immutability and should be handled very carefully.
If you're familiar with CORBA, and underwhelmed by SOAP, then you might like to check out ICE. It's an attempt to do CORBA "better" - in other words, without the designed by committee and everything bar the kitchen sink aspects that ruined CORBA. I was initially a little bit sceptical, but having played around with it for a notifications system I've become really impressed.
Complete crap. Threads solve a number of programming problems much more elegantly than forked processes and sharing data through some IPC mechanisms. Anecdote time: a stock price system I worked on. The first generation used separate processes for a single writer and a large number of readers, with shared memory for interprocess communication. This was switched to a threaded implementation for the second generation, which was faster, even though it was using the old LinuxThreads implementation, and more easily maintained as the pthreads API is much richer than IPC ones.
The articles' author explicitly mentions Erlang as a potential solution to threading issues in other languages. In fact he's mainly concerned about POSIX pthreads, Boost threads, Java threads (and presumably Windows low level thread libraries). As I point out in another post below, I disagree with him lumping Java threads in with those used in most C/C++ libraries, as threading support is integrated into the language along with increasingly sophisticated locking support in the library which can be used if the simple object lock is insufficient. In my experience, most data shared across threads is immutable (read only), and the Java libraries encourage use of immutable types such as String. Once you appreciate the value of immutable types, then they can be used just as easily in C++ (with C it's a little harder). Writable shared data can be cleanly hidden behind a decent interface, with the locking within the getters and setters, but again, this approach is applicable in C++ as well as Java.
The problem is not threads per se, but the way they are generally used in programming languages like C and C++. Although const correctness is understood by some C++ programmers, they appear to be a minority if I judge by the code I regularly review. There is also memory management which is a much bigger issue in threaded C/C++ applications than in applications written in Java. The Java library provides good examples of immutable classes, most prominently the String class, that remove a number of problems often encountered with their mutable cousins like std::string. Unlike std::string, I don't have to remember to make it immutable by constifying it or wrapping it. The presence of immutable classes, and the more adequate coverage given them along with threading in Java textbooks means that I disagree with the articles' author who lumps Java threads in with pthreads as a bad thing. What we need is more coverage of threading issues and how to alleviate them in intermediate level C/C++ textbooks, because despite the fact that threading is not built into those languages or their standard libraries, concurrency has become too important to ignore once you go beyond the basics.
If the criteria for what's included in gNewSense is what RMS uses, then don't expect it to come with a web browser as he recently admitted he doesn't use one. Check out the long flamefest on the OpenBSD mailing lists for the admission from RMS.
I think that the grandparent poster was referring to the dissecting and reordering of code that generally occurs with Literate Programming. Take the code from the book "A Retargetable C Compiler: Design and Implementation", which uses Literate Programming. The code is written as snippets and in an order that makes describing the purpose of the compiler easier, but the code itself loses its "integrity" (individual functions are split up and reordered) and is effectively unmaintainable in its source form - it needs to be preprocessed into a more logical order for the programmer to follow, but in doing so you're no longer editing the source in its Literate Programming form!
I know this will annoy those who believe he's some saint just because they've heard he is from anecdotes, but Knuth is somewhat irrelevant. An academic who has written no significant code (no, TeX doesn't count as it's just a simple interpreter), and who rails against the real world from his ivory tower. Even his books are a waste of time, with code written in an idealised assembly language that glosses over a number of practical considerations, they're dated, unbelievably boring and of no practical use compared to something like the "Numerical Recipes" or "Algorithms in..." books.
Having poked through chunks of both the Sun JDK source and the Classpath source, I wouldn't trust the latter in a production environment. Sun has released some crufty stuff (JAI for instance), but Classpath is horrible pretty much across the board.
If you actually compare the Java programming language to C++ (in other words, ignore the standard libraries), then C++ is the monster. If you compare the functionality provided by the Java libraries then it dwarfs the C++ ones (the latter amount to a subset of the java.lang and java.util classes in functionality). That massive amount of functionality comes at a cost - the size of the library. However, try writing a socket based app in portable C++ - portable to say Windows and Linux. Can't be done without using a third party library, so while you're fucking about with ifdefs and compiler compatability I'll be shipping my Java based app.
How do you know that the grandparent poster was suggesting you don't use the "best tools" in C++? There again, what does C++ do better than a number of other languages? Let's take the iostream classes for example. They were supposed to be "better" than C stdio because, well, for no other reason than they were object oriented. In practice, iostream code is actually more verbose, less intuitive and relies on a dubious use of the overridden left and right shift operators.
C++ was not the first OOP language, as even Stroustrup will acknowledge - he was attempting to add Simula like features to C when he came up with C++. Smalltalk also predates C++. I agree that it should be relegated to legacy status though.
Err, are you saying that you *have* to use an IDE to generate a class to run a Java app? The equivalent of your C++ main would be:
public class Test {
public static void main(String[] args) { //...
}
}
Why do you need an IDE to write that?
Re:Excession and Look to Windward?
on
Matter
·
· Score: 2, Informative
Ultimately, I think the best introduction to Banks is to start at the beginning, with Consider Phlebas.
If you start at the beginning, that would be "The Wasp Factory" and "Walking On Glass". His best book has got to be "Complicity", which combines the unexpected twists and nastiness of his first two books with a cracking thriller plot. In fact, Banks is at his best when he's not allowed to indulge in sci-fi too much - as someone mentioned above, it's often masturbatory shite.
Slashdot Mirror
Actually, for the most part US English retains the older spellings, not British English. That said, dictionaries and the codification of languages was still a novelty until the mid-nineteenth century so the differences in spelling can be pretty arbitrary.
Checkstyle and PMD (which is what the new tool you mention probably is) are configurable - I turn the warnings about the ternary operator off for example. Having a "zero Checkstyle warnings" policy is daft, as static code analysis tools are a good way of potentially bad code, not an indication that something absolutely must be changed.
I think it's easier to make working documentation out of working code than working code out of non-working documentation.
Sadly not. Most hardware documentation is wrong, and errata updates are the exception rather than the norm. However, understanding what the hardware was supposed to do from reading the documentation is often better than reading a magic number filled chunk of source code. Please note that this is not a criticism of the VIA code, which may be a model of well written and documented code ...
The 200MHz Pentium would be roughly four or five times of the ARM found in an iPaq, so something had to give - and that was the cache and some complexity. The ARM chip also ran much cooler and with lower power consumption than the Pentium, which needed a fan and sizable heat sink. My point about an x86 processor being inferior is that it's crippled by the instruction set, which requires a lot of decoding before the RISC-like core can actually do its work. There are diagrams that show how much real estate on a number of x86 processors from Intel is taken up by the decoder, and it's considerably more than on a processor with a more efficient and elegant instruction set.
Speed comes much further down the list of priorities in most embedded applications. Size, power consumption, heat dissipation and even code size matter more - and code size is related to instruction set. Even when it comes to performance, x86 is relatively inferior compared to something like an ARM processor - it's mostly the higher clock speed and Intel's ability to build new fabs faster than anyone else that's kept them in the game.
Not sure whether it counts as a laptop, but despite the size the Sharp Zaurus CL3200 had all the features of one and used an ARM processor. As for desktops, the Archimedes had an ARM processor (in fact the processor was invented for it) and was an amazing machine in its day. Nowadays, you can get an ARM based desktop machine from Iyonix but they're a very niche product.
They said the same things about Apple and moto chips.
Yes, but the article discusses processors for embedded devices. What do you think's inside an iPod or iPhone? An ARM processor.
Yup, but the authors argument that familiarity with development tools for x86 (and what seems like an assumption that those don't exist for other architectures) is going to be appealing also shows he's clueless. There are already excellent suites of tools for embedded development, in fact most of them are the same as you'd use for desktop or server development - particularly gcc, gdb and so forth targeted for your particular architecture, along with IDEs and emulators you can run on a typical PC. If the author thinks something like Visual Studio is going to appeal for embedded programming then he's even more of a nitwit.
The article appears to be written from the perspective of someone who knows fuck all about the embedded market. The majority of embedded products that have something more sophisticated than an 8bit processor are using Motorola M68K, ARM or MIPS derivatives. That's likely to stay that way, as x86 processors tend to be large, comparatively power hungry and focused on high clock speeds - especially the ones from Intel and AMD. In fact, the only vaguely embedded device I've come across with an x86 chip was using a 486 clone (from Cyrix I think).
Problem with Java is the way that Beans have become so important, at least in the EE framework. These are the devil if you are a proponent of immutability and should be handled very carefully.
If you're familiar with CORBA, and underwhelmed by SOAP, then you might like to check out ICE. It's an attempt to do CORBA "better" - in other words, without the designed by committee and everything bar the kitchen sink aspects that ruined CORBA. I was initially a little bit sceptical, but having played around with it for a notifications system I've become really impressed.
Complete crap. Threads solve a number of programming problems much more elegantly than forked processes and sharing data through some IPC mechanisms. Anecdote time: a stock price system I worked on. The first generation used separate processes for a single writer and a large number of readers, with shared memory for interprocess communication. This was switched to a threaded implementation for the second generation, which was faster, even though it was using the old LinuxThreads implementation, and more easily maintained as the pthreads API is much richer than IPC ones.
The articles' author explicitly mentions Erlang as a potential solution to threading issues in other languages. In fact he's mainly concerned about POSIX pthreads, Boost threads, Java threads (and presumably Windows low level thread libraries). As I point out in another post below, I disagree with him lumping Java threads in with those used in most C/C++ libraries, as threading support is integrated into the language along with increasingly sophisticated locking support in the library which can be used if the simple object lock is insufficient. In my experience, most data shared across threads is immutable (read only), and the Java libraries encourage use of immutable types such as String. Once you appreciate the value of immutable types, then they can be used just as easily in C++ (with C it's a little harder). Writable shared data can be cleanly hidden behind a decent interface, with the locking within the getters and setters, but again, this approach is applicable in C++ as well as Java.
The problem is not threads per se, but the way they are generally used in programming languages like C and C++. Although const correctness is understood by some C++ programmers, they appear to be a minority if I judge by the code I regularly review. There is also memory management which is a much bigger issue in threaded C/C++ applications than in applications written in Java. The Java library provides good examples of immutable classes, most prominently the String class, that remove a number of problems often encountered with their mutable cousins like std::string. Unlike std::string, I don't have to remember to make it immutable by constifying it or wrapping it. The presence of immutable classes, and the more adequate coverage given them along with threading in Java textbooks means that I disagree with the articles' author who lumps Java threads in with pthreads as a bad thing. What we need is more coverage of threading issues and how to alleviate them in intermediate level C/C++ textbooks, because despite the fact that threading is not built into those languages or their standard libraries, concurrency has become too important to ignore once you go beyond the basics.
If the criteria for what's included in gNewSense is what RMS uses, then don't expect it to come with a web browser as he recently admitted he doesn't use one. Check out the long flamefest on the OpenBSD mailing lists for the admission from RMS.
Well, if it's a fire at the Whitehouse you want, then the spirit of 1812 still burns in our hearts!
I'm not sure it will run on Sparc 10, will it? Is that even sun4u?
No, an SS10 is a 32bit sun4m machine.
No one rushes to write new operating systems for UltraSparc III 8-cores. No one.
No, they port existing ones like OpenBSD and oh, that thing called Linux.
I think that the grandparent poster was referring to the dissecting and reordering of code that generally occurs with Literate Programming. Take the code from the book "A Retargetable C Compiler: Design and Implementation", which uses Literate Programming. The code is written as snippets and in an order that makes describing the purpose of the compiler easier, but the code itself loses its "integrity" (individual functions are split up and reordered) and is effectively unmaintainable in its source form - it needs to be preprocessed into a more logical order for the programmer to follow, but in doing so you're no longer editing the source in its Literate Programming form!
I know this will annoy those who believe he's some saint just because they've heard he is from anecdotes, but Knuth is somewhat irrelevant. An academic who has written no significant code (no, TeX doesn't count as it's just a simple interpreter), and who rails against the real world from his ivory tower. Even his books are a waste of time, with code written in an idealised assembly language that glosses over a number of practical considerations, they're dated, unbelievably boring and of no practical use compared to something like the "Numerical Recipes" or "Algorithms in ..." books.
Having poked through chunks of both the Sun JDK source and the Classpath source, I wouldn't trust the latter in a production environment. Sun has released some crufty stuff (JAI for instance), but Classpath is horrible pretty much across the board.
If you actually compare the Java programming language to C++ (in other words, ignore the standard libraries), then C++ is the monster. If you compare the functionality provided by the Java libraries then it dwarfs the C++ ones (the latter amount to a subset of the java.lang and java.util classes in functionality). That massive amount of functionality comes at a cost - the size of the library. However, try writing a socket based app in portable C++ - portable to say Windows and Linux. Can't be done without using a third party library, so while you're fucking about with ifdefs and compiler compatability I'll be shipping my Java based app.
How do you know that the grandparent poster was suggesting you don't use the "best tools" in C++? There again, what does C++ do better than a number of other languages? Let's take the iostream classes for example. They were supposed to be "better" than C stdio because, well, for no other reason than they were object oriented. In practice, iostream code is actually more verbose, less intuitive and relies on a dubious use of the overridden left and right shift operators.
C++ was not the first OOP language, as even Stroustrup will acknowledge - he was attempting to add Simula like features to C when he came up with C++. Smalltalk also predates C++. I agree that it should be relegated to legacy status though.
Err, are you saying that you *have* to use an IDE to generate a class to run a Java app? The equivalent of your C++ main would be:
public class Test {
// ...
public static void main(String[] args) {
}
}
Why do you need an IDE to write that?
Ultimately, I think the best introduction to Banks is to start at the beginning, with Consider Phlebas.
If you start at the beginning, that would be "The Wasp Factory" and "Walking On Glass". His best book has got to be "Complicity", which combines the unexpected twists and nastiness of his first two books with a cracking thriller plot. In fact, Banks is at his best when he's not allowed to indulge in sci-fi too much - as someone mentioned above, it's often masturbatory shite.