Let's be honest: Documentation of open source programs is generally TERRIBLE.
Let's be even honester: documentation of all programs is generally terrible. You can pay $500 for an industry-standard closed-source product, only to find that what little documentation you get consists of tautologies like "Explaxuvize Frobnicants: Select this option to enable explaxuvization of frobnicants".
Commercial software companies are more likely to have policies in place that mandate that every UI element is documented, etc. But it's hard to think of a policy that would make sure the documentation is useful.
Why do you think the publishers of computer books like the Missing Manual series are doing so well? People don't go out and buy expensive books unless they need them.
For the latter, imagine if, instead of "rm -rf *", you'd have to type "delete all files in this folder, and I'm sure I want to do this". It's more verbose and much less efficient, but it's both more human-readable and likely much more dummy-proof. If someone can more easily understand what they're doing, they're more likely to stop and realise it may not be what they actually intended to do.
Solving the wrong problem there. Dummies will still just copy-and-paste the command from some forum thread, without reading it, and then be surprised when it does what it says. And non-dummies will turn your "helpful" feature off because it just gets in their way.
The correct solution to the problem of accidental file deletion is to provide an undelete function. All GUIs do this. The fact that most command lines do not suggests that command-line users do not, in practice, find that such a problem exists.
Anyone with the smallest foresight can see the trend is towards paper-thin, low power electronic displays. It may be 20+ years before they cost marginally more than paper and start to replace the more mundane uses, but it will.
Look back over the last few decades. You'll see a pattern again and again: everyone knows that $TECHNOLOGY is going to be the next big thing and is literally just 10 or 20 years away. Then, 10 or 20 years later, it simply hasn't happened, or is still too expensive to be useful. Look at AI, holographic storage, electric cars...
Do you seriously think it's ever going to be as cheap to manufacture an electronic display as to stick some wood pulp in a sieve?
But look at checks - 15 years ago I was writing 8+ paper checks a month. Now I probably write that many a year.
Yes, things change, it's true. But not everything (receipts are basically the same as they were 15 years ago), and the things that do change tend not to change in the ways we predict.
The article only mentioned netbooks, which would be insanely painful for programming.
Not so. Maybe if you insist on using an "IDE" that fills up your entire screen with toolbars and sidebars and crap. With a proper programmer's editor like vim or emacs, netbooks are fine.
Wrong! It's totally essential. Arrays in Java don't support the size() method that all other collections use to say how many elements they contain. So the only way to iterate over the contents of an array in Java is:
try {
Integer arrayIterationIndex = new Integer(0);
while (arrayIterationIndex != null) {
arrayInstance[arrayIterationIndex.intValue()].doSomething();
arrayIterationIndex = new Integer(arrayIterationIndex.intValue() + 1);
} } catch (ArrayIndexOutOfBoundsException wtf) { // reached end of array }
I hope I never end up maintaining any of your code, if you don't even know basic idioms like that.
Yes, OS X is Unix-certified. And Windows NT was POSIX-compliant. In both cases, it's largely irrelevant in practice, because the OSes heavily promote the use of their own proprietary APIs and discourage the use of standard interfaces.
The best coders I've worked with never even went to college, didn't finish, or graduated with a degree completely unrelated to computer science or IT.
My experiences are totally at odds with that - I've not yet found a truly gifted coder who doesn't have some degree - the best that I've worked with were the physics/maths graduates
Allow me to paraphrase your post: "I completely disagree. I completely agree."
Beryl may have been around when Vista was still Longhorn, but in all this time it has still not managed to be a stable compositor
Have I somehow gone back in time and started reading an ancient Slashdot discussion? In my timeline, Beryl is an old experiment that was officially discontinued several years ago.
And Compiz is perfectly stable and runs very smoothly even on netbook hardware.
Why would anyone go to all that effort? If I wanted to pirate fonts, I'm sure I'd find plenty of torrent sources available.
There's no point worrying about piracy, because the pirates already have your product. The only thing you need to worry about is keeping honest people honest, and you do that by making your product easy enough and cheap enough to buy that piracy doesn't look like an attractive option.
That's a heck of a lot of text for someone who clearly hasn't bothered to find out what this is about.
Would you say that designing a font is more, or less work than the following examples:
You're comparing apples and tractors. Type design has very little in common with programming. The open source community has a strong track record in programming, but a very poor track record in creative products.
There's a reason why the fonts on a typical Linux distribution include Bitstream Vera and Charter, URW Nimbus Sans/Roman, Bigelow & Holmes Luxi, and of course the Liberation fonts procured by Red Hat from Ascender Corp. And it's not because the "community" is good at making fonts.
That said, I'm not so sure how much we *need* another font format. Especially given that OpenType is an ISO standard, and has been for years. Just because it was developed by Microsoft and Adobe, doesn't mean it's not worth considering.
If you'd bothered to read the WOFF specification, you'd have found that WOFF is OpenType. Or rather, a minor extension of OpenType to provide some additional metadata and allow for compression of the font data.
You seem to be under the impression that this is an exercise in reinventing the wheel and replacing proprietary formats with open formats. It isn't. It's an exercise in building on the existing standards to provide extensions that make them better-adapted for use in a specific domain.
You will get useful output with sentences that are not too complex, for example indirect speech with third person and a few subsentences won't work as well as such simple things like "Can you tell me the way to the next restaurant, please?"
If that's supposed to be an example of a sentence that machine translation will be successful with, then you're still aiming too high.
For example, if you ask Google to translate that into Japanese, what it comes out with literally says "Please explain the following method to the restaurant beside me." Which is more likely to elicit a blank stare or helpless laughter than directions to the next restaurant.
Right. And these tools can actually do a reasonable job in highly controlled circumstances. For things like patents, where the language tends to be very formulaic and is carefully constructed to avoid ambiguity, machine translation is feasible.
Casual conversational language is another kettle of fish entirely. The "universal translator" is still science fiction, and looks likely to remain so for a long time.
It would seem simple to just discard the two dots and just have a// to specify the remote host.
// already has a meaning in UNIX: it means exactly the same as/,///,////, and any other number of slashes you care to enter. Changing this would break a lot of software.
For example, a script can safely write "$SOMEDIR/$SOMEFILE", and it will work perfectly even if $SOMEFILE is in the root directory and the user sets $SOMEDIR to "/". Imagine the confusion that would result if the script suddenly started trying to connect to "http://$SOMEFILE" instead!
It's fundamentally tackling the wrong problem. The passwords that are most at risk of being compromised are passwords to remote computers and web sites. The password you type into a desktop computer is the least likely ever to be attacked; and if it ever is attacked, the attack is likely to be a brute-force attack on the password database at rest, not some guy sitting down at your keyboard and typing stuff in at random like in the movies.
The only attack scenario this prevents is the case where someone gains access to your office and finds your password on a post-it note. And, frankly, if someone has managed to break into your office where you have passwords written on post-it notes, then that person logging into your computer is the least of your concerns.
Re:The guys behind EXTJS are terrible
on
Learning Ext JS
·
· Score: 1
if your code only calls functions in the library, you only need to provide a copy of the library (at no time is the library linked, either statically or dynamically, to your code);
This is plausible, and quite possibly true. But there are GPL advocates who would argue that loading your code into the same JS interpreter as the library is equivalent to linking.
The fact that the library's authors have dual-licensed it suggests that they take this harder line, since what's the point of a commercial license otherwise?
So failing to give away unobfuscated copies of your client-side JS under the GPL could still land you in court. And even if there's a good chance you'd win, I can see why most companies might want to avoid taking the risk when there are so many alternative libraries with less ambiguous licensing.
It's not even that. I have no problem using SQLite on ext4. It runs fine.
The real problem, I suspect, is that they're probably running those INSERTs individually. With SQLite it's very important to batch your INSERTs in transactions, because it does an fsync() every time it commits a transaction -- and that's what's so expensive on ext4.
My experience with python is that it is very easy to learn and to write, but hell to read if it is written by others.
My experience exactly. It is no better, and no worse, than any other language I've ever used. (Except FORTRAN (the old-fashioned sort), which is worse. But that's getting off topic.)
Python advocates often seem to be under the impression that inconsistent indentation is the leading cause of unreadable code. This is simply not true in my experience. I have seen code in some languages that used no indentation at all, and yet was perfectly comprehensible.
The real causes of unreadable code are bad or misleading variable and method names, poor or inaccurate comments, and spaghetti algorithms. And Python does absolutely nothing whatsoever to prevent any of these things. It doesn't even discourage the use of global variables!
As a result, python code written by your average script monkey is more readable.
Observe, my friends, the complete absence of citations to support this assertion. Observe the vagueness of the claim, and the lack of any reference even to an objective metric by which this alleged "readability" is supposed to be measured.
This is what is technically known as "bullshit". It is founded only on the claimant's personal prejudices, not on anything that could realistically be termed "evidence". The poster truly, genuinely believes that Python is better than Javascript -- but he has absolutely nothing to back up this view other than a religious conviction. So he quotes the sacred texts, instead of searching for a rational argument.
Re:Elite 2 and 3
on
Elite Turns 25
·
· Score: 2, Insightful
The problem with the sequels was that they went all out for realism, whereas the original went all out for fun.
So in the original, to fly to another system you undock, hyperspace, and apply your jump drive a few times. If you meet opposition, you engage in an exciting dogfight with usually several enemies.
In Frontier, to fly to another system you undock, fly outside hyperspace range, hyperspace, and then spend the next twenty minutes slowly accelerating and decelerating across an entire solar system. If you meet opposition, it takes the form of a single enemy. You remain relatively stationary while it flies slowly round you in circles, only coming into range for a few seconds every three or four minutes.
Realistic? Sure. Immersive? Yes, actually, for a few days. But the original was gripping for months, while the sequels got boring very quickly, and that was entirely down to the fact that realistic is not fun.
That ancient article (it's 20 years old, talking about 1980s Mac OS!) is not divinely inspired infallible truth.
It does not take muscle memory into account; it is a simple fact that certain very frequent key combinations, like that for "save", can literally become reflexive. I have had it timed. It does not take me anything like two seconds to remember "control+s". And it takes me significantly longer than two seconds to position the mouse pointer over the "save" button on the toolbar.
It also does not take complex actions into account. Modern applications tend to have many more features than was common 20 years ago. There is only a limited amount of room for toolbars. Once things are hidden in long menus, the mouse becomes more cumbersome to use. Particularly if you're performing a given action several times. Yeah, it might take five seconds to remember the key sequence, and only four seconds to find the menu option with the mouse. But it only takes one second to repeat the key sequence, so you only have to perform the action twice in a row for the keyboard to win!
A final point: yeah, maybe Apple did $50m of research in 1989. But Microsoft did a fair amount of research as well, rather more recently, when they were designing the Office 2007 interface. One result of that was that they put considerable effort into making keyboard shortcuts easier to learn. Why would they have done that, if learning keyboard shortcuts would make users less efficient?
Slashdot Mirror
Let's be even honester: documentation of all programs is generally terrible. You can pay $500 for an industry-standard closed-source product, only to find that what little documentation you get consists of tautologies like "Explaxuvize Frobnicants: Select this option to enable explaxuvization of frobnicants".
Commercial software companies are more likely to have policies in place that mandate that every UI element is documented, etc. But it's hard to think of a policy that would make sure the documentation is useful.
Why do you think the publishers of computer books like the Missing Manual series are doing so well? People don't go out and buy expensive books unless they need them.
Even better is the way she has Leonardo da Vinci (died 1519) drawing pictures of soybeans (introduced to Europe circa 1700).
I suppose that just proves his genius ...
Solving the wrong problem there. Dummies will still just copy-and-paste the command from some forum thread, without reading it, and then be surprised when it does what it says. And non-dummies will turn your "helpful" feature off because it just gets in their way.
The correct solution to the problem of accidental file deletion is to provide an undelete function. All GUIs do this. The fact that most command lines do not suggests that command-line users do not, in practice, find that such a problem exists.
Look back over the last few decades. You'll see a pattern again and again: everyone knows that $TECHNOLOGY is going to be the next big thing and is literally just 10 or 20 years away. Then, 10 or 20 years later, it simply hasn't happened, or is still too expensive to be useful. Look at AI, holographic storage, electric cars ...
Do you seriously think it's ever going to be as cheap to manufacture an electronic display as to stick some wood pulp in a sieve?
Yes, things change, it's true. But not everything (receipts are basically the same as they were 15 years ago), and the things that do change tend not to change in the ways we predict.
Not so. Maybe if you insist on using an "IDE" that fills up your entire screen with toolbars and sidebars and crap. With a proper programmer's editor like vim or emacs, netbooks are fine.
OS X is largely irrelevant to Apple's success or failure. It's the iPod that their current fortune is built on.
Wrong! It's totally essential. Arrays in Java don't support the size() method that all other collections use to say how many elements they contain. So the only way to iterate over the contents of an array in Java is:
I hope I never end up maintaining any of your code, if you don't even know basic idioms like that.
Yes, OS X is Unix-certified. And Windows NT was POSIX-compliant. In both cases, it's largely irrelevant in practice, because the OSes heavily promote the use of their own proprietary APIs and discourage the use of standard interfaces.
Allow me to paraphrase your post: "I completely disagree. I completely agree."
Have I somehow gone back in time and started reading an ancient Slashdot discussion? In my timeline, Beryl is an old experiment that was officially discontinued several years ago.
And Compiz is perfectly stable and runs very smoothly even on netbook hardware.
Why would anyone go to all that effort? If I wanted to pirate fonts, I'm sure I'd find plenty of torrent sources available.
There's no point worrying about piracy, because the pirates already have your product. The only thing you need to worry about is keeping honest people honest, and you do that by making your product easy enough and cheap enough to buy that piracy doesn't look like an attractive option.
That's a heck of a lot of text for someone who clearly hasn't bothered to find out what this is about.
You're comparing apples and tractors. Type design has very little in common with programming. The open source community has a strong track record in programming, but a very poor track record in creative products.
There's a reason why the fonts on a typical Linux distribution include Bitstream Vera and Charter, URW Nimbus Sans/Roman, Bigelow & Holmes Luxi, and of course the Liberation fonts procured by Red Hat from Ascender Corp. And it's not because the "community" is good at making fonts.
If you'd bothered to read the WOFF specification, you'd have found that WOFF is OpenType. Or rather, a minor extension of OpenType to provide some additional metadata and allow for compression of the font data.
You seem to be under the impression that this is an exercise in reinventing the wheel and replacing proprietary formats with open formats. It isn't. It's an exercise in building on the existing standards to provide extensions that make them better-adapted for use in a specific domain.
If that's supposed to be an example of a sentence that machine translation will be successful with, then you're still aiming too high.
For example, if you ask Google to translate that into Japanese, what it comes out with literally says "Please explain the following method to the restaurant beside me." Which is more likely to elicit a blank stare or helpless laughter than directions to the next restaurant.
Right. And these tools can actually do a reasonable job in highly controlled circumstances. For things like patents, where the language tends to be very formulaic and is carefully constructed to avoid ambiguity, machine translation is feasible.
Casual conversational language is another kettle of fish entirely. The "universal translator" is still science fiction, and looks likely to remain so for a long time.
You don't tend to get a high score unless you play the game. Why were all these people playing the game if it sucked?
Amen, brother! Let us unite to prevent all these evil programmers from oppressing us by making a living out of their code.
This logical course of action is certain to ensure that they will continue to write high-quality software for us to pirate! Yarr!
// already has a meaning in UNIX: it means exactly the same as /, ///, ////, and any other number of slashes you care to enter. Changing this would break a lot of software.
For example, a script can safely write "$SOMEDIR/$SOMEFILE", and it will work perfectly even if $SOMEFILE is in the root directory and the user sets $SOMEDIR to "/". Imagine the confusion that would result if the script suddenly started trying to connect to "http://$SOMEFILE" instead!
The thing is, it's misguided and pointless.
It's fundamentally tackling the wrong problem. The passwords that are most at risk of being compromised are passwords to remote computers and web sites. The password you type into a desktop computer is the least likely ever to be attacked; and if it ever is attacked, the attack is likely to be a brute-force attack on the password database at rest, not some guy sitting down at your keyboard and typing stuff in at random like in the movies.
The only attack scenario this prevents is the case where someone gains access to your office and finds your password on a post-it note. And, frankly, if someone has managed to break into your office where you have passwords written on post-it notes, then that person logging into your computer is the least of your concerns.
This is plausible, and quite possibly true. But there are GPL advocates who would argue that loading your code into the same JS interpreter as the library is equivalent to linking.
The fact that the library's authors have dual-licensed it suggests that they take this harder line, since what's the point of a commercial license otherwise?
So failing to give away unobfuscated copies of your client-side JS under the GPL could still land you in court. And even if there's a good chance you'd win, I can see why most companies might want to avoid taking the risk when there are so many alternative libraries with less ambiguous licensing.
It's not even that. I have no problem using SQLite on ext4. It runs fine.
The real problem, I suspect, is that they're probably running those INSERTs individually. With SQLite it's very important to batch your INSERTs in transactions, because it does an fsync() every time it commits a transaction -- and that's what's so expensive on ext4.
My experience exactly. It is no better, and no worse, than any other language I've ever used. (Except FORTRAN (the old-fashioned sort), which is worse. But that's getting off topic.)
Python advocates often seem to be under the impression that inconsistent indentation is the leading cause of unreadable code. This is simply not true in my experience. I have seen code in some languages that used no indentation at all, and yet was perfectly comprehensible.
The real causes of unreadable code are bad or misleading variable and method names, poor or inaccurate comments, and spaghetti algorithms. And Python does absolutely nothing whatsoever to prevent any of these things. It doesn't even discourage the use of global variables!
Observe, my friends, the complete absence of citations to support this assertion. Observe the vagueness of the claim, and the lack of any reference even to an objective metric by which this alleged "readability" is supposed to be measured.
This is what is technically known as "bullshit". It is founded only on the claimant's personal prejudices, not on anything that could realistically be termed "evidence". The poster truly, genuinely believes that Python is better than Javascript -- but he has absolutely nothing to back up this view other than a religious conviction. So he quotes the sacred texts, instead of searching for a rational argument.
The problem with the sequels was that they went all out for realism, whereas the original went all out for fun.
So in the original, to fly to another system you undock, hyperspace, and apply your jump drive a few times. If you meet opposition, you engage in an exciting dogfight with usually several enemies.
In Frontier, to fly to another system you undock, fly outside hyperspace range, hyperspace, and then spend the next twenty minutes slowly accelerating and decelerating across an entire solar system. If you meet opposition, it takes the form of a single enemy. You remain relatively stationary while it flies slowly round you in circles, only coming into range for a few seconds every three or four minutes.
Realistic? Sure. Immersive? Yes, actually, for a few days. But the original was gripping for months, while the sequels got boring very quickly, and that was entirely down to the fact that realistic is not fun.
That simply isn't true -- at least, not of the BBC Micro, which came in a number of different configurations and was easily upgraded.
And just how many models of Apple II were there, again?
And let's not even get into the MSX, which was produced in dozens of variations by different manufacturers.
"Podcast" means an MP3 of people talking. That's all.
That ancient article (it's 20 years old, talking about 1980s Mac OS!) is not divinely inspired infallible truth.
It does not take muscle memory into account; it is a simple fact that certain very frequent key combinations, like that for "save", can literally become reflexive. I have had it timed. It does not take me anything like two seconds to remember "control+s". And it takes me significantly longer than two seconds to position the mouse pointer over the "save" button on the toolbar.
It also does not take complex actions into account. Modern applications tend to have many more features than was common 20 years ago. There is only a limited amount of room for toolbars. Once things are hidden in long menus, the mouse becomes more cumbersome to use. Particularly if you're performing a given action several times. Yeah, it might take five seconds to remember the key sequence, and only four seconds to find the menu option with the mouse. But it only takes one second to repeat the key sequence, so you only have to perform the action twice in a row for the keyboard to win!
A final point: yeah, maybe Apple did $50m of research in 1989. But Microsoft did a fair amount of research as well, rather more recently, when they were designing the Office 2007 interface. One result of that was that they put considerable effort into making keyboard shortcuts easier to learn. Why would they have done that, if learning keyboard shortcuts would make users less efficient?