At the time there were few tools that would indicate how/where parenthesis balanced (and no integrated IDEs)
I suspect that someone was pulling the wool over your eyes. Lisp has had fully featured IDE's almost since it was originally implemented.
A lisp shell environment is a true text-based IDE, with features that "modern" IDE's are still trying to catch up to. The editor, compiler, and debugger are all available exactly how and when you want them to be. As for the parens, I don't know how long emacs has done parenthesis matching and lisp autoformatting. Those features were there when I wrote my first lisp program in 1989, more than 16 years ago. I'm sure some of the more experienced lispers could give an authoritative answer as to when this happened (though I suspect that emacs has had these features since shortly after the appearance of elisp).
Now if you mean by "Integrated IDE", something that looks like eclipse or MS Dev Studio, well, yeah. Except for the UI builder, the complexity of those tools is there to help you deal with the fact that the language isn't helping you very much.
IMHO, the one thing that lisp really lacks and Java really has is effective packaging of deliverables. The combined ClassLoader concept and the.jar file are actual genius. I'm still waiting for someone to find a way to deliver lisp-based capabilities so cleanly.
Well, I'm all for that. Explaining what conditions the test is exercising is pretty darned important to having a sane test.
The first error is assuming that tests document the code. They do not, they only test the code.
Agreed. Though well-written tests can provide information about the intent of module usage (since they're an example of using the module being tested), they are not true documentation.
Your second error is assuming that tests prevent bugs.
I don't make that assumption at all. I know for a fact that tests capture a large fraction of coding errors early in the process. This doesn't mean that unit tests can catch all coding errors, nor does it mean that they can prevent future bugs.
What you can say is, "What has been tested is known to work correctly." Everything else in the system is still a risk and if the tests don't reflect actual usage of the module being tested, they're pretty much worthless.
I really don't understand why you don't want people to comment. It isn't an either-or proposition. Comment AND test.
Sounds fine to me. My typical plan for comments is to add them to methods where there are more than three steps or where the names of variables and methods in a block of code are not adequately self-documenting (usually when calling out to third party libraries).
My posting was an objection to the apparent assertion that unit tests are worthless because they don't help find the bug. The statement is wrong because even a poorly documented test narrows down where the problem lies and the automated test tells you there is a problem early in your development process.
Until you end up trying to fix a bug five or ten years down the line.
Uhhh, no. That's when the massive body of unit tests saves your bacon. You had to make a change that caused the tests to start failing. Once the tests are all running again, your system has at least the level of quality it had before you made your changes.
You and your team do have to follow a rule of not deleting possibly relevant tests. Ever.
Those tests don't do you jack if all they do is tell you there's a bug.
Sounds like you haven't written many unit/functional tests. The way it works is: you write tests for small pieces (A, B, and C) and then you write the tests for the part of the system that uses those small pieces (ABC).
If the test for B and the test for ABC are failing, pray tell... where's the problem?
What's worse than commented code without tests? Gaggles of tests and not a comment in sight!
Black, ugly, heavy, and still using that nipple joystick in the middle of the keyboard.
Black? The black color will be attractive to some, unappealing to others. I like the way they look, but I'm not all that picky on color.
Ugly? Again, that's a matter of opinion and I happen to like the way they look. No swoopy plastic, just well-engineered function. The keyboard is especially functional and well-constructed.
Heavy? Not sure what scale you're using, but you should get it checked. The Thinkpad line ranges in weight from 7lbs (including power brick) to 3.5lbs (including power brick). Only a few of the Sony laptops (and all ultraportables) are lighter and only if you leave the DVD drive at home. When comparing apple-to-apple functionally, the IBM has always come out lighter. It's one of the reasons I'm willing to pay more for them.
"nipple joystick"? All but the lightest of the Thinkpads have both trackpoint and touchpad controllers. Personally, I love the trackpoint and I have never managed to get the hang of a touchpad. The ability to leave my fingers near the home keys while moving the cursor is wonderful. I won't buy a laptop that doesn't have a trackpoint controller.
The screen looks underwhelming as well.
You should look at a Thinkpad screen in person. They tend to be the brightest and clearest displays I've ever seen. Few/no dead/hot pixels either. The resolution of this particular tablet is underwhelming, but I have two Thinkpads with 1600x1200 displays (a21p r50p) and I've never had a more comfortable display than those laptop displays. With subpixel antialiasing turned on, I've noted that I don't mind reading documents in electronic form. Normally, I find reading documents on a computer screen annoying and I print stuff pretty quickly to avoid it. Not if I'm at home using either of our Thinkpads.
I'm not sure what the attraction is to these Thinkpads.
IBM made the best designed and built laptop on the market, bar none. Like many others, I'm very interested to see whether Lenovo continues the trend or whether they drop the ball and drop the design standard down to the quality of the Dells, Toshibas and Gateways...
Similar problems arise in any strict rule-based moral system (deontological ethics). By ignoring the circumstances of the specific in favor of the rule that covers the general, tragedy is inevitably allowed in.
Strict moral rules are entirely appropriate for children, who are often protected from the subtlety of circumstance (discretion is so important in ethical decision making). But once a certain sophistication of cognitive development is reached, simple rules no longer cut it. The exceptions become too numerous and too compelling, the consequences of mistakes too severe.
This is one of the reasons why religious morals are historically so destructive: the attempt to treat adults like children, with tragic consequence. But then I'm hijacking your remark to make my point. Sorry about that;-)
What? The robots attacked and try to kill him! How on earth is that in line with Asimov's theme?
The 0th Law is an extrapolation from the 1st Law which states that, "A robot may not harm humanity or through inaction, allow humanity to come to harm."
Once a robot reaches this conclusion, the safety of humanity (0th Law) can be surmised to override the safety, happiness, or continued existence of the individual (1st Law).
This is well within Asimov's thinking on the three laws. As the grandparent hinted at, R. Danieel Olivaw figured out the 0th Law in "Robots and Earth" and was able to harm large numbers of individuals to fulfill it
SPOILERS: Danieel started a process that accelerated the decay rate of fissionables in the earth's crust, driving humanity off the Earth and into eventually forming the galactic empire of the Foundation novels. He did this knowing that the increased radiation levels would sicken and kill many people before the full population would decide to leave and then actually get everyone off the planet.
Viki's implication was a little more brutal, similar to another story, whose title I can't remember (but very much want to). The premise is that humans and robots have been working together just fine until one guy invents the "perfect" robot, able to build more of itself, caring completely about the safety of their human charges. The problem is that the concern over safety causes the robots to protect people from any kind of risk, including disappointment, anger, frustration, etc. Planets where these robots have appeared stop communicating with the rest of humanity and smart leaders try to quarantine their communities to prevent the same thing from happening to them. But the robots find ways through the quarantines, and their helpfulness makes them so tempting to people who first welcome them and only sometimes realize the depth of the contract that the robots have promised to fulfill?
Actually, it isn't an autogyro, it's a coaxial helicopter.
An autogyro is identifiable by the horizontally mounted, small (typically) pusher propellor that is powered, and the overhead rotor which is unpowered.
This device has two overhead rotors and no horizontally mounted propellor at all.
As for whether or not the design allows for autorotation, that's unclear. They seem to be making a rather big deal about the lack of complex rotating parts, which does seem to preclude a swashplate, mixing arms, and separately hinged rotors that are all necessary to have collective control...
Regards,
Ross
Except that very few of those projects are entirely based on reverse engineering.
Do they have to be based entirely on reverse-engineering to qualify as being reverse-engineered? How about if they qualify as benefitting from reverse engineering? I don't differentiate between those two levels of reverse engineering. I also think that reverse engineering is good for competition and the markets in which you and I make economic decisions.
Tridgell reverse engineered something that already had a capable and popular client on Linux,
You and Linus appear to have a problem with that, but for the life of me, I can't see what it might be. Reverse engineering a duplicate of a working existing product is legal, ethical, and highly beneficial to free markets (whether open or closed source).
as someone said in the last story, Tridgells main reason was to circumvent the license for Bitkeeper.
I don't mean to sound condescending, but why else would he put the time and effort into such a project? He wanted an open-source alternative to a closed-source tool that he didn't want to have to use. So he reverse-engineered an implementation of the client to achieve that goal.
Seems pretty straightforward to me. Also seems pretty ethical and completely legal.
[1] Throw bits at a server and see what you get back: good. [2] Save known data to a proprietary format and see what you get: good. [3] Emulate programs by writing code to get the same result: good.
This is reverse engineering. When you divide up the responsibilities so that Group A does [1] and [2] and Group B does [3], that is called "clean room reverse engineering" as the new development is not tainted by exposure to the original work.
Taking somebody else's binary and figuring out the code from that: bad.
By itself, this is not reverse engineering, but it may be equivalent to [1] and [2] (but not [3]) in the earlier process. The most common way in which this happens, reverse-compiling, is also very commonly prohibited by licensing agreements, including EULA's. I don't know if this prohibition has ever been tested in court and if not, that it would be upheld.
If you really want this question answered, I suspect that a test case would have to be filed and carried through to conclusion. Unless a lawyer already knows.
This has nothing to do with what Open Source is all about.
Correct, but there are many open source projects that rely on reverse-engineering to duplicate the features of another system, which is why I said, "...a bunch of other open source projects..." and didn't claim the value for open source as a whole.
GCC wasn't created by examining the bytecode output of an Intel compiler.
True, but several of the optimizations that used to be found only in commercial compilers were figured out through a reverse-engineering process.
[Linus] is not in favor of reverse-engineering someone elses implementation against their wishes.
1) When would anyone ever be in favor of someone else reverse-engineering their work? 2) Linus is inconsistent with his principles. 3) Linus is inconsistent with current law and the current ethics surrounding reverse engineering.
4) Linus is going after the wrong guy. He should be acknowledging that his decision to go with BitKeeper was always at odds with much of the Linux development community and was bound to eventually blow up in his face. Which it has.
As it turns out, all of these things are okay. Linus seems to have some very good skills that, along with the work of other kernel developers, benefit millions of people every day. This doesn't mean that he should be infallible or that anyone should take his advice when he speaks outside his area of expertise. As for the ill-fated decision to go with BitKeeper, there was value, but there is now cost.
The slashdot summary is definitely incomplete, and represents a falsehood by omission. On the naming of this article as a dup, I think this is a worthwhile followup because TFA effectively reframes the issue, and clarifies the clean-room aspects of Tridge's implementation.
In this reframing: Linus has clearly come down against reverse-engineering. TFA is further correct in pointing out that this is inconsistent with what Linux, OpenOffice, gcc, and a bunch of other open source projects are all about.
So, Linus is inconsistent and chose to side with his friend over his principles in this case. I can understand that even if I don't agree with it. Even Linus is entitled to make mistakes now and then:)
India has serious systemic problems in government and culture that they will need to overcome before they can be effective solving new problems.
In government, there is corruption and graft, the likes of which would take any American's breath away. This is accepted as "business as usual" by the Indian populace, who see few alternatives. The average Indian citizen has nothing to gain and a lot to lose if they are the "squeaky wheel", so everyone pretty much sits quietly and takes their share of the graft. Because of this situation, Indian infrastructure (roads, wiring, communications) is in a perpetual state of near failure. The areas where this is not the case are private networks where western companies are currently pumping money in and demand a high quality of service for their money. As soon as those funds disappear, the repairs on the redundant power generators, the satellite uplinks (made by western companies) the telecom equipment and redundant trunks (made by western companies) will all fall apart.
Based on my observations, the cultural problems relevant to tech workers revolve around attitudes towards authority and strategies of pedagogy and learning. Further, the two problems are tightly coupled and coupled with the enormous power disparities between cultural groups, which makes the problems even less tractable.
The education problem can be framed as one in which the teachers pour the knowledge that the students need into the student's heads and that's what they get. This "banking" method of teaching has been long discredited for developing creative thinkers (something that American and European educational systems can list among their strengths). If you go into a bookstore in Bangalore, most of what you will find are certification training books. When you talk to outsourcing companies about the team you might be hiring, they list certifications at you and will almost refust to discuss experience.
When you go to India to work with your team, you find that unless you can frame your problem and development approach as a series of strict single-option rules, your rules will not be followed. Rules of the form, "Either (1) or (2), whichever is more readable." will result at best in 100% (1) or 100% (2) and usually neither. When you ask about a shortcoming that you've found in a review or testing, they will ask where the problems are, then wait until you tell them exactly how to fix those problems before making changes. If the problems that you have mentioned are a part of a pattern and you point out other cases of the problem, you will find that only those instances that you specifically pointed out have been changed.
In short, until Indian technology workers start treating software development as a craft, they will only be the equivalent of the "web developer" here in the US. Until the Indian educational system teaches a craft approach to problem solving, Indian software workers are unlikely to have any success at anything other than the simplest and most motonous projects. Until the culture supports asking challenging questions to teachers and team leaders, the educational system and the products of that educational system are unlikely to change in any significant way.
I liked India. I liked most of the Indians I met (the souvenier sellers were not very likeable, except for 10-year old Madhu up there on Chumundi hill in Mysore). But aside from their personal appeal, I needed to build up an honest evaluation of their suitability for use by my employer.
My conclusion after working with them for a year and being overseas for a month of that: If it's trivial detail work that doesn't require any creativity or insight into the underlying design. If the task can be specified up front and is entirely based on widespread standards, the Indian team is perfect and will do a good job.
If, on the other hand, the module is core to the system, if the module requires careful design, if the requirements are poorly understood, if we need to have a lot
The DAOs are all in one package, and use hibernate as a backend. The package acts like a limiting wrapper around hibernate. It keeps objects from accessing actions that they don't need. Due to hibernate, more than half the methods are like 1-2 liners.
So, the layer is simple, small, easy to maintain, replacable, and independent enough from the other layers that I don't need to go line hunting when I change a DAO.
Well, in this case, it sounds like your domain layer is simple enough that the trade-offs between the various persistence patterns lose a lot of significance. I don't mean to belittle your project, here. In my experience, different things are significant for a 20 class domain layer than for a 200 class domain layer and that shouldn't suprise anyone.
In the application I'm currently working on, there are already 240 distinct persisted types in the system, (role-based access control, personal information, financial information, admin logic, document management interface, core application, extension #1, extension #2, etc.). An approach to business rule management that makes it easier to maintain highly disparate business rules across 15-20 packages becomes critical. When the domain objects (what Hibernate manages) are "safe", as in, they don't allow illegal states to appear, the rest of the app can do a whole lot of relaxing and focus on making the system look good.
dividing the responsibility of an object is fundamental to OO programming.
Exactly. Let Hibernate build the DAO's for you behind the scenes. Those will manage the data in and out of your domain objects (that can then focus on enforcing all of the business rules) and all you have to do is maintain an.xml file (if that).
Don't build yet another DAO layer for Hibernate to manage with Hibernate's automatically generated DAO classes. The DAO pattern doesn't let you use encapsulation, effective inheritance, or a host of other central design tenets of object-oriented programming. Your domain objects should have the benefit of object-oriented design and you shouldn't trade that off because someone told you the DAO pattern was still relevant.
Hibernate does what the DAO pattern claims to do and does it better. Having Hibernate manage your own DAO types is adding layers for the sake of adding layers.
Business rules in the UI layer? WHAT? That's a recipe for disaster.
Exactly.
Domain objects with business rules, Hibernate builds the DAO's behind the scenes, UI presents the data from the domain objects to the world.
I'm objecting to going through the effort of describing DAO's for Hibernate to synchronize with the db and then having another place for your business rules. Hibernate takes care of the same problem that DAO's purport to solve and does without me needing to do anything other than maintain an xml file.
Spring controllers and Struts actions should *NOT* contain business logic, but call objects that do. They in turn can talk to the db.
From memory, and from the link you posted, the DAO pattern is a way around the limitations of JDBC by placing the work of keeping the objects and database synchronized. Which is what Hibernate does. Once you have Hibernate doing the heavy lifting of getting the data in and out of your business objects, why in the world would you want to deal with the forced compromises of the DAO pattern any more?
DAO's aren't objects, or are at best, badly designed objects. You can't use encapsulation with them, the utility of inheritance (polymorphism) is either lost or becomes very difficult (since your business methods are elsewhere), et-cetera.
Rather than have DAO's and a separate business rule layer, just design good domain objects and forget all about DAO's. Polymorphic behavior returns! Encapsulation of data! The option to separate your interface from your implementation!
DAO is one pattern whose time has come and gone.
DAO does have one advantage. And for some teams, it appears to be critical: the "non-OO" approach to class design means that mediocre/poor programmers don't need mentoring to assist with the development and to keep maintaining the system.
One of my clients insisted that they had to be able to hire an army of VB-coders to extend their application. I tried to talk them into a smaller team of skilled developers but they were adamant with their desires. So we found a Perl codegen system, whipped up a framework with some C# DAO's for them and off they went. It was one of the most lavishly expensive processes I have ever been witness to.
Their competitor with five A-players on the team absolutely trounced their product in the market. Though it's hard to entirely fault the "hire an army" mentality for their failure, I can't see that their goal of making it easy for crappy developers to add code helped them at all.
What I didn't like is the assumption that generating business objects from your mappings works well (or at all, in larger systems). I understand the argument for putting the business rules in the UI layer (Spring's controller objects, Struts actions) and letting the domain objects be simple DAO's, and I don't buy it for anything more complex than PetShop applications.
If you're writing a toy application or a simple database report generator, sure. You don't need complex business rules and it's probably easier to let someone generate DAO's and push what limited business rules there are into the UI layer.
If, however, you're writing a substantial business application, you've got four or five interfaces per deployment (UI, scheduler, import data API, erp interface, etc.). If all of those interfaces don't act against the same business rules enforced upon them, your customer's data is hosed and quickly. Anecdotally, all but one of the "data corruption" bugs in my last big project were from business rules that someone thought should go into the UI layer, and didn't get enforced for other interfaces, allowing usage of those interfaces to wreak havoc.
The other approach I've seen for generated DAO's is to hang business rule implementations off of the DAO's via inheritance. Not only is this approach contrary to the goal of inheritance, it prevents you from actually having object oriented classes. You'd better not try to have polymorphic behavior in those classes. The kicker with this approach is that your business rule classes are just as complex as if you'd simply written good domain objects in the first place, meaning that the generation has bought you no reduction of effort.
"The overhead of maintaining separate artifacts." is wildly inflated. The system details are there, whether conflated into the same files or separated into different files. You also have fewer artifacts if you don't separate interface from implementation. You also have fewer artifacts if you combine several classes into the same.java file. Fewer artifacts != lower cost of development/maintenance.
isn't plugging it in and then looking at MPG very decieving?
Exactly. They're taking advantage of a second energy supply and only claiming the cost of the first.
In order to normalize the figures, you need a common divisor. As you suggested, money sounds like a good idea to me. I use 91 octane from the station around the corner in my Honda Nighthawk motorcycle. I get about 45mpg. The price I pay is $2.61/gal (California!), which comes to about 6 cents spent on fuel per mile travelled. If you're getting 60mpg, you're at about 4.5 cents per mile.
We need one other number to compare these modified Prius's: the change in size of the energy bill. We could get by with off-peak rates from the CPUC and a miles/kWh figure for the Prius when only using battery power.
Which is really a long excuse for failing to go through the design stage where you work with the end users to develop a formal requirements specification.
Then you didn't read what I wrote. If you actually go through that exercise and implement the system that was designed in the formal exercise, 90%+ of the time, what you build will not be what the end users need.
And that is a risk just as substantial as the other real risks you've mentioned. If the system corrupts customer data, it's worthless (or worse). If the system allows unauthorized people to see confidential data, it's worthless (or worse). If the users can't get done what they need to get done (no matter what they think that might be at the start of the project), it's worthless (or worse).
I'm interested, do all you developers do nothing but write software where the costs of failure, data corruption, data loss, or security breaches are negligible?
This is a strawman. Just because I stated that formal methods rarely if ever result in successful projects outside of NASA doesn't mean that I don't think quality is important. Implemented quality needs to be balanced against quality requirements.
Of course the system should't corrupt it's data. But a formal spec doesn't actually deliver that benefit. Smart implementation and time to do effective qa from the beginning (yes, including the design step) deliver that benefit.
your design should isolate that so that it can't cause any data corruption or loss at the backend which is formally specified, and guaranteed not screw up.
You just have no idea of the cost of an absolute guarantee that it doesn't screw up. It doesn't cost 20% more or even 100% more, an "absolute guarantee" (formal methods) costs 10x to 20x more than "99.9% certain". Our employers almost never feel that the additional cost is worth the reduction in risk from 0.1% to 0% unless lives are on the line, and even then, they'll do just about anything to avoid the real costs.
For some reason we accept that software should be just thrown together rather than properly designed and proved.
I'll sum up some of the sibling's answers by saying: the reason formal methods aren't used more often is that we (developers) don't trust the original spec.
Bridge builders have the luxury of stable requirements. X number of lanes, here's the local geology, here's where we want the bridge. With software, at best you have a clear concept of the problem the system should solve (in many cases, you only have a vague idea of what the real problem is). If you come up with a detailed design, formally specifying everything, and then the design happens solve the problem poorly, you've wasted an enormous amount of time.
If, instead, you develop a prototype, get it in front of users, see how they use it, see what problems they have, and iteratively learn what the design is as you write the solution for it, you're much more likely to solve the real problem quickly. Like all things, however, this involves a trade-off: this approach trades correctness and usability of solution for a deterministic schedule.
In all design projects, there are four primary variables: cost, time, features, and quality. You are usually constrained by one of those and you get to optimize for one other. The two remaining variables are not controllable. Your proposed approach (like most formal approaches) optimizes for quality and assumes that features are fixed. Beware of time and cost, because you cannot control them. In this case, time and cost will bite you in the form of costly and time-consuming rewrites to all of that formal documentation when the first version doesn't really do what the users need. NASA writes software like that, but they are aware of the time and cost variables and budget for them. And they do pay.
He's actually a really pleasant guy to meet and seems to have a real passion and aptitude for teaching.
I bumped into he and his girlfriend walking her dog in Santa Monica (where we both live) and mentioned what I knew about the sundials on the mars rovers as a conversation starter. We instantly got into a discussion about diffusion and color and he started teaching my fiance about sundial structure and started demonstrating some of the logic behind the rover cameras using his hand and a newspaper.
We still talk about "meeting Bill Nye" every once in a while.
Kind of. Actualy my point is to look beyond what you understand and consider that those charged with your protection might be actualy working in your best interest.
There are ways for them to do that that are within the rules under which our government is expected to operate. Within the powers granted to them by the constitution.
This massive hidden detention and torture operation at Guantanamo bay is another WWII internment camp, another Indian war, another red scare, another part of American history that your children will look back on with shame. I wonder if they'll blame you personally?
I know it is a hard concept to fathom. But it may just be happening. Rocking the boat sometime swamps it and causes it to sink. Worse yet, it just gets the passengers wet and destroy thier belongings and might make them sick.
What a disgusting way to think. It amazes me that you and I are grouped in the same political category by the mass media (conservative), yet I'm willing to think for myself, and you just accept what you're told.
You must be one of those "neoconservatives" I've been hearing so much about. Going to revitalize the party by bending over the saddle before you're even told, eh? Well, you have fun.
Why does asserting that all people deserve due process imply that I think they are naturally good? I bet that most of the people in that camp are pretty nasty individuals who wouldn't think twice about killing me. That doesn't mean they aren't entitled to constitutional rights designated for people (instead of those rights set aside for citizens).
If anyone is throwing around unsupported assertions between us, it isn't me.
We have rights because we assert that human beings have rights. As soon as you say that "those people don't have that right", you've given away the right. I don't like the prisoners we're holding at Guantanamo bay, but they deserve their rights because we deserve to have the same rights and I do like myself, my family, my neighbors, etc.
go talk to the families of the people killed on that morning in 2001
Have you actually convinced yourself that I'm happy the 9/11 attack happened? Do you honestly believe that I want 3000+ people to be dead just because I want the US to pay attention to our constitution all the time? What are these families going to tell me? That they're upset and angry? Of course they're upset and angry. So are the family members of any murder victim.
But that doesn't mean that you take every person who looks similar to the murderer and lock them up for years without a trial.
Think for yourself. Just once. That's all I ask. If that sounds holier than thou, try to come up with a good reason why a conservative, intelligent person might think the way I do on this issue. Because I understand why you think the way you do: you've bought into the "You need to be afraid, but we'll protect you" line that the Bush government is selling. Why don't I think the same way? Because I don't buy into either proposition.
There's no need to be afraid. And the government isn't going to protect me from harm.
Security has been a myth all along. We weren't "safe" before 9/11, and the changes to airlines and government powers since then don't make us the slightest bit safer now. You still aren't "safe" sitting at home, taking a bath, or driving down the street, but that shouldn't prevent you from going out and living your life. Just take responsibility for yourself and do your best to take care of what's important to you.
Regards, Ross
Possibly pertinent information: I voted for Reagan twice, Bush Sr. once, Dole once, and the libertarian candidate since then. I consider myself pretty darned conservative and I've never been able to actually vote for any of the Democratic candidates. But I'll be damned if I'll let Bush Jr's scare-mongering actually make me feel afraid about a religion or a people.
Perversely, it's not a very good idea to actually do a patent search before lunging into your neat new idea. Should you actually find evidence that your invention was close to patented technology and that fact comes out in court, you will be accused of violating the patent deliberately.
If you never looked, on the other hand, you just didn't know about it and may have violated someone's patent as a result.
Further, you'll only be subject to serious trouble on the patent front if you're wildly successful (i.e. harming the patent holder's market share). In that case, there ought to be enough interested parties with money to actually handle the challenge.
I am not a lawyer, but I've talked to a few on this exact subject with the exact same question.
Slashdot Mirror
At the time there were few tools that would indicate how/where parenthesis balanced (and no integrated IDEs)
.jar file are actual genius. I'm still waiting for someone to find a way to deliver lisp-based capabilities so cleanly.
I suspect that someone was pulling the wool over your eyes. Lisp has had fully featured IDE's almost since it was originally implemented.
A lisp shell environment is a true text-based IDE, with features that "modern" IDE's are still trying to catch up to. The editor, compiler, and debugger are all available exactly how and when you want them to be. As for the parens, I don't know how long emacs has done parenthesis matching and lisp autoformatting. Those features were there when I wrote my first lisp program in 1989, more than 16 years ago. I'm sure some of the more experienced lispers could give an authoritative answer as to when this happened (though I suspect that emacs has had these features since shortly after the appearance of elisp).
Now if you mean by "Integrated IDE", something that looks like eclipse or MS Dev Studio, well, yeah. Except for the UI builder, the complexity of those tools is there to help you deal with the fact that the language isn't helping you very much.
IMHO, the one thing that lisp really lacks and Java really has is effective packaging of deliverables. The combined ClassLoader concept and the
Regards,
Ross
I COMMENT the tests I write!
Well, I'm all for that. Explaining what conditions the test is exercising is pretty darned important to having a sane test.
The first error is assuming that tests document the code. They do not, they only test the code.
Agreed. Though well-written tests can provide information about the intent of module usage (since they're an example of using the module being tested), they are not true documentation.
Your second error is assuming that tests prevent bugs.
I don't make that assumption at all. I know for a fact that tests capture a large fraction of coding errors early in the process. This doesn't mean that unit tests can catch all coding errors, nor does it mean that they can prevent future bugs.
What you can say is, "What has been tested is known to work correctly." Everything else in the system is still a risk and if the tests don't reflect actual usage of the module being tested, they're pretty much worthless.
I really don't understand why you don't want people to comment. It isn't an either-or proposition. Comment AND test.
Sounds fine to me. My typical plan for comments is to add them to methods where there are more than three steps or where the names of variables and methods in a block of code are not adequately self-documenting (usually when calling out to third party libraries).
My posting was an objection to the apparent assertion that unit tests are worthless because they don't help find the bug. The statement is wrong because even a poorly documented test narrows down where the problem lies and the automated test tells you there is a problem early in your development process.
Regards,
Ross
Until you end up trying to fix a bug five or ten years down the line.
Uhhh, no. That's when the massive body of unit tests saves your bacon. You had to make a change that caused the tests to start failing. Once the tests are all running again, your system has at least the level of quality it had before you made your changes.
You and your team do have to follow a rule of not deleting possibly relevant tests. Ever.
Those tests don't do you jack if all they do is tell you there's a bug.
Sounds like you haven't written many unit/functional tests. The way it works is: you write tests for small pieces (A, B, and C) and then you write the tests for the part of the system that uses those small pieces (ABC).
If the test for B and the test for ABC are failing, pray tell... where's the problem?
What's worse than commented code without tests? Gaggles of tests and not a comment in sight!
This is just trolling.
Regards,
Ross
Black, ugly, heavy, and still using that nipple joystick in the middle of the keyboard.
Black? The black color will be attractive to some, unappealing to others. I like the way they look, but I'm not all that picky on color.
Ugly? Again, that's a matter of opinion and I happen to like the way they look. No swoopy plastic, just well-engineered function. The keyboard is especially functional and well-constructed.
Heavy? Not sure what scale you're using, but you should get it checked. The Thinkpad line ranges in weight from 7lbs (including power brick) to 3.5lbs (including power brick). Only a few of the Sony laptops (and all ultraportables) are lighter and only if you leave the DVD drive at home. When comparing apple-to-apple functionally, the IBM has always come out lighter. It's one of the reasons I'm willing to pay more for them.
"nipple joystick"? All but the lightest of the Thinkpads have both trackpoint and touchpad controllers. Personally, I love the trackpoint and I have never managed to get the hang of a touchpad. The ability to leave my fingers near the home keys while moving the cursor is wonderful. I won't buy a laptop that doesn't have a trackpoint controller.
The screen looks underwhelming as well.
You should look at a Thinkpad screen in person. They tend to be the brightest and clearest displays I've ever seen. Few/no dead/hot pixels either. The resolution of this particular tablet is underwhelming, but I have two Thinkpads with 1600x1200 displays (a21p r50p) and I've never had a more comfortable display than those laptop displays. With subpixel antialiasing turned on, I've noted that I don't mind reading documents in electronic form. Normally, I find reading documents on a computer screen annoying and I print stuff pretty quickly to avoid it. Not if I'm at home using either of our Thinkpads.
I'm not sure what the attraction is to these Thinkpads.
IBM made the best designed and built laptop on the market, bar none. Like many others, I'm very interested to see whether Lenovo continues the trend or whether they drop the ball and drop the design standard down to the quality of the Dells, Toshibas and Gateways...
Regards,
Ross
Similar problems arise in any strict rule-based moral system (deontological ethics). By ignoring the circumstances of the specific in favor of the rule that covers the general, tragedy is inevitably allowed in.
;-)
Strict moral rules are entirely appropriate for children, who are often protected from the subtlety of circumstance (discretion is so important in ethical decision making). But once a certain sophistication of cognitive development is reached, simple rules no longer cut it. The exceptions become too numerous and too compelling, the consequences of mistakes too severe.
This is one of the reasons why religious morals are historically so destructive: the attempt to treat adults like children, with tragic consequence. But then I'm hijacking your remark to make my point. Sorry about that
Regards,
Ross
What? The robots attacked and try to kill him! How on earth is that in line with Asimov's theme?
The 0th Law is an extrapolation from the 1st Law which states that, "A robot may not harm humanity or through inaction, allow humanity to come to harm."
Once a robot reaches this conclusion, the safety of humanity (0th Law) can be surmised to override the safety, happiness, or continued existence of the individual (1st Law).
This is well within Asimov's thinking on the three laws. As the grandparent hinted at, R. Danieel Olivaw figured out the 0th Law in "Robots and Earth" and was able to harm large numbers of individuals to fulfill it
SPOILERS: Danieel started a process that accelerated the decay rate of fissionables in the earth's crust, driving humanity off the Earth and into eventually forming the galactic empire of the Foundation novels. He did this knowing that the increased radiation levels would sicken and kill many people before the full population would decide to leave and then actually get everyone off the planet.
Viki's implication was a little more brutal, similar to another story, whose title I can't remember (but very much want to). The premise is that humans and robots have been working together just fine until one guy invents the "perfect" robot, able to build more of itself, caring completely about the safety of their human charges. The problem is that the concern over safety causes the robots to protect people from any kind of risk, including disappointment, anger, frustration, etc. Planets where these robots have appeared stop communicating with the rest of humanity and smart leaders try to quarantine their communities to prevent the same thing from happening to them. But the robots find ways through the quarantines, and their helpfulness makes them so tempting to people who first welcome them and only sometimes realize the depth of the contract that the robots have promised to fulfill?
Anyone know the series of books I'm referring to?
Regards,
Ross
Actually, it isn't an autogyro, it's a coaxial helicopter. An autogyro is identifiable by the horizontally mounted, small (typically) pusher propellor that is powered, and the overhead rotor which is unpowered. This device has two overhead rotors and no horizontally mounted propellor at all. As for whether or not the design allows for autorotation, that's unclear. They seem to be making a rather big deal about the lack of complex rotating parts, which does seem to preclude a swashplate, mixing arms, and separately hinged rotors that are all necessary to have collective control... Regards, Ross
Except that very few of those projects are entirely based on reverse engineering.
Do they have to be based entirely on reverse-engineering to qualify as being reverse-engineered? How about if they qualify as benefitting from reverse engineering? I don't differentiate between those two levels of reverse engineering. I also think that reverse engineering is good for competition and the markets in which you and I make economic decisions.
Tridgell reverse engineered something that already had a capable and popular client on Linux,
You and Linus appear to have a problem with that, but for the life of me, I can't see what it might be. Reverse engineering a duplicate of a working existing product is legal, ethical, and highly beneficial to free markets (whether open or closed source).
as someone said in the last story, Tridgells main reason was to circumvent the license for Bitkeeper.
I don't mean to sound condescending, but why else would he put the time and effort into such a project? He wanted an open-source alternative to a closed-source tool that he didn't want to have to use. So he reverse-engineered an implementation of the client to achieve that goal.
Seems pretty straightforward to me. Also seems pretty ethical and completely legal.
Regards,
Ross
IANAL
[1] Throw bits at a server and see what you get back: good.
[2] Save known data to a proprietary format and see what you get: good.
[3] Emulate programs by writing code to get the same result: good.
This is reverse engineering. When you divide up the responsibilities so that Group A does [1] and [2] and Group B does [3], that is called "clean room reverse engineering" as the new development is not tainted by exposure to the original work.
Taking somebody else's binary and figuring out the code from that: bad.
By itself, this is not reverse engineering, but it may be equivalent to [1] and [2] (but not [3]) in the earlier process. The most common way in which this happens, reverse-compiling, is also very commonly prohibited by licensing agreements, including EULA's. I don't know if this prohibition has ever been tested in court and if not, that it would be upheld.
If you really want this question answered, I suspect that a test case would have to be filed and carried through to conclusion. Unless a lawyer already knows.
Regards,
Ross
This has nothing to do with what Open Source is all about.
Correct, but there are many open source projects that rely on reverse-engineering to duplicate the features of another system, which is why I said, "...a bunch of other open source projects..." and didn't claim the value for open source as a whole.
GCC wasn't created by examining the bytecode output of an Intel compiler.
True, but several of the optimizations that used to be found only in commercial compilers were figured out through a reverse-engineering process.
[Linus] is not in favor of reverse-engineering someone elses implementation against their wishes.
1) When would anyone ever be in favor of someone else reverse-engineering their work?
2) Linus is inconsistent with his principles.
3) Linus is inconsistent with current law and the current ethics surrounding reverse engineering.
4) Linus is going after the wrong guy. He should be acknowledging that his decision to go with BitKeeper was always at odds with much of the Linux development community and was bound to eventually blow up in his face. Which it has.
As it turns out, all of these things are okay. Linus seems to have some very good skills that, along with the work of other kernel developers, benefit millions of people every day. This doesn't mean that he should be infallible or that anyone should take his advice when he speaks outside his area of expertise. As for the ill-fated decision to go with BitKeeper, there was value, but there is now cost.
Regards,
Ross
The slashdot summary is definitely incomplete, and represents a falsehood by omission. On the naming of this article as a dup, I think this is a worthwhile followup because TFA effectively reframes the issue, and clarifies the clean-room aspects of Tridge's implementation.
:)
In this reframing: Linus has clearly come down against reverse-engineering. TFA is further correct in pointing out that this is inconsistent with what Linux, OpenOffice, gcc, and a bunch of other open source projects are all about.
So, Linus is inconsistent and chose to side with his friend over his principles in this case. I can understand that even if I don't agree with it. Even Linus is entitled to make mistakes now and then
Regards,
Ross
India has serious systemic problems in government and culture that they will need to overcome before they can be effective solving new problems.
In government, there is corruption and graft, the likes of which would take any American's breath away. This is accepted as "business as usual" by the Indian populace, who see few alternatives. The average Indian citizen has nothing to gain and a lot to lose if they are the "squeaky wheel", so everyone pretty much sits quietly and takes their share of the graft. Because of this situation, Indian infrastructure (roads, wiring, communications) is in a perpetual state of near failure. The areas where this is not the case are private networks where western companies are currently pumping money in and demand a high quality of service for their money. As soon as those funds disappear, the repairs on the redundant power generators, the satellite uplinks (made by western companies) the telecom equipment and redundant trunks (made by western companies) will all fall apart.
Based on my observations, the cultural problems relevant to tech workers revolve around attitudes towards authority and strategies of pedagogy and learning. Further, the two problems are tightly coupled and coupled with the enormous power disparities between cultural groups, which makes the problems even less tractable.
The education problem can be framed as one in which the teachers pour the knowledge that the students need into the student's heads and that's what they get. This "banking" method of teaching has been long discredited for developing creative thinkers (something that American and European educational systems can list among their strengths). If you go into a bookstore in Bangalore, most of what you will find are certification training books. When you talk to outsourcing companies about the team you might be hiring, they list certifications at you and will almost refust to discuss experience.
When you go to India to work with your team, you find that unless you can frame your problem and development approach as a series of strict single-option rules, your rules will not be followed. Rules of the form, "Either (1) or (2), whichever is more readable." will result at best in 100% (1) or 100% (2) and usually neither. When you ask about a shortcoming that you've found in a review or testing, they will ask where the problems are, then wait until you tell them exactly how to fix those problems before making changes. If the problems that you have mentioned are a part of a pattern and you point out other cases of the problem, you will find that only those instances that you specifically pointed out have been changed.
In short, until Indian technology workers start treating software development as a craft, they will only be the equivalent of the "web developer" here in the US. Until the Indian educational system teaches a craft approach to problem solving, Indian software workers are unlikely to have any success at anything other than the simplest and most motonous projects. Until the culture supports asking challenging questions to teachers and team leaders, the educational system and the products of that educational system are unlikely to change in any significant way.
I liked India. I liked most of the Indians I met (the souvenier sellers were not very likeable, except for 10-year old Madhu up there on Chumundi hill in Mysore). But aside from their personal appeal, I needed to build up an honest evaluation of their suitability for use by my employer.
My conclusion after working with them for a year and being overseas for a month of that: If it's trivial detail work that doesn't require any creativity or insight into the underlying design. If the task can be specified up front and is entirely based on widespread standards, the Indian team is perfect and will do a good job.
If, on the other hand, the module is core to the system, if the module requires careful design, if the requirements are poorly understood, if we need to have a lot
The DAOs are all in one package, and use hibernate as a backend. The package acts like a limiting wrapper around hibernate. It keeps objects from accessing actions that they don't need. Due to hibernate, more than half the methods are like 1-2 liners.
So, the layer is simple, small, easy to maintain, replacable, and independent enough from the other layers that I don't need to go line hunting when I change a DAO.
Well, in this case, it sounds like your domain layer is simple enough that the trade-offs between the various persistence patterns lose a lot of significance. I don't mean to belittle your project, here. In my experience, different things are significant for a 20 class domain layer than for a 200 class domain layer and that shouldn't suprise anyone.
In the application I'm currently working on, there are already 240 distinct persisted types in the system, (role-based access control, personal information, financial information, admin logic, document management interface, core application, extension #1, extension #2, etc.). An approach to business rule management that makes it easier to maintain highly disparate business rules across 15-20 packages becomes critical. When the domain objects (what Hibernate manages) are "safe", as in, they don't allow illegal states to appear, the rest of the app can do a whole lot of relaxing and focus on making the system look good.
Regards,
Ross
dividing the responsibility of an object is fundamental to OO programming.
.xml file (if that).
Exactly. Let Hibernate build the DAO's for you behind the scenes. Those will manage the data in and out of your domain objects (that can then focus on enforcing all of the business rules) and all you have to do is maintain an
Don't build yet another DAO layer for Hibernate to manage with Hibernate's automatically generated DAO classes. The DAO pattern doesn't let you use encapsulation, effective inheritance, or a host of other central design tenets of object-oriented programming. Your domain objects should have the benefit of object-oriented design and you shouldn't trade that off because someone told you the DAO pattern was still relevant.
Hibernate does what the DAO pattern claims to do and does it better. Having Hibernate manage your own DAO types is adding layers for the sake of adding layers.
Regards,
Ross
Business rules in the UI layer? WHAT? That's a recipe for disaster.
Exactly.
Domain objects with business rules, Hibernate builds the DAO's behind the scenes, UI presents the data from the domain objects to the world.
I'm objecting to going through the effort of describing DAO's for Hibernate to synchronize with the db and then having another place for your business rules. Hibernate takes care of the same problem that DAO's purport to solve and does without me needing to do anything other than maintain an xml file.
Spring controllers and Struts actions should *NOT* contain business logic, but call objects that do. They in turn can talk to the db.
Sounds right to me.
Regards,
Ross
From memory, and from the link you posted, the DAO pattern is a way around the limitations of JDBC by placing the work of keeping the objects and database synchronized. Which is what Hibernate does. Once you have Hibernate doing the heavy lifting of getting the data in and out of your business objects, why in the world would you want to deal with the forced compromises of the DAO pattern any more?
DAO's aren't objects, or are at best, badly designed objects. You can't use encapsulation with them, the utility of inheritance (polymorphism) is either lost or becomes very difficult (since your business methods are elsewhere), et-cetera.
Rather than have DAO's and a separate business rule layer, just design good domain objects and forget all about DAO's. Polymorphic behavior returns! Encapsulation of data! The option to separate your interface from your implementation!
DAO is one pattern whose time has come and gone.
DAO does have one advantage. And for some teams, it appears to be critical: the "non-OO" approach to class design means that mediocre/poor programmers don't need mentoring to assist with the development and to keep maintaining the system.
One of my clients insisted that they had to be able to hire an army of VB-coders to extend their application. I tried to talk them into a smaller team of skilled developers but they were adamant with their desires. So we found a Perl codegen system, whipped up a framework with some C# DAO's for them and off they went. It was one of the most lavishly expensive processes I have ever been witness to.
Their competitor with five A-players on the team absolutely trounced their product in the market. Though it's hard to entirely fault the "hire an army" mentality for their failure, I can't see that their goal of making it easy for crappy developers to add code helped them at all.
Regards,
Ross
What I didn't like is the assumption that generating business objects from your mappings works well (or at all, in larger systems). I understand the argument for putting the business rules in the UI layer (Spring's controller objects, Struts actions) and letting the domain objects be simple DAO's, and I don't buy it for anything more complex than PetShop applications.
.java file. Fewer artifacts != lower cost of development/maintenance.
If you're writing a toy application or a simple database report generator, sure. You don't need complex business rules and it's probably easier to let someone generate DAO's and push what limited business rules there are into the UI layer.
If, however, you're writing a substantial business application, you've got four or five interfaces per deployment (UI, scheduler, import data API, erp interface, etc.). If all of those interfaces don't act against the same business rules enforced upon them, your customer's data is hosed and quickly. Anecdotally, all but one of the "data corruption" bugs in my last big project were from business rules that someone thought should go into the UI layer, and didn't get enforced for other interfaces, allowing usage of those interfaces to wreak havoc.
The other approach I've seen for generated DAO's is to hang business rule implementations off of the DAO's via inheritance. Not only is this approach contrary to the goal of inheritance, it prevents you from actually having object oriented classes. You'd better not try to have polymorphic behavior in those classes. The kicker with this approach is that your business rule classes are just as complex as if you'd simply written good domain objects in the first place, meaning that the generation has bought you no reduction of effort.
"The overhead of maintaining separate artifacts." is wildly inflated. The system details are there, whether conflated into the same files or separated into different files. You also have fewer artifacts if you don't separate interface from implementation. You also have fewer artifacts if you combine several classes into the same
Regards,
Ross
isn't plugging it in and then looking at MPG very decieving?
Exactly. They're taking advantage of a second energy supply and only claiming the cost of the first.
In order to normalize the figures, you need a common divisor. As you suggested, money sounds like a good idea to me. I use 91 octane from the station around the corner in my Honda Nighthawk motorcycle. I get about 45mpg. The price I pay is $2.61/gal (California!), which comes to about 6 cents spent on fuel per mile travelled. If you're getting 60mpg, you're at about 4.5 cents per mile.
We need one other number to compare these modified Prius's: the change in size of the energy bill. We could get by with off-peak rates from the CPUC and a miles/kWh figure for the Prius when only using battery power.
Anyone?
Regards,
Ross
Which is really a long excuse for failing to go through the design stage where you work with the end users to develop a formal requirements specification.
Then you didn't read what I wrote. If you actually go through that exercise and implement the system that was designed in the formal exercise, 90%+ of the time, what you build will not be what the end users need.
And that is a risk just as substantial as the other real risks you've mentioned. If the system corrupts customer data, it's worthless (or worse). If the system allows unauthorized people to see confidential data, it's worthless (or worse). If the users can't get done what they need to get done (no matter what they think that might be at the start of the project), it's worthless (or worse).
I'm interested, do all you developers do nothing but write software where the costs of failure, data corruption, data loss, or security breaches are negligible?
This is a strawman. Just because I stated that formal methods rarely if ever result in successful projects outside of NASA doesn't mean that I don't think quality is important. Implemented quality needs to be balanced against quality requirements.
Of course the system should't corrupt it's data. But a formal spec doesn't actually deliver that benefit. Smart implementation and time to do effective qa from the beginning (yes, including the design step) deliver that benefit.
your design should isolate that so that it can't cause any data corruption or loss at the backend which is formally specified, and guaranteed not screw up.
You just have no idea of the cost of an absolute guarantee that it doesn't screw up. It doesn't cost 20% more or even 100% more, an "absolute guarantee" (formal methods) costs 10x to 20x more than "99.9% certain". Our employers almost never feel that the additional cost is worth the reduction in risk from 0.1% to 0% unless lives are on the line, and even then, they'll do just about anything to avoid the real costs.
Regards,
Ross
For some reason we accept that software should be just thrown together rather than properly designed and proved.
I'll sum up some of the sibling's answers by saying: the reason formal methods aren't used more often is that we (developers) don't trust the original spec.
Bridge builders have the luxury of stable requirements. X number of lanes, here's the local geology, here's where we want the bridge. With software, at best you have a clear concept of the problem the system should solve (in many cases, you only have a vague idea of what the real problem is). If you come up with a detailed design, formally specifying everything, and then the design happens solve the problem poorly, you've wasted an enormous amount of time.
If, instead, you develop a prototype, get it in front of users, see how they use it, see what problems they have, and iteratively learn what the design is as you write the solution for it, you're much more likely to solve the real problem quickly. Like all things, however, this involves a trade-off: this approach trades correctness and usability of solution for a deterministic schedule.
In all design projects, there are four primary variables: cost, time, features, and quality. You are usually constrained by one of those and you get to optimize for one other. The two remaining variables are not controllable. Your proposed approach (like most formal approaches) optimizes for quality and assumes that features are fixed. Beware of time and cost, because you cannot control them. In this case, time and cost will bite you in the form of costly and time-consuming rewrites to all of that formal documentation when the first version doesn't really do what the users need. NASA writes software like that, but they are aware of the time and cost variables and budget for them. And they do pay.
Regards,
Ross
He's actually a really pleasant guy to meet and seems to have a real passion and aptitude for teaching.
I bumped into he and his girlfriend walking her dog in Santa Monica (where we both live) and mentioned what I knew about the sundials on the mars rovers as a conversation starter. We instantly got into a discussion about diffusion and color and he started teaching my fiance about sundial structure and started demonstrating some of the logic behind the rover cameras using his hand and a newspaper.
We still talk about "meeting Bill Nye" every once in a while.
Regards,
Ross
Kind of. Actualy my point is to look beyond what you understand and consider that those charged with your protection might be actualy working in your best interest.
There are ways for them to do that that are within the rules under which our government is expected to operate. Within the powers granted to them by the constitution.
This massive hidden detention and torture operation at Guantanamo bay is another WWII internment camp, another Indian war, another red scare, another part of American history that your children will look back on with shame. I wonder if they'll blame you personally?
I know it is a hard concept to fathom. But it may just be happening. Rocking the boat sometime swamps it and causes it to sink. Worse yet, it just gets the passengers wet and destroy thier belongings and might make them sick.
What a disgusting way to think. It amazes me that you and I are grouped in the same political category by the mass media (conservative), yet I'm willing to think for myself, and you just accept what you're told.
You must be one of those "neoconservatives" I've been hearing so much about. Going to revitalize the party by bending over the saddle before you're even told, eh? Well, you have fun.
Regards,
Ross
Why does asserting that all people deserve due process imply that I think they are naturally good? I bet that most of the people in that camp are pretty nasty individuals who wouldn't think twice about killing me. That doesn't mean they aren't entitled to constitutional rights designated for people (instead of those rights set aside for citizens).
If anyone is throwing around unsupported assertions between us, it isn't me.
We have rights because we assert that human beings have rights. As soon as you say that "those people don't have that right", you've given away the right. I don't like the prisoners we're holding at Guantanamo bay, but they deserve their rights because we deserve to have the same rights and I do like myself, my family, my neighbors, etc.
go talk to the families of the people killed on that morning in 2001
Have you actually convinced yourself that I'm happy the 9/11 attack happened? Do you honestly believe that I want 3000+ people to be dead just because I want the US to pay attention to our constitution all the time? What are these families going to tell me? That they're upset and angry? Of course they're upset and angry. So are the family members of any murder victim.
But that doesn't mean that you take every person who looks similar to the murderer and lock them up for years without a trial.
Think for yourself. Just once. That's all I ask. If that sounds holier than thou, try to come up with a good reason why a conservative, intelligent person might think the way I do on this issue. Because I understand why you think the way you do: you've bought into the "You need to be afraid, but we'll protect you" line that the Bush government is selling. Why don't I think the same way? Because I don't buy into either proposition.
There's no need to be afraid. And the government isn't going to protect me from harm.
Security has been a myth all along. We weren't "safe" before 9/11, and the changes to airlines and government powers since then don't make us the slightest bit safer now. You still aren't "safe" sitting at home, taking a bath, or driving down the street, but that shouldn't prevent you from going out and living your life. Just take responsibility for yourself and do your best to take care of what's important to you.
Regards,
Ross
Possibly pertinent information: I voted for Reagan twice, Bush Sr. once, Dole once, and the libertarian candidate since then. I consider myself pretty darned conservative and I've never been able to actually vote for any of the Democratic candidates. But I'll be damned if I'll let Bush Jr's scare-mongering actually make me feel afraid about a religion or a people.
It's not a defense, it's avoiding the additional penalty. Regards, Ross
Perversely, it's not a very good idea to actually do a patent search before lunging into your neat new idea. Should you actually find evidence that your invention was close to patented technology and that fact comes out in court, you will be accused of violating the patent deliberately.
If you never looked, on the other hand, you just didn't know about it and may have violated someone's patent as a result.
Further, you'll only be subject to serious trouble on the patent front if you're wildly successful (i.e. harming the patent holder's market share). In that case, there ought to be enough interested parties with money to actually handle the challenge.
I am not a lawyer, but I've talked to a few on this exact subject with the exact same question.
Regards,
Ross