If you can factor the loop into its own function, you can replace the goto with a return to please the "I read somewhere that gotos must never be used" folks.:-)
Seriously though, IMHO gotos should be used just like that -- to handle function-local exception conditions. Gotos should be avoided when they make code hard to follow, but why avoid them when they make the code easier to read? On the other hand, "open classes" as Ruby calls them -- *cough*COMEFROM*cough* -- they are pure evil.;-)
Even if LSI wants to (somehow) claim that the doubly-linked list doesn't count as prior art, maintaining linked lists of graphical objects sorted by both x and y co-ordinates for collision detection has been done since "graphical objects" meant ASCII characters on a green-on-black screen, and has probably been widespread in databases for probably even longer."
But in the end I think all this "we can do that too" mentality ends up stifling free software. While I applaud the efforts of OO and am grateful for it's inclusion in modern distros I would also love to see them wake up one day and deceide they were going to take a "and now for something completely different" approach.
Take a look at LyX for a completely different take on word processing. I've found its user interface to be very pleasant to work with---all you have to do is write, and everything turns out looking great without you having to give it any thought. It's not compatible with MS Office or OO.o, but it's still great for creating PDFs and printed documents.
Finally, there is a Python script. At first glance, it looks slightly better. It uses what appears to be the Python equivalent of HTML::Parse to get links. But a closer look reveals that, to find links, it just gets the first attribute of any a tag and uses that as the link. Never mind if the 1st attribute doesn't happen to be "href".
What bugs me the most about this article is that the author keeps using the most generic libraries he can find instead of something written for this exact task. He should have used WWW:Mechanize for Perl or mechanize for Python. I'm sure there's something like this for Ruby, too.
In a phyiscal invention the gears and levels are easy to take apart to see how they work. This is one reason patents (which are basically copyrights for physical things) are nessesary, as reverse engineering is easy in the physical world. In the computer world copyright and keeping your source secure, is effectivly your assurance that someone won't simply rip off your idea.
There is another way in which software inventions are essentially different from physical inventions. In the physical world having an idea, and specifying it in detail is only the first (and relatively cheap) step. Getting your invention from the drawing board to mass production can end up being a very costly and risky undertaking. Patents are needed to assure the inventor, that after he has spent the needed resources to create a new product, he won't get ripped off by other companies which have waited to see how the R&D project pans out.
The world of software is different. As you summed it up in your last sentence, securing the source code prevents people from ripping the idea off. That's because the source code is the idea, described in ultimate detail, while simultaneously being a product that you can sell. There is no expensive process needed to transofrm the idea into a product, describing it in detail is enough. Because of that, software patents don't encourage anyone to bring new products to the market (thus increasing competition) -- quite on the contrary, patent holders are using them to stifle the competition's attempts at doing that.
This makes regular patents good but software patents purely evil in my book.
Huge firms: Custom-modified OOo tailored to their needs. (after all, it's open source. You can't modify MSO because you don't have the sources.)
Last I heard, the amount of user-contributed patches to OpenOffice.org was 0 (zero). There are very few people on this earth who are able to compile (let alone modify) a custom build of the monster that is OpenOffice.org. There is only one huge company modifying OpenOffice.org to their needs, and that's Sun.
The point is not to give free tools to people - it is to educate a small percentage of the 3rd world people to a level of expertise in which they will be able to support the information processing needs of their countries, i.e. create affordable software for which they don't have to send money out of their countries to Apple/Microsoft/etc.
Giving out free Mac OS Xs would just make sure that they will only end up using the computers and not tinkering with them at all. This would create a situation in which the 3rd world people would remain cheap labor for sports shoe manufacturers while the (expensive) IT expertise would remain in today's economic powers.
Re:So how do you write tests for ..
on
Microsoft Lauds Scrum
·
· Score: 2, Insightful
applications that are a constantly moving target "this would be cool to have"
How can you write any code for an application if you don't know what it's supposed to do? When you have a functional specification, you can write tests that test the specified features. When the spec changes you change the tests accordingly to help you make sure that you don't introduce new bugs when changing your code.
applications with changing data sets - you can run your tests fine on the standardized data set, but then when it hits the real-world data, all you can say is "Sorry my application is perfect, it just doesn't work with with that data."
Are you suggesting that having no tests would make that particular application work with real-world data? The point of testing is not to prove the customer that your application is flawless (that's impossible) but to help the programmers catch errors like the one you describe.
When you're writing a test, you are making sure that your application works in one particular case. If you don't know what the possible cases are, not only will that prevent you from writing tests - it will also prevent you from writing working code.
"But you can't test everything!" is a dumb excuse for not testing at all. It's like refusing to wear a bullet proof vest because it's useless if you get shot in the head.
I've replaced my Windows gvim's _vimrc with my hand-written.vimrc that I use everywhere I have a shell account, and I haven't noticed the behaviour you described. I'm quite sure that the default _vimrc sets an option that does that.
One thing is certain, these cameras do not save any lives. I remember clearly once in high school a Policeman came to give a talk on vehicle safety he showed us a big graph with a stedily declining death rate over the years, he pointed out the huge drop after the introduction of seat bealts, then one after they banned drink driving, and a smaller drop after the introduction of airbags. My hand immediently shot up and I asked him when speed cameras were introduced, my teachers just laughed and he never answered the question.
Your question was answered by a Finnish study recently (only a Finnish link, sorry). The headline says "Camera control halved the amount of accidents resulting in death".
The article also states that "Camera control does not affect the number of accidents but the accidents are less severe than before. For example, the amount of fatal accidents has been reduced to less than a half."
I'll rather believe an official study than your so very logical proof: My teacher laughed at my question --> cameras do not save any lives.:-P
That said, I haven't seen a really good way to manage permissions. It's just not practical for an applet to say, "In order to run this, you need these 47 permissions" and expect you to fix that. With cleverness the modeler could create roles with aggregates of permissions, so that you can say, "This app needs access to your browser UI" (like Tabbrowser).
I find it interesting that every application has to wrestle with these problems time and time again, instead of them being solved by the operating system. The reason for all this trouble is that the Access Control List security model is inherently flawed.
Using ACLs makes us adjust permissions per user basis, while it is not the user who does (good or evil) things with the computer but the processes running on behalf of the user. Thus an application can (be tricked to) do malicious things with the user's full permissions - as if the user himself was actively and knowingly destroying his data, sending it over to an eavesdropper, etc. A correct approach would be to grant permissions to do a certain operation on a certain resource per process basis. This is what the capability based security is all about. (If I am mistaken, I hope someone more enlightened in CAP theory will correct me).
I am amazed that none of the popular operating systems implement capability based security models, since they would eliminate Confused Deputy Problems like this.
Some random links relating to Capability based security:
Providing an easier interface (an abstraction layer) over the existing tools does not take anything away from the power users. They can always choose to ignore the interface and use the underpinnings directly. For example, I can drive a car but I have no idea of what's going on under the hood. I still have the need to drive the car and every right to do so. Likewise a car mechanic needs and has every right to use a computer. If a person does not have a degree in computer science, that does not mean that he is dumb.
Higher levels of abstraction don't mean decreased efficiency. If they would, we'd still be writing all the software in assembly.
One seldom commented disadvantage of tightly integrated desktops like Gnome/KDE is their lack of extensibility.
It's seldom commented because there is no such thing. The interoperability features that KDE provides are way more advanced than UNIX pipes.
Case in point: DCOP. Using the console DCOP client, or the DCOP APIs you can control almost every KDE program from your scripts. For example, if you want to pop up the K menu at the mouse cursor, just call `dcop kicker kicker popupKMenu 0`. Want to switch to the next virtual desktop using your script? No problem: `dcop kwin KWinInterface nextDesktop`.
With the evolving desktop, people stop writing general purpose tools that abstract data and functionalities as simple files and scripts, and instead write their stuff for specific desktops.
I don't really understand what your point is. AFAIK (correct me if I'm wrong) there is nothing stopping you from using DCOP calls from a GNOME or XFCE application. If you are interacting with application X from your script, your script naturally depends on X. It doesn't matter if you use DCOP, D-BUS or pipes to do that.
"They don't want to throw people in lonely prisons after they publish damaging things, they want to prevent damaging things from being published."
And the most effective way to do that is to make an example of those pioneering this new way of free speech and their loved ones - there are many people who are willing to give their own life for their cause but no one wants to get their family enslaved, tortured or killed. It's not nice but to me it seems like the most efficient way to keep people from doing Inaproppriate Things (tm) and that's why I believe that this is what the Chinese government uses.
"
And this is really sad to say, but true: sometimes you need someone to be made an example of, because it's the recognition of the injustice towards them that spurs others to really consider the issue critically and do something about it, since the same could happen to them."
That would be correct if they'd only stopped at hurting only the misbehaving citizen. As I said, the thought of dying for The Cause sounds glorious while getting your loved ones killed for is horrific.
what's stopping the Chinese secret service (or whatever) to register with this service as hosts, collect all the information needed to snatch the blogger and make an example out of him and his family?
All those people "robbed of learning" can still download the sources themselves. It's not like it's a choice between shipping each brazilian citizen a CD full of sources and blocking them access to OSS projects' websites.
Slashdot Mirror
Just point him to Why's (Poignant) Guide to Ruby. That shouldn't be too boring. I enjoy reading just for its style, even though I already know Ruby :-)
If you can factor the loop into its own function, you can replace the goto with a return to please the "I read somewhere that gotos must never be used" folks. :-)
;-)
Seriously though, IMHO gotos should be used just like that -- to handle function-local exception conditions. Gotos should be avoided when they make code hard to follow, but why avoid them when they make the code easier to read? On the other hand, "open classes" as Ruby calls them -- *cough*COMEFROM*cough* -- they are pure evil.
Read the rest of the summary:
Take a look at LyX for a completely different take on word processing. I've found its user interface to be very pleasant to work with---all you have to do is write, and everything turns out looking great without you having to give it any thought. It's not compatible with MS Office or OO.o, but it's still great for creating PDFs and printed documents.
What bugs me the most about this article is that the author keeps using the most generic libraries he can find instead of something written for this exact task. He should have used WWW:Mechanize for Perl or mechanize for Python. I'm sure there's something like this for Ruby, too.
There is another way in which software inventions are essentially different from physical inventions. In the physical world having an idea, and specifying it in detail is only the first (and relatively cheap) step. Getting your invention from the drawing board to mass production can end up being a very costly and risky undertaking. Patents are needed to assure the inventor, that after he has spent the needed resources to create a new product, he won't get ripped off by other companies which have waited to see how the R&D project pans out.
The world of software is different. As you summed it up in your last sentence, securing the source code prevents people from ripping the idea off. That's because the source code is the idea, described in ultimate detail, while simultaneously being a product that you can sell. There is no expensive process needed to transofrm the idea into a product, describing it in detail is enough. Because of that, software patents don't encourage anyone to bring new products to the market (thus increasing competition) -- quite on the contrary, patent holders are using them to stifle the competition's attempts at doing that.
This makes regular patents good but software patents purely evil in my book.
Let's see.. the last time was when my ISP was doing some upgrades. Both Windows and I kept working without Google, though.
Oops, that's what you get for posting on slashdot before your first cup of coffee :)
In case someone doesn't know it, the joke is from the latest Penny Arcade comic.
You hit the nail on the head!
The point is not to give free tools to people - it is to educate a small percentage of the 3rd world people to a level of expertise in which they will be able to support the information processing needs of their countries, i.e. create affordable software for which they don't have to send money out of their countries to Apple/Microsoft/etc.
Giving out free Mac OS Xs would just make sure that they will only end up using the computers and not tinkering with them at all. This would create a situation in which the 3rd world people would remain cheap labor for sports shoe manufacturers while the (expensive) IT expertise would remain in today's economic powers.
How can you write any code for an application if you don't know what it's supposed to do? When you have a functional specification, you can write tests that test the specified features. When the spec changes you change the tests accordingly to help you make sure that you don't introduce new bugs when changing your code.
Are you suggesting that having no tests would make that particular application work with real-world data? The point of testing is not to prove the customer that your application is flawless (that's impossible) but to help the programmers catch errors like the one you describe.
When you're writing a test, you are making sure that your application works in one particular case. If you don't know what the possible cases are, not only will that prevent you from writing tests - it will also prevent you from writing working code.
"But you can't test everything!" is a dumb excuse for not testing at all. It's like refusing to wear a bullet proof vest because it's useless if you get shot in the head.
Tada! No page loading on middle click on the page. If you meant something else, check out the other middle* options.
I've replaced my Windows gvim's _vimrc with my hand-written .vimrc that I use everywhere I have a shell account, and I haven't noticed the behaviour you described. I'm quite sure that the default _vimrc sets an option that does that.
Your question was answered by a Finnish study recently (only a Finnish link, sorry). The headline says "Camera control halved the amount of accidents resulting in death".
The article also states that "Camera control does not affect the number of accidents but the accidents are less severe than before. For example, the amount of fatal accidents has been reduced to less than a half."
I'll rather believe an official study than your so very logical proof: My teacher laughed at my question --> cameras do not save any lives. :-P
I find it interesting that every application has to wrestle with these problems time and time again, instead of them being solved by the operating system. The reason for all this trouble is that the Access Control List security model is inherently flawed.
Using ACLs makes us adjust permissions per user basis, while it is not the user who does (good or evil) things with the computer but the processes running on behalf of the user. Thus an application can (be tricked to) do malicious things with the user's full permissions - as if the user himself was actively and knowingly destroying his data, sending it over to an eavesdropper, etc. A correct approach would be to grant permissions to do a certain operation on a certain resource per process basis. This is what the capability based security is all about. (If I am mistaken, I hope someone more enlightened in CAP theory will correct me).
I am amazed that none of the popular operating systems implement capability based security models, since they would eliminate Confused Deputy Problems like this.
Some random links relating to Capability based security:
You forgot that ESR's bazaar stuff is not a satistically proven model. It is just a theory until someone proves it to be correct.
Providing an easier interface (an abstraction layer) over the existing tools does not take anything away from the power users. They can always choose to ignore the interface and use the underpinnings directly. For example, I can drive a car but I have no idea of what's going on under the hood. I still have the need to drive the car and every right to do so. Likewise a car mechanic needs and has every right to use a computer. If a person does not have a degree in computer science, that does not mean that he is dumb.
Higher levels of abstraction don't mean decreased efficiency. If they would, we'd still be writing all the software in assembly.
It's seldom commented because there is no such thing. The interoperability features that KDE provides are way more advanced than UNIX pipes.
Case in point: DCOP. Using the console DCOP client, or the DCOP APIs you can control almost every KDE program from your scripts. For example, if you want to pop up the K menu at the mouse cursor, just call `dcop kicker kicker popupKMenu 0`. Want to switch to the next virtual desktop using your script? No problem: `dcop kwin KWinInterface nextDesktop`.
I don't really understand what your point is. AFAIK (correct me if I'm wrong) there is nothing stopping you from using DCOP calls from a GNOME or XFCE application. If you are interacting with application X from your script, your script naturally depends on X. It doesn't matter if you use DCOP, D-BUS or pipes to do that.
The servers are in free countries. The bloggers are Chinese people in china.
Goohoo? You probably meant Yagoohoogle.
And the most effective way to do that is to make an example of those pioneering this new way of free speech and their loved ones - there are many people who are willing to give their own life for their cause but no one wants to get their family enslaved, tortured or killed. It's not nice but to me it seems like the most efficient way to keep people from doing Inaproppriate Things (tm) and that's why I believe that this is what the Chinese government uses.
That would be correct if they'd only stopped at hurting only the misbehaving citizen. As I said, the thought of dying for The Cause sounds glorious while getting your loved ones killed for is horrific.
what's stopping the Chinese secret service (or whatever) to register with this service as hosts, collect all the information needed to snatch the blogger and make an example out of him and his family?
You mean something like Klik?
All those people "robbed of learning" can still download the sources themselves. It's not like it's a choice between shipping each brazilian citizen a CD full of sources and blocking them access to OSS projects' websites.