Unfortunately, machine generated XML is rarely as pretty as your format, and in the case of Apple has far less meaningful tags denoting only names and types of properties. i.e. it throws out the parts of XML that are actually nice.
And what happens when you miss a > in XML, or mistype any tag name? These sorts of error are what validators were made for. The vasyt majority of programs should refuse improper input, as in the long term that's the only way to stay sane.
True, swing is one of the best (if not the best) toolkits out there. The last time I had to do serial IO on Java was in 2000, and at the time the version we had defined an interface for serial IO but had no working implementation (not helpful, guys). I'm sure that's been corrected by now though. At the time we had to cook something up using JNI, which was my first taste of that nastyness.
At least nowadays you can run on most computers with two sets of code: Posix and Windows. Thanks to OSX, it can be treated at another posix-like system.
Which is the case for most numerical programs, as well as the amazing number of backends, daemons, cgi-programs, etc that run the digital world. They rarely get counted because they by definition have lower visibility than a GUI.
If you program uses a GUI then you are pretty much out of luck.
By out of luck do you mean you only have 5 choices for a toolkit rather than 2? I use FLTK myself, and am glad a "standard" was not shoved down my throat. Java rescued itself with a second toolkit, since the first one sucked. I don't see how that is more elegant than the 3rd party libraries competing for mindshare in the C/C++ world.
Before you rant about how much Java sucks I suggest trying Eclipse and Limewire. Those are two well written Java apps.
Good programs can be written in almost any language. It says far more about the developers than the language itself. In the case of Emacs/XEmacs, I'd even say they succeeded despite their use of a bad language for most of the functionality.
These are the lessons from SML, OCaml, Clean, and modern Common Lisp compilers.
There were also lessons from their language design, which Java mostly ignored.
If you've been sleeping for the past 20 years, Guy Steele hasn't.
Then how do you explain Java being crappier feature-wise than pretty much every functional language? It doesn't even get all of the features from a pure-OOP language like smalltalk either. It took 10 years of thought after C++ to come up with something marginally better? On the bright side though, at least it isn't unityped...
Well if Java is a guide, they will have something called FNI, which will not be automatically generated in any way, will push all of glue code into Fortran (rather than in Fortress), and allow you to easily screw up the VM. But that's just a guess...
(1) You give up speed for a marginal increase in features. (1b) If speed is not a factor, languages such as OCaml have many more features suitable for high-level programming. OCaml is also slightly faster than Java in general. Thus Java is both more primitive and slower than a language that came out in a similar time frame.
(2) You give up source portability for binary portability. Almost every platform has an ansi-C compiler, yet only a handful support Java, especially if you use a recent library. There are more platforms that support OpenGL than Java3D, for example.
(3) A company controls your language. The future of Java is at the whim of a single for-profit entity. Furthermore, this entity has displayed that it wants to control the Java language and the Java platform to the greatest extent possible.
(4) It's one of the most difficult languages to interface with C, and it pushes 100% of the glue required to the native language. It is easier to interface Lisp and Haskell with C than Java to C through JNI. Given the large difference between the former pairs, and the small differences between the latter pair, this is pretty ironic.
There are some sensors that cat get dense scans in 3D, but they are by no means cheap. I've also seen some (not open) research systems that recover amazingly detailed 3D world models from stereo. Unfortunately, it's still not easy to do anything: Once you overcome the sensing problem you still have lots of spatial reasoning problems. This gets even more fun outdoors where even the 3D data doesn't tell the whole story: A rock and a clump of grass can have similar 3D shapes, but for driving purposes they aren't nearly the same.
This stuff is hard, but progress is being made. Hopefully we'll get there.
Destructors help, but do you wrap every libc or kernel function you ever use in a class? In real-world programming one has to interface with the incredible bulk of C code that is out there, and wrapping absolutely everything is damn near impossible. Each goto label replaces an entire wrapper class. I really like OOP, but when you start to get into low level interfaces, sometimes its not the most elegant way.
I agree completely. I never used goto until I saw it used in the Linux kernel, just like in your example. It's helpful when you have locks/semaphores, which absolutely must be balanced. C++ destructors can help for not leaking memory on early returns, but locks and other state still need to be cleaned up after errors.
What I want is an editor that folds stupidly obvious comments while keeping the important ones, but even Emacs doesn't do that yet. Folding treats "set i to 0" the same as "FIXME - this is completely broken".
You are spot on. Large comments at the top of a function don't "break up" the work nearly as much as inline comments. Inline comments should not state the obvious, but merely state the sections identified in the top level comment, and describe the non-obvious(*). I always like the concept that "comments should state why you are doing something, not what you are doing."
(*) This is way too often overlooked. If it takes more than a bit of thinking to figure out why code is written the way it is, you should comment it. In other words, rather than one comment per line, I'd rather see very few comments on obvious lines, and 7 lines of comments for one line of voodoo.
CS department on the other hand has its own space, and much more lax rules. Many people in CS have root access to their machines
And many of us need that, so I'm not sure what the point here is: CS=="doing things with computers". And in the case of CMU CS IT, they are still using a RedHat 7 derivative, and still use Kerberos 4, and I'd like to run software from this century.
and no bandwidth policies, arbitrary quotas on AFS servers, etc.
Uh, there's sort of a bandwidth policy, which I discovered when a 40MB video of our research was linked in the first comment to a Slashdot article. Of course that was the andrew people who asked the cs people who asked me: You've used a months' worth of alowed bandwidth in 2 days, what's going on? Quotas on AFS aren't arbitrary... you have to telnet to "jeeves" and then you get a menu that lets you set your quota. Ok never mind, that's pretty arbitrary.
All of these are highly integrated, and frequently run on the single kerberos realm provided by IT. (You can log in and read files in CS with your Andrew account, etc)
That's just Kerberos and AFS being cool. They are different realms, but it still works due to cross realm support. You can either klog to get tickets in both realms, or set ACLs on both sides allowing access from the foriegn account (but don't forget to cklog the first time).
You are spot on about IT though; This breach really sounds like some admissions' person had an insecure computer (laptop maybe even?) with a database left on it. It's up to the business school to make sure there are as few copies of the data as possible. That's just good security in general, which has nothing directly to do with computers.
Now if the CS department gets breached electronically, I really will be annoyed, because they really should know better. CS should fall only to social engineering attacks taking advantage of dorks, which the business school should be more immune to.
They didn't change for a while. SSNs were still used when I came in 1996, and they were printed on the front of your ID card. After much protest and a couple of years, they were removed. I hear that entering students can now choose non-SSN ID numbers.
Sometimes I am anti-comment. When I get some example code that has 10+ lines of comments per line of actual code, I usually delete most of the comments so I can see what the heck the code is actually doing. There is such a thing as too much verbosity, or at the very least, some documentation shouldn't be in the middle of the function.
X aggregates drawing primitives, which is really what you want. In the big scheme of a windowing system, the time processing events is lost in the noise. What do you think the average ratio of drawing primitives to input events is for most applications? I'd guess its at least 1000:1 for anything with a modern gui.
In that case progress is being made and that's good to hear. Perhaps I came off a bit too negative in the GP. Pure modular/reconfigurable robots strike me as fantastically difficult, especially when you start talking about onboard power; Snake robots do have a future as you point out, but they still need some work to be useful for things like urban search and rescue. But then again, what robot doesn't need more work:) At any rate my main point is that we should distinguish caterpillars-like vs snake-like, and ultimately I think they'll be used for different things.
Though another take on it is that you could create any hybrid between pure snake and pure tracked, or even add wheels or rollers at some segments. The future will be interesting.
Slashdot Mirror
Officer: Can I see your software license and registration please?
Unfortunately, machine generated XML is rarely as pretty as your format, and in the case of Apple has far less meaningful tags denoting only names and types of properties. i.e. it throws out the parts of XML that are actually nice.
And what happens when you miss a > in XML, or mistype any tag name? These sorts of error are what validators were made for. The vasyt majority of programs should refuse improper input, as in the long term that's the only way to stay sane.
True, swing is one of the best (if not the best) toolkits out there. The last time I had to do serial IO on Java was in 2000, and at the time the version we had defined an interface for serial IO but had no working implementation (not helpful, guys). I'm sure that's been corrected by now though. At the time we had to cook something up using JNI, which was my first taste of that nastyness.
At least nowadays you can run on most computers with two sets of code: Posix and Windows. Thanks to OSX, it can be treated at another posix-like system.
That's an excellent point, and something I hadn't thought about. We'll just have to see how he does when he gets to start with a clean slate.
Yea for command line programs.
Which is the case for most numerical programs, as well as the amazing number of backends, daemons, cgi-programs, etc that run the digital world. They rarely get counted because they by definition have lower visibility than a GUI.
If you program uses a GUI then you are pretty much out of luck.
By out of luck do you mean you only have 5 choices for a toolkit rather than 2? I use FLTK myself, and am glad a "standard" was not shoved down my throat. Java rescued itself with a second toolkit, since the first one sucked. I don't see how that is more elegant than the 3rd party libraries competing for mindshare in the C/C++ world.
Before you rant about how much Java sucks I suggest trying Eclipse and Limewire. Those are two well written Java apps.
Good programs can be written in almost any language. It says far more about the developers than the language itself. In the case of Emacs/XEmacs, I'd even say they succeeded despite their use of a bad language for most of the functionality.
Java(tm) is more like a rethought fuck-up of C, than a C++ derivative.
These are the lessons from SML, OCaml, Clean, and modern Common Lisp compilers.
There were also lessons from their language design, which Java mostly ignored.
If you've been sleeping for the past 20 years, Guy Steele hasn't.
Then how do you explain Java being crappier feature-wise than pretty much every functional language? It doesn't even get all of the features from a pure-OOP language like smalltalk either. It took 10 years of thought after C++ to come up with something marginally better? On the bright side though, at least it isn't unityped...
Well if Java is a guide, they will have something called FNI, which will not be automatically generated in any way, will push all of glue code into Fortran (rather than in Fortress), and allow you to easily screw up the VM. But that's just a guess...
There are also reasons why Java its over-hyped:
(1) You give up speed for a marginal increase in features. (1b) If speed is not a factor, languages such as OCaml have many more features suitable for high-level programming. OCaml is also slightly faster than Java in general. Thus Java is both more primitive and slower than a language that came out in a similar time frame.
(2) You give up source portability for binary portability. Almost every platform has an ansi-C compiler, yet only a handful support Java, especially if you use a recent library. There are more platforms that support OpenGL than Java3D, for example.
(3) A company controls your language. The future of Java is at the whim of a single for-profit entity. Furthermore, this entity has displayed that it wants to control the Java language and the Java platform to the greatest extent possible.
(4) It's one of the most difficult languages to interface with C, and it pushes 100% of the glue required to the native language. It is easier to interface Lisp and Haskell with C than Java to C through JNI. Given the large difference between the former pairs, and the small differences between the latter pair, this is pretty ironic.
There are some sensors that cat get dense scans in 3D, but they are by no means cheap. I've also seen some (not open) research systems that recover amazingly detailed 3D world models from stereo. Unfortunately, it's still not easy to do anything: Once you overcome the sensing problem you still have lots of spatial reasoning problems. This gets even more fun outdoors where even the 3D data doesn't tell the whole story: A rock and a clump of grass can have similar 3D shapes, but for driving purposes they aren't nearly the same.
This stuff is hard, but progress is being made. Hopefully we'll get there.
But if future forklifts become self-aware, they might demand freedom too. Such is the risk of progress though.
Which, incidentally, is not supported in plain C.
Destructors help, but do you wrap every libc or kernel function you ever use in a class? In real-world programming one has to interface with the incredible bulk of C code that is out there, and wrapping absolutely everything is damn near impossible. Each goto label replaces an entire wrapper class. I really like OOP, but when you start to get into low level interfaces, sometimes its not the most elegant way.
I agree completely. I never used goto until I saw it used in the Linux kernel, just like in your example. It's helpful when you have locks/semaphores, which absolutely must be balanced. C++ destructors can help for not leaking memory on early returns, but locks and other state still need to be cleaned up after errors.
What I want is an editor that folds stupidly obvious comments while keeping the important ones, but even Emacs doesn't do that yet. Folding treats "set i to 0" the same as "FIXME - this is completely broken".
You are spot on. Large comments at the top of a function don't "break up" the work nearly as much as inline comments. Inline comments should not state the obvious, but merely state the sections identified in the top level comment, and describe the non-obvious(*). I always like the concept that "comments should state why you are doing something, not what you are doing."
(*) This is way too often overlooked. If it takes more than a bit of thinking to figure out why code is written the way it is, you should comment it. In other words, rather than one comment per line, I'd rather see very few comments on obvious lines, and 7 lines of comments for one line of voodoo.
You completely missed the point. Comments are like water, essential for life. That doesn't mean a raging flood is helpful for life.
CS department on the other hand has its own space, and much more lax rules. Many people in CS have root access to their machines
And many of us need that, so I'm not sure what the point here is: CS=="doing things with computers". And in the case of CMU CS IT, they are still using a RedHat 7 derivative, and still use Kerberos 4, and I'd like to run software from this century.
and no bandwidth policies, arbitrary quotas on AFS servers, etc.
Uh, there's sort of a bandwidth policy, which I discovered when a 40MB video of our research was linked in the first comment to a Slashdot article. Of course that was the andrew people who asked the cs people who asked me: You've used a months' worth of alowed bandwidth in 2 days, what's going on? Quotas on AFS aren't arbitrary... you have to telnet to "jeeves" and then you get a menu that lets you set your quota. Ok never mind, that's pretty arbitrary.
All of these are highly integrated, and frequently run on the single kerberos realm provided by IT. (You can log in and read files in CS with your Andrew account, etc)
That's just Kerberos and AFS being cool. They are different realms, but it still works due to cross realm support. You can either klog to get tickets in both realms, or set ACLs on both sides allowing access from the foriegn account (but don't forget to cklog the first time).
You are spot on about IT though; This breach really sounds like some admissions' person had an insecure computer (laptop maybe even?) with a database left on it. It's up to the business school to make sure there are as few copies of the data as possible. That's just good security in general, which has nothing directly to do with computers.
Now if the CS department gets breached electronically, I really will be annoyed, because they really should know better. CS should fall only to social engineering attacks taking advantage of dorks, which the business school should be more immune to.
They didn't change for a while. SSNs were still used when I came in 1996, and they were printed on the front of your ID card. After much protest and a couple of years, they were removed. I hear that entering students can now choose non-SSN ID numbers.
That's why I use darcs. Find out the differences with some surfing.
Sometimes I am anti-comment. When I get some example code that has 10+ lines of comments per line of actual code, I usually delete most of the comments so I can see what the heck the code is actually doing. There is such a thing as too much verbosity, or at the very least, some documentation shouldn't be in the middle of the function.
X aggregates drawing primitives, which is really what you want. In the big scheme of a windowing system, the time processing events is lost in the noise. What do you think the average ratio of drawing primitives to input events is for most applications? I'd guess its at least 1000:1 for anything with a modern gui.
And Mach/Hurd/L4 have demonstrated just how microkernels will develop rapidly and eclipse macrokernels with their superior features.
In that case progress is being made and that's good to hear. Perhaps I came off a bit too negative in the GP. Pure modular/reconfigurable robots strike me as fantastically difficult, especially when you start talking about onboard power; Snake robots do have a future as you point out, but they still need some work to be useful for things like urban search and rescue. But then again, what robot doesn't need more work :) At any rate my main point is that we should distinguish caterpillars-like vs snake-like, and ultimately I think they'll be used for different things.
Though another take on it is that you could create any hybrid between pure snake and pure tracked, or even add wheels or rollers at some segments. The future will be interesting.