Objective-C was unfortunately the path not taken when C++ was starting to take off. The syntax is a bit odd, but it does OO in a cleaner and more featureful way than C++. It's a pity that, even after all this time, it has not gained the popularity it deserves, especially given that there are new checklist items in recently-developed programming languages that it hasn't added to its resume, but it is still an excellent development environment that in its time was ahead of everything else out there (not unlike NeXTStep itself). I should disclaim that I am a former NeXTStep user/developer who moved on a very long time ago to more vanilla Unices, and now program in primarily in C, Java, and Perl.
I know that at one point, it was considered necessary and useful to understand things, and people generally were expected to really think things through before posing stupid ideas and thinking we need to change the whole world without any reason every so often.
Having done tech support, programming, and a number of similar jobs, I have to say that neither I nor anyone I have worked with have thrown or otherwise abused computer equipment. If they had, I suspect they would have been canned immediately, and for good reason -- people who can't control themselves are a bit.. 'off'. The only person I know who actually has destroyed computer hardware was a layperson musician/artist who was having problems with some sound editing software.. he was very embarassed for the whole trip to MicroCenter to replace the keyboard, mouse, and CDROM drive. The point is that destroying things when angry is childish, and is something that hopefully most people outgrow by the time they're 14 or so.
I am involved in psychology research that involves neuroimaging, and also have, off and on, been playing with OsiriX. I agree that it's one of the best tools out there, but unfortunately I can't justify (I am also the sysadmin for the group I'm in) buying high-end Macs for all the researchers in the group that use the scanner. There are some things that I would like to see us able to do that Osirix does and our other tools (Xmedcon, the AIR/NIS/AFNI suites) don't do, and I haven't yet looked into BrainVoyager (so expensive!), but for now, we're sticking with Linux for our research.
It's not an abuse of power, but it is BLOGesque whining, and is pretty lame to see here. Imagine if on CNN, Ted Turner came on and talked about how he had bad service at a restaurant. It'd just make you think, "man is that guy a loser". Who does CmdrTaco think he is, jwz?:)
There's something to be said for reserving one's stamp of authenticity, whether it be a signature or not, for things that are actually from one. It seems unnecessary and precisely akin to protecting one's signature from appearing on material that pokes fun at oneself -- there's nothing funny about the seal itself, and it would not change the humour to replace that seal with a mock seal. Parody should be seen to be a nearly blank check when it comes to making fun of the attributes of someone or something, and in my opinion, traditional intellectual property law totally sucks, but protecting one's sigil/signature is a reasonable thing to do.
Obviously, this is not forgery with an intent to fool, but like posting unaltered dollar bill photographs on a website, it's at least uncool and asking for trouble.
At one point I recall reading a paper that, while perhaps a bit too self-praising, described unix culture (and similarly the programming crowd associated with it) to be a very literate culture, viewing the flow of information through various streams, filters, etc, as something that draws similar people to those who have a love of words, wordplay, and literature. Anyone recall the specific paper/website/source?
Regexes are *wrong*? What does that mean? How are they wrong? I can understand that you might not like them, but can you make the case for anything more?
Further, I would say that Java indeed makes a lot of things easy that are harder in C. It provides much more capable classes with a number of very useful operations on them. Also, strings don't suck, and collections are safer than arrays. Java makes memory management much simpler. If you look at Java and don't see any of these things, I think you've somehow missed out on a lot of things that C programmers (like me) can get from Java.
I understand your disappointment that only Java and C were considered. Frankly, although I love C and grew up on it, I don't think it should be considered for most things where it is used today -- it is a traditional choice, but given where Java has moved the industry, its conservativism has led to senility. Java draws on a lot of its good choices (and syntax), and that's why it's seen in many circles as the successor to C (and to a degree, C++, which IMO was largely a collection of mistakes). No other programming language is very close to how good Java is for general systems programming, at least partly because of the maturity of many of the ideas that have led to Java. Unfortunately, Sun screwed up in instability of the language spec a few times, which has hurt Java a lot, but it's still considered the best tool for most jobs. Things have been this way for a long time though -- for general purpose programming there has usually been one dominant language, a few other languages that are kind of near, the up-and coming, the obsolescent, and a number of toy and domain-specific languages. Before Java, C was dominant, and before C, Fortran. I think we've made progress with each transition. I might have hoped that things had gone another way (e.g. ObjC instead of Java), but things are looking pretty good now. Maybe Ruby will take the crown next.
Although it's an uphill battle to make the language help programmers avoid insecure code, it's an uphill battle worth facing. Progress in doing so is important progress to make, even if it is very hard. Even very competent programmers sometimes make mistakes, and I'd wager they happen more often in languages that don't help them. Having good tools is always a good thing -- I, for example, find programming without vim and all my customizations to it to be extremely irritating.
As for regexes, it's possible for them to work well -- implementing a parser is often a bad idea. Regexes are easy to misunderstand, but when done right, they're really nice.
Personally, I see functional languages as toys, but if you see them as more, use 'em.
People who can't spell words in the English language like "aggravate" might not be the best people to look for deep and insightful attacks on what everybody else agrees on. I'm not saying that having good spelling would make his point any more valid, but it should at least be a rule of thumb for those who can't bother to think about his point on their own (as the poster of this article can't).
To get more into it, yes, the C runtime is smaller than the Java runtime, and there is a certain trustworthiness in having your code small. However, languages like C where the basic type system requires a lot of care to avoid bugs starts you off considerably behind just having a large runtime. In C, it requires almost no thought at all to write insecure code, and to do some things securely requires chunks of wrapper code around most things involving IO layers, wrapper code that is not program logic and can have bugs. In higher-level languages, the user won't be writing that code -- the engineers at Sun will, and because that code gets exercised by the entire world, its bugs will be found and removed very quickly.
Of course, in both cases, we're not really talking about the language being secure, we're talking about how likely it is that, given equivalent tasks, people using the different languages will end up writing secure code. To weigh that, we all use rules of thumb based on what we know causes errors -- he invokes bulk of code, but doesn't think about how the used code in that bulk will need to be written anyway and will be reused by every Java programmer. As I said before, I think a caveat-emptor type system is another major factor to be considered. Other (generally obvious) rules of thumb that go against this guy are left as an exercise for the reader.
It is not in the public interest to have advertising companies doing this. Such companies do little to no public good and a certain amount of public harm in their normal course of operations by wasting resources. They do considerably more harm in these cases. It would be ideal to do structural changes to DNS to make their model of business unprofitable or undoable, or legal changes to make it illegal. As a lesser solution, perhaps practices like this should be illegal or prohibited.
How about instead, Popular songs sell a lot more, generating more revenue to the ones making and distributing them. Maybe *this* will encourage bands to create more songs that people actually like.
It seems kind of antisocial..
on
Wi-Fi Times Sixteen
·
· Score: 4, Interesting
I hope people are careful where they use it -- using all the channels at the same time seems quite antisocial to any other networks that might be in the area.
But I don't expect Slashdot to have the flavour of overhearing a bunch of drunken fratboys bragging about their latest conquests. I'm glad that Slashdot has the ability to filter out articles posted by particular editors. Zonk? *plonk*
That may be nice for some people, but I'd rather not be running Java just to do bittorrent, and actually like the nice, curses interface that runs in a terminal. It's not a big deal, but if you want to be really nice to your end users (and the networks between you and them), please consider that most people don't want to download custom clients, so it'd be very cool to provide the more select downloads.
I wish they had separate torrents for the FLAC and the mp3s. I imagine most people will just want one or the other, and it's a waste of bandwidth to get both.
The problem is that it is forbidden to fix later, burdening the system with a shortsighted legacy./usr/lib is reserved for 32-bit legacy libries on amd64, and/usr/lib64 is reserved for 64-bit native libraries. If they wanted to put the legacy libraries in lib32 and native libraries in either lib (ideal) or lib64 and use a symlink (less ideal), that'd be fine. The mandate that things be perpetually the wrong way around is what bothers me. To be clear, your symlink breaks the standard and also neglects the issue that LSB-compliant native code must incorporate the lib64 mess.
What are you talking about with regards to hard-linked directories anyhow? Very few filesystems support directory hardlinks, and given what userland applications expect and do in practice, directory hardlinks are unsafe to use on the few filesystems that support them anyhow.
If anyone goes, try to bring up the mess they've made for amd64 -- that native 64-bit libraries don't live in/usr/lib, instead living in/usr/lib64. This is a mess, and in a few years the excuse that it's there for compatibility won't matter. It's not cool to pay more attention to backwards compatibility than to native code, and it's always something one regrets later. Another counterargument -- that legacy software that needs to find libraries to load or link to at runtime could easily be handled by making ld a little bit smarter, rather than complicating and uglifying the simple, native case.
I remember running NeXTStep 4.2 on white hardware, and it once had its own bootloader that could handle multiboot. I guess they took it out for OSX/White?
It doesn't help that English spelling is such a mess. In order to really know how to map sounds to spelling, one needs to (perhaps unconsciously) learn a number of rules corrisponding to the bewildering number of languages that have been borrowed from in constructing American (or British, or Australian, or...) English. Somehow we all manage, more or less, to do it, but it's worth noting that in a lot of other languages, it's a lot harder to misspell words, and spelling bees seem somewhat humourous.
True, but installing KDE on many non-Linux, non-BSD systems is nontrivial (although not as hard as GNOME). Adobe Acrobat Reader 7 isn't available as source, so for many platforms, it's not an option (although they're pretty good at supporting a lot of the more popular platforms).
I can understand that ggv has some possibly tricky dependencies, but xpdf is pretty easy to compile on any Unix. I've compiled it on a number of oddball unices without problem.
Slashdot Mirror
Objective-C was unfortunately the path not taken when C++ was starting to take off. The syntax is a bit odd, but it does OO in a cleaner and more featureful way than C++. It's a pity that, even after all this time, it has not gained the popularity it deserves, especially given that there are new checklist items in recently-developed programming languages that it hasn't added to its resume, but it is still an excellent development environment that in its time was ahead of everything else out there (not unlike NeXTStep itself). I should disclaim that I am a former NeXTStep user/developer who moved on a very long time ago to more vanilla Unices, and now program in primarily in C, Java, and Perl.
I know that at one point, it was considered necessary and useful to understand things, and people generally were expected to really think things through before posing stupid ideas and thinking we need to change the whole world without any reason every so often.
Having done tech support, programming, and a number of similar jobs, I have to say that neither I nor anyone I have worked with have thrown or otherwise abused computer equipment. If they had, I suspect they would have been canned immediately, and for good reason -- people who can't control themselves are a bit .. 'off'. The only person I know who actually has destroyed computer hardware was a layperson musician/artist who was having problems with some sound editing software.. he was very embarassed for the whole trip to MicroCenter to replace the keyboard, mouse, and CDROM drive. The point is that destroying things when angry is childish, and is something that hopefully most people outgrow by the time they're 14 or so.
I am involved in psychology research that involves neuroimaging, and also have, off and on, been playing with OsiriX. I agree that it's one of the best tools out there, but unfortunately I can't justify (I am also the sysadmin for the group I'm in) buying high-end Macs for all the researchers in the group that use the scanner. There are some things that I would like to see us able to do that Osirix does and our other tools (Xmedcon, the AIR/NIS/AFNI suites) don't do, and I haven't yet looked into BrainVoyager (so expensive!), but for now, we're sticking with Linux for our research.
It's not an abuse of power, but it is BLOGesque whining, and is pretty lame to see here. Imagine if on CNN, Ted Turner came on and talked about how he had bad service at a restaurant. It'd just make you think, "man is that guy a loser". Who does CmdrTaco think he is, jwz? :)
Out of curiosity, do you mean wiener or whiner? If you're going to insult me, you should at least be intelligible :)
There's something to be said for reserving one's stamp of authenticity, whether it be a signature or not, for things that are actually from one. It seems unnecessary and precisely akin to protecting one's signature from appearing on material that pokes fun at oneself -- there's nothing funny about the seal itself, and it would not change the humour to replace that seal with a mock seal. Parody should be seen to be a nearly blank check when it comes to making fun of the attributes of someone or something, and in my opinion, traditional intellectual property law totally sucks, but protecting one's sigil/signature is a reasonable thing to do.
Obviously, this is not forgery with an intent to fool, but like posting unaltered dollar bill photographs on a website, it's at least uncool and asking for trouble.
At one point I recall reading a paper that, while perhaps a bit too self-praising, described unix culture (and similarly the programming crowd associated with it) to be a very literate culture, viewing the flow of information through various streams, filters, etc, as something that draws similar people to those who have a love of words, wordplay, and literature. Anyone recall the specific paper/website/source?
Regexes are *wrong*? What does that mean? How are they wrong? I can understand that you might not like them, but can you make the case for anything more?
Further, I would say that Java indeed makes a lot of things easy that are harder in C. It provides much more capable classes with a number of very useful operations on them. Also, strings don't suck, and collections are safer than arrays. Java makes memory management much simpler. If you look at Java and don't see any of these things, I think you've somehow missed out on a lot of things that C programmers (like me) can get from Java.
I understand your disappointment that only Java and C were considered. Frankly, although I love C and grew up on it, I don't think it should be considered for most things where it is used today -- it is a traditional choice, but given where Java has moved the industry, its conservativism has led to senility. Java draws on a lot of its good choices (and syntax), and that's why it's seen in many circles as the successor to C (and to a degree, C++, which IMO was largely a collection of mistakes). No other programming language is very close to how good Java is for general systems programming, at least partly because of the maturity of many of the ideas that have led to Java. Unfortunately, Sun screwed up in instability of the language spec a few times, which has hurt Java a lot, but it's still considered the best tool for most jobs. Things have been this way for a long time though -- for general purpose programming there has usually been one dominant language, a few other languages that are kind of near, the up-and coming, the obsolescent, and a number of toy and domain-specific languages. Before Java, C was dominant, and before C, Fortran. I think we've made progress with each transition. I might have hoped that things had gone another way (e.g. ObjC instead of Java), but things are looking pretty good now. Maybe Ruby will take the crown next.
The article was a little bit short and without sufficient substance to be noteworthy on slashdot, I think.
A few specific comments --
Although it's an uphill battle to make the language help programmers avoid insecure code, it's an uphill battle worth facing. Progress in doing so is important progress to make, even if it is very hard. Even very competent programmers sometimes make mistakes, and I'd wager they happen more often in languages that don't help them. Having good tools is always a good thing -- I, for example, find programming without vim and all my customizations to it to be extremely irritating.
As for regexes, it's possible for them to work well -- implementing a parser is often a bad idea. Regexes are easy to misunderstand, but when done right, they're really nice.
Personally, I see functional languages as toys, but if you see them as more, use 'em.
People who can't spell words in the English language like "aggravate" might not be the best people to look for deep and insightful attacks on what everybody else agrees on. I'm not saying that having good spelling would make his point any more valid, but it should at least be a rule of thumb for those who can't bother to think about his point on their own (as the poster of this article can't).
To get more into it, yes, the C runtime is smaller than the Java runtime, and there is a certain trustworthiness in having your code small. However, languages like C where the basic type system requires a lot of care to avoid bugs starts you off considerably behind just having a large runtime. In C, it requires almost no thought at all to write insecure code, and to do some things securely requires chunks of wrapper code around most things involving IO layers, wrapper code that is not program logic and can have bugs. In higher-level languages, the user won't be writing that code -- the engineers at Sun will, and because that code gets exercised by the entire world, its bugs will be found and removed very quickly.
Of course, in both cases, we're not really talking about the language being secure, we're talking about how likely it is that, given equivalent tasks, people using the different languages will end up writing secure code. To weigh that, we all use rules of thumb based on what we know causes errors -- he invokes bulk of code, but doesn't think about how the used code in that bulk will need to be written anyway and will be reused by every Java programmer. As I said before, I think a caveat-emptor type system is another major factor to be considered. Other (generally obvious) rules of thumb that go against this guy are left as an exercise for the reader.
It is not in the public interest to have advertising companies doing this. Such companies do little to no public good and a certain amount of public harm in their normal course of operations by wasting resources. They do considerably more harm in these cases. It would be ideal to do structural changes to DNS to make their model of business unprofitable or undoable, or legal changes to make it illegal. As a lesser solution, perhaps practices like this should be illegal or prohibited.
How about instead, Popular songs sell a lot more, generating more revenue to the ones making and distributing them. Maybe *this* will encourage bands to create more songs that people actually like.
I hope people are careful where they use it -- using all the channels at the same time seems quite antisocial to any other networks that might be in the area.
But I don't expect Slashdot to have the flavour of overhearing a bunch of drunken fratboys bragging about their latest conquests. I'm glad that Slashdot has the ability to filter out articles posted by particular editors. Zonk? *plonk*
That may be nice for some people, but I'd rather not be running Java just to do bittorrent, and actually like the nice, curses interface that runs in a terminal. It's not a big deal, but if you want to be really nice to your end users (and the networks between you and them), please consider that most people don't want to download custom clients, so it'd be very cool to provide the more select downloads.
I wish they had separate torrents for the FLAC and the mp3s. I imagine most people will just want one or the other, and it's a waste of bandwidth to get both.
The problem is that it is forbidden to fix later, burdening the system with a shortsighted legacy. /usr/lib is reserved for 32-bit legacy libries on amd64, and /usr/lib64 is reserved for 64-bit native libraries. If they wanted to put the legacy libraries in lib32 and native libraries in either lib (ideal) or lib64 and use a symlink (less ideal), that'd be fine. The mandate that things be perpetually the wrong way around is what bothers me. To be clear, your symlink breaks the standard and also neglects the issue that LSB-compliant native code must incorporate the lib64 mess.
What are you talking about with regards to hard-linked directories anyhow? Very few filesystems support directory hardlinks, and given what userland applications expect and do in practice, directory hardlinks are unsafe to use on the few filesystems that support them anyhow.
If anyone goes, try to bring up the mess they've made for amd64 -- that native 64-bit libraries don't live in /usr/lib, instead living in /usr/lib64. This is a mess, and in a few years the excuse that it's there for compatibility won't matter. It's not cool to pay more attention to backwards compatibility than to native code, and it's always something one regrets later. Another counterargument -- that legacy software that needs to find libraries to load or link to at runtime could easily be handled by making ld a little bit smarter, rather than complicating and uglifying the simple, native case.
I remember running NeXTStep 4.2 on white hardware, and it once had its own bootloader that could handle multiboot. I guess they took it out for OSX/White?
It doesn't help that English spelling is such a mess. In order to really know how to map sounds to spelling, one needs to (perhaps unconsciously) learn a number of rules corrisponding to the bewildering number of languages that have been borrowed from in constructing American (or British, or Australian, or ...) English. Somehow we all manage, more or less, to do it, but it's worth noting that in a lot of other languages, it's a lot harder to misspell words, and spelling bees seem somewhat humourous.
Then you may as well be already dead. Whatever age one is, wherever one is in life, TV tempts people away from meaningful interaction with each other.
True, but installing KDE on many non-Linux, non-BSD systems is nontrivial (although not as hard as GNOME). Adobe Acrobat Reader 7 isn't available as source, so for many platforms, it's not an option (although they're pretty good at supporting a lot of the more popular platforms).
I can understand that ggv has some possibly tricky dependencies, but xpdf is pretty easy to compile on any Unix. I've compiled it on a number of oddball unices without problem.