Yes, actually, I do. There's a reason why we rule the desktop marketplace, you know, and it's not FUD. It's the overall quality and ease of use of our products.
The world needs one full-assed solution, not 400 half-assed solutions. That's the eternal problem with free software / open source development. Quit bickering about which one is better and which one to use; pick one, stick with it, and get it done. Christ.
Several simple but effective changes
on
Fair IP Laws?
·
· Score: 1
The patent service should not be a central government-controlled monopoly. Instead, independent patent registration services should flourish competitively, with conflicting registrations at different services being resolved simply by which registration was acquired earliest. And in a competitive system, registrars that do a better job of investigating prior art will earn a more respected reputation for the legitimacy of their patents in the courts and in the marketplace.
A patent should only last for 5 years, period.
In any patent dispute case in court, the loser should have to pay entirely for the defense costs of the winner, in addition to any damages owed.
In any patent dispute case in court, the general public should be able to provide prior art evidence to the court during an open discussion period, and if the judge ignores prior art in his/her decision that should be automatic grounds for appeal.
The primary goal of commenting is to save time by making it easier for a literate programmer to jump into your code and understand how it works.
A literate programmer doesn't need you to comment tricky-looking lines of code or to ensure every looper value is "iSomethingDescriptive" instead of "i". What a literate programmer needs is *context*--they need to understand the overall architecture of your code, how the small piece they are looking at fits into the architecture. This means you need to comment the goals of each method or function, the structure of each class/object/interface, by specying *why* you've broken things down or structured things in such a way or *why* a function or method is trying to do some particular obscure magic. This way you don't have people walking into your code, picking up a piece of it, and having absolutely no clue what it is trying to accomplish, why it's trying to accomplish that, or when it gets invoked.
This is why "write the comments first as pseudo-code, then fill in the actual code beneath the comments" approaches are generally successful--because they in effect guarantee that you've thoroughly outlined the architecture of your code in the comments.
Slashdot Mirror
Where is the "does not crash mysteriously" feature?
How about the "is actually complete, not a BETA" feature?
Perhaps a "renders popular pages properly" feature would be good as well.
And people actually wonder why IE has overtaken the marketplace... ?!?
Yes, actually, I do. There's a reason why we rule the desktop marketplace, you know, and it's not FUD. It's the overall quality and ease of use of our products.
The world needs one full-assed solution, not 400 half-assed solutions. That's the eternal problem with free software / open source development. Quit bickering about which one is better and which one to use; pick one, stick with it, and get it done. Christ.
The primary goal of commenting is to save time by making it easier for a literate programmer to jump into your code and understand how it works.
A literate programmer doesn't need you to comment tricky-looking lines of code or to ensure every looper value is "iSomethingDescriptive" instead of "i". What a literate programmer needs is *context*--they need to understand the overall architecture of your code, how the small piece they are looking at fits into the architecture. This means you need to comment the goals of each method or function, the structure of each class/object/interface, by specying *why* you've broken things down or structured things in such a way or *why* a function or method is trying to do some particular obscure magic. This way you don't have people walking into your code, picking up a piece of it, and having absolutely no clue what it is trying to accomplish, why it's trying to accomplish that, or when it gets invoked.
This is why "write the comments first as pseudo-code, then fill in the actual code beneath the comments" approaches are generally successful--because they in effect guarantee that you've thoroughly outlined the architecture of your code in the comments.
The new features include cookie management and plug-in support.
What a waste of effort. When is going to finally have the "doesn't crash mysteriously" and "renders popular pages properly" features?