Crypto is about more then just hiding stuff from 'The Man', its about keeping things private from all
people.
Right on. Encryption is also a tool that helps prevent your information from being violated. Notice that the availabilty of weapons and training (selfdefence) are proactive. They are things you can do yourself to learn to deal with potentailly unpleasant situations. You have options other than: wait for the cops to get there (though this may still be your safest one). Encryption is a similar tool for the defence of your information... And in this day and age direct information attacks such as true name fraud (basically by collecting enough information about you to functionally impersonate you) are much more lucrative than any pick pocketing.
In academia, specifically, when it is
a class project, the purpose is to teach the students how to do things, rather than just grab someone else's code. The focus is
not on saving time and money, but on learning how to do things themselves.
In academia (especially undergraduate) the focus is to expose the student to subject at hand so that they know where they have to look when they really have to do something. If one really wanted them to learn to do things one wouldn't throw a half dozen new subjects at them every 4 months.
Using someone else's code, even if only for a
portion of the code, is having someone else do it for them. Thus, it is considered cheating.
Usually, even in accademia knowing who to ask and what to ask are just as (if not more) important than being able to do it yourself. The fact is that every prof/t.a./lab tech assumes his course is the only one in the curriculum, and you as the student should have more than enough time to gain the same level of understanding as he has after 20 years of teaching the course. Of course if he's a prof he'd rather be doing research anyway so you (as a student) are just an inconvenience.
Now, the simple fact is that all sorts of electronic devices do affect our mental abilities adversely, and in various
ways. They do so through radiation, which heats the brain up, not a good thing.
To me it looks like the cases cited in the article can be attributed to a stress related mental breakdown. One of my co-workers (at an old job) got physically sick (requiring bed rest), when the responsiblities he took on, and the idiots he hired, caught up with him. And its not like the Japanese aren't know for working themselves to death... Better get a tinfoil hat, the orbital mind contol lasers might get you and zap your memory.
You're right, eh. All us canuks speak some strange foreign language that you just must drive 30 hours to hear, eh. And those people in San Fran...eh, can't make heads or tails of what they're saying, eh. New york is even worse, eh! Imagine how confusing it is, eh. Those people from brooklyn, eh, they speak differently from those in harlem, eh.
I know many programmers that, despite having no 'formal' training, can run rings around the Software Engineers I
know.
The ability to hack, and knowledge of computer system internals, cannot be compared to software engineering. Software engineering requires knowledge of the design process, understanding of system design, and understanding of scheduling. It requires the ability to manage design, complexity, schedule, and people. These are the points where most programmers of all grades fall down... It is the core of why software sucks. Most of the people writing code don't want to manage. They want to design. They don't want to schedule. To them management and scheduling are a burden that takes them from the pure thought stuff that they love to work with it. The price that is then paid, is that people who have no concept of the tasks at hand are asked to do the management component. Unreasonable deadlines are set, features are changed without the proper estimate of the effor to make the changes...
There is another thing to add to this. It is that people have been building things for millenia. Yet very little of this experience has been transfered to software design. Consider the planning and construction of a ship. Surely the techniques that are applicable in the engineering of that ship (remeber what I said about the management component of engineering -its what makes you and engineer not a scientist) should be to some extent applicable with in software engineering. Yet from my reading of software engineering texts this transfer has not happend. I think it has specifically to do with the sort of backgrounds from which people come to software. The theoretical underpinnings of software have always come from mathematics, where practical things like getting resources can be assumed away. A large number of the remainder have come without any education at all (self taught). They are not in a position to draw these links. They don't know where to look for the information.
You're absolutely right.... as a matter of fact those 'surfing for hot sexy babes?' adds that have been showing up around here recently are offering a service that most of the slashdot population desperately need. The ability to surf anonymously for 'hot sexy babes' from work!
Boy am I glad that the only way you can sell anonymity online is for the ability to surf porn.
but the US
government, and any other group answerable to the US people alone, sure as hell isn't.
The us department of commerce has last say on all this because, like it or not, the us goverment paid for most of the initial development and expansion of the Internet. Like the saying goes "he pays he says". Is it going to change any time soon?.. Its not likely. To quote The Queen of England (in reference to the falklands): "we don't see any reason to give up something that belongs to us".
All the rest of this is hot air.
When we have local elections in Munich, Germany, we can choose between approximately 300
Candidates.
Wow! Thats a lot of candidates. Must be quite a headache to sort out. How do you prevent votes from being siphoned of? I mean 1 out of 80 wrong (intentionally or unintentionally) is with in the real of human possibility. Maybe the answer to america's vote counting problems is to bring over a whole pile of germans once every 2 years (presidential and midterm elections).:)
Perhaps because the US has approx. 260 millions residents, whereas Canada has less than 29 million (source:
Wrong bigger. When an election is held in canada, (federally) we only vote on one thing: the local member of parliment. When an election is held in the US all sorts of other measures are on the ballot. Some of these are for the county, some for the state, and some are federal (some of you americans help me out here if I've missed something). Thats why county by they do thier own ballot.... which makes quite a bit of a mess. The shear number of things to vote on and number of ballots (president, congressman, senator, measures etc) mean that it takes a lot longer to count the vote in the US than in Canada.
You don't
blame the shill for the game of the con-man.
By your rational the whole market (under any conditions) is a con. By extension any form of sale (for cash) or barter is too. Any place where I as a merchant try to sell something to a buyer is. After all, I'm going to proceed so as to make my goods appear as valuable as possible (to all buyers).
people finally realizing that there is no way these companies can sustain their market cap
Nope. What caused the crash is people stopping to believe that everyone else was believing. Its all about consumer confidence... which is like a shared halucination. I think that the market is going to go up, and that I can make money buying this stock. Whats more a lot of other people share the same belief, so the stock keeps going up. As long as more people believe that they can make money then those that don't, the stock will keep going up. The market cap (total value of all shares) is a manifestation of the shared halucination. The real things are the earnings per share, the profits and so on. Economists have been warning for months, if not years, that there was a stock bubble and grinding their teeth about how bad it will be when it bursts. Their main point has been that by all (what had been up to now) rational indicators (earnings etc) these stocks were not worth what they were being traded for. But their words fell on deaf ears. Everyone believed that yahoo was work 200+$/share. After all, all of america can't be wrong. But the moment the halucination ends yahoo is worth (relatively) peanuts.
10. VA Linux stock crashes, as they have no possible way of justifying the market cap.
11. VA Linux stock loses 95% of its value
I love the omission... how about 10.A. market nose dives.
In any case, after the crazy way the nasdac has been behaving it should be blatently obvious that stock prices have no basis in reality. For an extended period of time it has been simply an excercise in mob mentality. Everybody's been hit large and small. So you're going to grow by 4%, not 5%, this year. We'll all get out here's a 20% cut in your stock price? VA can't control its shareholders overreaction to its statements, or the general market skitishnes.
This has everything to do with dumb investors and nothing to do with companies. You shouldn't get into the market unless you do the research... and even then, these days the research sometimes isn't worth a damn.
Hungarian Notation: Hungarian Notation is the tactical nuclear weapon of source code
obfuscation techniques; use it! Due to the sheer volume of source code contaminated by
this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian
Notation attack.
First of all, this will be my last reply to this (and other) threads (sipposedly) about debugging MT code. We are way
off topic here.
Feel free to take this off line if you like.
i.e. inserting real's into a list of
(conceptually, when you dont have parametrised types) integers.
I guess, first off I don't see this as so common an error. Next, my point has been that in order to generate the above errors (at least in Java) you must wrap the Java collection in a class whose interface verifies the type. This will give you at least a basic compile time verification.
On dynamicly loaded code
Therefore you will not have problems with later loaded dynamic code.
But then this is a compile time error, regardless of whether or not we have generic programming.
This is why you need generic
programming and parametrised types in the first place
Parameterised types do guarantee that you don't try to further refine the parameters. But I thought that was just good programming practice, not to further refine the types of arguments, regardless of having or not having templates.
On constant References, Reader-Writer, etc, and class hierarchies.
Regardless of the implementation language you can't use finally or const to return your references because both of these rely on the cooperation of the invoker to use finally or not to cast away constness. For the writer, the relevant reference type must provide setValue and getValue operations. For the readers it must only provide get operations. In java this would mean two interfaces. A refValueReader interface and a refValueWriter interface that extend the first. The the monitor writer you put the data to be written in instances of the refValueWriter type, in the readers you are returned instances of the refValueReader interface. In C++ terms the difference is in how you override the functions of the operators on the type. You would have to (forexample) override the = operator to prevent the reftype from being an lvalue in some cases...
The STL collections are programmed using generic programming, which means, that they operate on any compile-time
refined type.
In C++ it would be hard to implement collections in the OO paradigm, since classes do not inherit from a common
base class.
I'll quote again from the same source:
In sum, we achieve genericity by means of a design idea, i.e. separation of data structures from algorithms, and by use of programming
techniques supported by the programming language, i.e. C++ class and function templates.
Although generic programming uses classical object-oriented C++ language features such as class (template) declarations, it is not
object-oriented. How does generic programming contrast to object-oriented ideas?
In object-oriented programs abstractions are expressed by means of base classes.
In generic programs the abstractions are described in terms of formal, yet verbal requirements. Examples of such requirements are:
A container must provide certain iterators.
An iterator must provide certain operations, such as increment and dereference.
An algorithm must work on iterator ranges.
In my (admittedly brief) online search for definitions of generic programming that include compile time constraints as a fundamental property of genericity I've come up with: bubkas. The underlying feature is that inheritance is spearated from polymorphism. The problem with it as expressed in C++ is that there is no formal way to guarantee compliance with the stated verbal interface that can be gauraneeted by the programming language. If one looks at the base functionalities of types in C++, and compares them with the base functionalities of (reference) types in Java one notices that they are strikingly similar. Further if one speaks strictly, things such as operators are in fact short hands for function calls of the the nature int plus(int, int). Thus the fact that operator overloading is not allowed in java is irrelevant. The point is that C++ has an implicit common base type (operations I can do any any type, and infact it has a number of types derived from it (pointer types etc) but this is done by the language not the user), where as java has an explict one (Object). Template operations with in STL collections use these implicit common bases in order to be meaningfull. Java Collection operations use an explicit common base to be meaningfull (such is the language). In both cases a greater guarantee can be made of smenatic correctness of a program by insisting on an abstract base class that overrides given default operations. But this would taint the purity of the genericity.
The key point is that generic programming sperates algorithm from data structure. I can do this in java, but I must stipulate that all reference are to Object. The most generic type. I can also stiplate some semantic ordering of the basic operations on arbirary types, but then the programming language cannot help me short of using object orientation. Java Collections (like STL) allows me precisely this separation of algorithm from datastructure.
The whole point was to have type-safety, and get compile-time errors, instead of runtime error's which may occur
after you shipped the product.
Given that in java I can load a class from anywhere at anytime, the class cast exception may be generated by my code, but might have its root in some code that was made to invoke my code long after I finished it. I don't know if this is completely feasible in Java.
Java does have final, so you can pass parameters can prevent thier alteration.
Java has value constants, not reference constants. Please try to think a bit about the difference:
class A {
B bInstance;
const b getbInstance() { return bInstance; }
}
I never claimed that you could return a constant from a function in general. However, once a final reference is initialized it cann't be changed.
So I can go: B getB(final C c){...}
and in the invoking function declare: final B b = a.getB(new C())
They (final B b, and final C c) are reference constants, but I realize this is not what you're after... You want to specify the constness, not to rely on the invoker, then again in C++ what prevents me from casting away the constness? So whats the diff? A properly constructed B will prevent me from altering its internals, and if I lose my reference to it, well its my own damn fault. So if you don't want me to change it, you shouldn't be returning it. You should provide accessors to the relevant data memebers.
The trick is, that you wish to specify the concrete type that an algorithm work on (specializing the
interface if you will, some call this compile-time type refinement), so that you will get compile-time type-errors if the
(type-instantiated) algorithm is applied to data of the wrong type.
I think they might want compile time refinement for the speed... Its faster to figure it out at compile time than runtime. In any case, if I create a class foo. and then declare:
list<foo*> bar;
now I try to do a bar.find on this list for some specific foo. Unless I've overridden the == operator for the foo* type this operation will compare pointers not the values of the foo objects. No compile time check will catch this.
Further after a look around the web, I came across a
comparison of OO and GP and to quote the author:
We note that a significant part of the generic programming paradigm can be expressed in terms of C++ language constructs; other parts
cannot be expressed by means of the programming language. There are requirements to containers, iterators, and algorithms that are not
expressed by means of language features and hence will not even be detected at compile or template instantiation time.
Under the premise that generic programming requires full knowledge of types at compile time. Java cannot (at least under java 1.2 not sure about 1.3) support generic programming (neither can C++ using virtuals) yet Java Collections looks and behaves a hell of a lot like STL. The latter is by all acounts an example of generic programming. The STL (to me at least) and Java collections represent abstract generic data structures, algorithms, and access methods. The implementation differences are mainly syntactic, as are the compile/runtime differences. These last are a result of the implemtation language not a fundamental property.
1.Java has NO! parametrised types This means that generic programming is impossible. One specific
consequence of that is, that collections cannot be type-safe, and you loose a lot of the help that
type-errors can buy you.
I can very easily override the insertion routeines for collections with, something that calls the instanceof operator... and return if it returns false. This gives me the sort of typesafety you're talking about.
Java doesn't have "const" (and friends) which means that when you give someone an object reference
you have no control over what they do with that. When returning read-only object, the only solution is
to clone() them. Very expensive!
Java does have final, so you can pass parameters can prevent thier alteration.
But where I really take issue here is the statement that generic programming is impossible in Java. Consider how STL (C++ standard template librarary) defines the use of your own types in its defined datastructures and algorithms library. They say: you must provide your own implementations of (for example) the == operator for list searches to be effective (don't have my book in front of me so can't be more specific right now). This is exactly analagous to saying in java, you must implement a specific interface, and only those classes which implement that interface can be operated on. The fact that you don't have templates is offset by the fact that you do have a common base class (Object), so you don't need templates. I can define a method in java to accept an instance of an interface, I can also define a method in C++ to accept an instance of a base, or virtual base class. These both acomplish the same thing, accept a general type in some algorithm, and allow operation using just a set of base methods. In both cases I can (if I want a big maintenance headache later) try to cast the objects passed in to any type I want to in the method.
The way you right generic code in Java and in C++ is different, but both allow it.
Basically xato went out and tried to figure out which bugs existed, which bug affected a given ms system, and which hot fix works for that bug... It was hell.
other than what the author mentioned, 3 things bother me a lot:
<Bastard>
Its open source, if these things bug you so much why don't you help fix them. Isn't that the way the model is supposed to work.
</Bastard>
Seriously, since I started using mozilla there have been a couple of times that I've come pretty damn close to getting the code to play with it myself. Haven't had those feelings much since I started to more or less live at work though.
And just why shouldn't it run fine on a 486/50? NS3 did.
but isn't part of the point of open source that we can
develop better software instead of bloatware?
Do you actually code?
You want full (compliant) implementations with all sorts of things like style sheets, javascript, the latest html standard, and at the same time you want the brower to run like hot shit off a greased shovel. Hate to break it to you, but with the amounts that those things have evolved its a hell of a lot more than the NS3 team ever had to even think about. Even if you go feature for feature with NS3 (lets say javascript support) I garuantee you the current implementations are going to be slower (and larger), because the standards have grown to encompas more things. You have to put in new hooks and rewrite your code to support more stuff. Its not bloatware. Users expect a certain minimum set of features. That set is larger now than it was 2 years ago. The software has to grow to accomodate it, it has to do more work to implement them. Now add in some debugging code and hell no wonder its slower than 4.76 (at least on my P200 MMX) but it doesn't crash half as much.
--locust.
Re:voting from the comfort of your own home -bad
on
eLection '04
·
· Score: 2
I agree with you that as a replacement for absentee balots it might be workable (assuming you can get around the authentication issues). California did a study on online voting and basically said that elections online at this point cannot be made free and fair. But I digress. The reason it might be acceptable for absentee balots is that the people who receive these are dispursed widely, and thus the likelyhood of large scale tampering/intimidation is small. Further the number of absentee balots is small relative to the general voting population, so the impact of any fraud is mimizied (though it might not fly in florida right now).
On general principle (that is if we apply this to elections outside the US) I would still worry about cities with large expatriot communities, where you would have to go back to the polling station method.
--locust
voting from the comfort of your own home -bad
on
eLection '04
·
· Score: 5
Being able to vote from anywhere creates situations where people with a vested interest in how you vote (your boss, on an anti corporate measure) demand that you vote in thier presence, where they can watch your vote. This preasure can have adverse effects on your career, and your personal relationships. Imagine if there is something you don't agree with your wife on, and know if its brought up there will be an argument. Now one or the other can be considerably upset at a vote that they've seen. Another example pertains to registered rep/democ voters in the us. I could easily see the parties demanding that thier registered members vote at a party installation where they are watched, and harassed if they don't vote the party line. Further, because most voting places will not be secure (it
s easier to secure a polling stations) your voting history can easily be recorded and used against you.
Technology is not the solution to all problems.
--locust
Have you actually read this platform... here are a few high lights:
workers should be allowed to elect their bosses
Make police officers stand for election every four years, voted on by the districts they patrol.
(this is how he plans to end police brutality).
Taxpayers should also be given a multiple choice of the ten or fifteen major areas of government to decide what percentage of their tax money goes where.
See youth apathy magically turn around when they know they have a real stake in their future
and get to vote for their school boards, and why not their teachers?
So responsiblity through being voted out of a position? Right, we'll vote a local pusher out of his position because he's cutting the dope with icing shugar. That'll teach him. I'll start a campaign to remove my teachers because I failed a given test (starting at age 5 no less). My boss told me I was doing a crappy job so I'll have him replaced by someone who won't give me such a hard time.
Now lets consider if the average person picked where his/her tax dollars went (off a checklist)... I'm sure health and education would get a lot of money. Most people wouldn't give a rats ass about santiation, though.Nobody would move the trash, or improve water and sewer. Those things aren't glamourous, but they keep our cities going. How many are selfenlightened enough to pick those as where the money goes?
Finally theres: Ending police brutality. I may as well put world peace on an election platform. And how? Bye god we'll vote you out of office! Don't help the police deal with thier problems, or punish for transgressions, vote them out office. Officer Murphy... I'll remeber this speeding ticket next time we go to the polls.
Most of these things work assuming a wealthy educated populus who understand the nature and weight of the things they are voting on. How is a 5 year old going to know what they're voting for? For that matter who's going to have time to do anything. Sorry, can't deliver that module on wednesday we're voting on whether or not the barber can keep his license.
they can gradually reduce the field in such a way that it'd bring
them to a stop in just the right place.
But then they would lose the magnetic shield that the propulsion system gives them. Worse, coming back they would have to counteract the force exerted by the solar wind.
More and more software is being
developed haphazardly without a clear design, coherent engineering or a well defined development
roadmap.
From everything I hear MS puts a lot of emphasis on the software process. This doesn't prevent them from succumbing to the same failures. Complexity is the enemy of security, and paraphrasing Brook's law... The complexity of a piece of software goes up as the square of the number of modules (features?) involved. Examining a product like Netscape, or IE, even good engineering practice cannot prevent such an extremely complex systems from behaving chaotically at some point. Now add to this short deadlines, and insufficient knowledge: of programming, of the off-the-shelf modules being used; and of the design of the system by the programmers writing it and you have holes waiting to happen. It is a credit to the people writing the software that such holes are not discovered more often.
Slashdot Mirror
Right on. Encryption is also a tool that helps prevent your information from being violated. Notice that the availabilty of weapons and training (selfdefence) are proactive. They are things you can do yourself to learn to deal with potentailly unpleasant situations. You have options other than: wait for the cops to get there (though this may still be your safest one). Encryption is a similar tool for the defence of your information... And in this day and age direct information attacks such as true name fraud (basically by collecting enough information about you to functionally impersonate you) are much more lucrative than any pick pocketing.
--locust
In academia (especially undergraduate) the focus is to expose the student to subject at hand so that they know where they have to look when they really have to do something. If one really wanted them to learn to do things one wouldn't throw a half dozen new subjects at them every 4 months.
Using someone else's code, even if only for a portion of the code, is having someone else do it for them. Thus, it is considered cheating.
Usually, even in accademia knowing who to ask and what to ask are just as (if not more) important than being able to do it yourself. The fact is that every prof/t.a./lab tech assumes his course is the only one in the curriculum, and you as the student should have more than enough time to gain the same level of understanding as he has after 20 years of teaching the course. Of course if he's a prof he'd rather be doing research anyway so you (as a student) are just an inconvenience.
--locust
--locust
To me it looks like the cases cited in the article can be attributed to a stress related mental breakdown. One of my co-workers (at an old job) got physically sick (requiring bed rest), when the responsiblities he took on, and the idiots he hired, caught up with him. And its not like the Japanese aren't know for working themselves to death... Better get a tinfoil hat, the orbital mind contol lasers might get you and zap your memory.
--locust
--locust
The ability to hack, and knowledge of computer system internals, cannot be compared to software engineering. Software engineering requires knowledge of the design process, understanding of system design, and understanding of scheduling. It requires the ability to manage design, complexity, schedule, and people. These are the points where most programmers of all grades fall down... It is the core of why software sucks. Most of the people writing code don't want to manage. They want to design. They don't want to schedule. To them management and scheduling are a burden that takes them from the pure thought stuff that they love to work with it. The price that is then paid, is that people who have no concept of the tasks at hand are asked to do the management component. Unreasonable deadlines are set, features are changed without the proper estimate of the effor to make the changes...
There is another thing to add to this. It is that people have been building things for millenia. Yet very little of this experience has been transfered to software design. Consider the planning and construction of a ship. Surely the techniques that are applicable in the engineering of that ship (remeber what I said about the management component of engineering -its what makes you and engineer not a scientist) should be to some extent applicable with in software engineering. Yet from my reading of software engineering texts this transfer has not happend. I think it has specifically to do with the sort of backgrounds from which people come to software. The theoretical underpinnings of software have always come from mathematics, where practical things like getting resources can be assumed away. A large number of the remainder have come without any education at all (self taught). They are not in a position to draw these links. They don't know where to look for the information.
--locust
Boy am I glad that the only way you can sell anonymity online is for the ability to surf porn.
--locust
The us department of commerce has last say on all this because, like it or not, the us goverment paid for most of the initial development and expansion of the Internet. Like the saying goes "he pays he says". Is it going to change any time soon?.. Its not likely. To quote The Queen of England (in reference to the falklands): "we don't see any reason to give up something that belongs to us". All the rest of this is hot air.
--locust
Wow! Thats a lot of candidates. Must be quite a headache to sort out. How do you prevent votes from being siphoned of? I mean 1 out of 80 wrong (intentionally or unintentionally) is with in the real of human possibility. Maybe the answer to america's vote counting problems is to bring over a whole pile of germans once every 2 years (presidential and midterm elections). :)
--locust
Wrong bigger. When an election is held in canada, (federally) we only vote on one thing: the local member of parliment. When an election is held in the US all sorts of other measures are on the ballot. Some of these are for the county, some for the state, and some are federal (some of you americans help me out here if I've missed something). Thats why county by they do thier own ballot.... which makes quite a bit of a mess. The shear number of things to vote on and number of ballots (president, congressman, senator, measures etc) mean that it takes a lot longer to count the vote in the US than in Canada.
--locust
By your rational the whole market (under any conditions) is a con. By extension any form of sale (for cash) or barter is too. Any place where I as a merchant try to sell something to a buyer is. After all, I'm going to proceed so as to make my goods appear as valuable as possible (to all buyers).
people finally realizing that there is no way these companies can sustain their market cap
Nope. What caused the crash is people stopping to believe that everyone else was believing. Its all about consumer confidence... which is like a shared halucination. I think that the market is going to go up, and that I can make money buying this stock. Whats more a lot of other people share the same belief, so the stock keeps going up. As long as more people believe that they can make money then those that don't, the stock will keep going up. The market cap (total value of all shares) is a manifestation of the shared halucination. The real things are the earnings per share, the profits and so on. Economists have been warning for months, if not years, that there was a stock bubble and grinding their teeth about how bad it will be when it bursts. Their main point has been that by all (what had been up to now) rational indicators (earnings etc) these stocks were not worth what they were being traded for. But their words fell on deaf ears. Everyone believed that yahoo was work 200+$/share. After all, all of america can't be wrong. But the moment the halucination ends yahoo is worth (relatively) peanuts.
--locust
11. VA Linux stock loses 95% of its value
I love the omission... how about 10.A. market nose dives.
In any case, after the crazy way the nasdac has been behaving it should be blatently obvious that stock prices have no basis in reality. For an extended period of time it has been simply an excercise in mob mentality. Everybody's been hit large and small. So you're going to grow by 4%, not 5%, this year. We'll all get out here's a 20% cut in your stock price? VA can't control its shareholders overreaction to its statements, or the general market skitishnes.
This has everything to do with dumb investors and nothing to do with companies. You shouldn't get into the market unless you do the research... and even then, these days the research sometimes isn't worth a damn.
--locust
Proud of yourself aren't you? How many people that had nothing to with firing the girl, ended up out of job because you are an asshole?
--locust
moderators: go a head make my day.
Hungarian Notation: Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack.
--locust
Feel free to take this off line if you like.
i.e. inserting real's into a list of (conceptually, when you dont have parametrised types) integers.
I guess, first off I don't see this as so common an error. Next, my point has been that in order to generate the above errors (at least in Java) you must wrap the Java collection in a class whose interface verifies the type. This will give you at least a basic compile time verification.
On dynamicly loaded code
Therefore you will not have problems with later loaded dynamic code.
But then this is a compile time error, regardless of whether or not we have generic programming.
This is why you need generic programming and parametrised types in the first place
Parameterised types do guarantee that you don't try to further refine the parameters. But I thought that was just good programming practice, not to further refine the types of arguments, regardless of having or not having templates.
On constant References, Reader-Writer, etc, and class hierarchies.
Regardless of the implementation language you can't use finally or const to return your references because both of these rely on the cooperation of the invoker to use finally or not to cast away constness. For the writer, the relevant reference type must provide setValue and getValue operations. For the readers it must only provide get operations. In java this would mean two interfaces. A refValueReader interface and a refValueWriter interface that extend the first. The the monitor writer you put the data to be written in instances of the refValueWriter type, in the readers you are returned instances of the refValueReader interface. In C++ terms the difference is in how you override the functions of the operators on the type. You would have to (forexample) override the = operator to prevent the reftype from being an lvalue in some cases...
The STL collections are programmed using generic programming, which means, that they operate on any compile-time refined type.
In C++ it would be hard to implement collections in the OO paradigm, since classes do not inherit from a common base class.
I'll quote again from the same source: In sum, we achieve genericity by means of a design idea, i.e. separation of data structures from algorithms, and by use of programming techniques supported by the programming language, i.e. C++ class and function templates. Although generic programming uses classical object-oriented C++ language features such as class (template) declarations, it is not object-oriented. How does generic programming contrast to object-oriented ideas? In object-oriented programs abstractions are expressed by means of base classes. In generic programs the abstractions are described in terms of formal, yet verbal requirements. Examples of such requirements are: A container must provide certain iterators. An iterator must provide certain operations, such as increment and dereference. An algorithm must work on iterator ranges.
In my (admittedly brief) online search for definitions of generic programming that include compile time constraints as a fundamental property of genericity I've come up with: bubkas. The underlying feature is that inheritance is spearated from polymorphism. The problem with it as expressed in C++ is that there is no formal way to guarantee compliance with the stated verbal interface that can be gauraneeted by the programming language. If one looks at the base functionalities of types in C++, and compares them with the base functionalities of (reference) types in Java one notices that they are strikingly similar. Further if one speaks strictly, things such as operators are in fact short hands for function calls of the the nature int plus(int, int). Thus the fact that operator overloading is not allowed in java is irrelevant. The point is that C++ has an implicit common base type (operations I can do any any type, and infact it has a number of types derived from it (pointer types etc) but this is done by the language not the user), where as java has an explict one (Object). Template operations with in STL collections use these implicit common bases in order to be meaningfull. Java Collection operations use an explicit common base to be meaningfull (such is the language). In both cases a greater guarantee can be made of smenatic correctness of a program by insisting on an abstract base class that overrides given default operations. But this would taint the purity of the genericity.
The key point is that generic programming sperates algorithm from data structure. I can do this in java, but I must stipulate that all reference are to Object. The most generic type. I can also stiplate some semantic ordering of the basic operations on arbirary types, but then the programming language cannot help me short of using object orientation. Java Collections (like STL) allows me precisely this separation of algorithm from datastructure.
--locust
Given that in java I can load a class from anywhere at anytime, the class cast exception may be generated by my code, but might have its root in some code that was made to invoke my code long after I finished it. I don't know if this is completely feasible in Java.
Java does have final, so you can pass parameters can prevent thier alteration. Java has value constants, not reference constants. Please try to think a bit about the difference: class A { B bInstance; const b getbInstance() { return bInstance; } }
I never claimed that you could return a constant from a function in general. However, once a final reference is initialized it cann't be changed. So I can go:
B getB(final C c){...}
and in the invoking function declare:
final B b = a.getB(new C())
They (final B b, and final C c) are reference constants, but I realize this is not what you're after... You want to specify the constness, not to rely on the invoker, then again in C++ what prevents me from casting away the constness? So whats the diff? A properly constructed B will prevent me from altering its internals, and if I lose my reference to it, well its my own damn fault. So if you don't want me to change it, you shouldn't be returning it. You should provide accessors to the relevant data memebers.
The trick is, that you wish to specify the concrete type that an algorithm work on (specializing the interface if you will, some call this compile-time type refinement), so that you will get compile-time type-errors if the (type-instantiated) algorithm is applied to data of the wrong type.
I think they might want compile time refinement for the speed... Its faster to figure it out at compile time than runtime. In any case, if I create a class foo. and then declare: list<foo*> bar;
now I try to do a bar.find on this list for some specific foo. Unless I've overridden the == operator for the foo* type this operation will compare pointers not the values of the foo objects. No compile time check will catch this.
Further after a look around the web, I came across a comparison of OO and GP and to quote the author: We note that a significant part of the generic programming paradigm can be expressed in terms of C++ language constructs; other parts cannot be expressed by means of the programming language. There are requirements to containers, iterators, and algorithms that are not expressed by means of language features and hence will not even be detected at compile or template instantiation time.
Under the premise that generic programming requires full knowledge of types at compile time. Java cannot (at least under java 1.2 not sure about 1.3) support generic programming (neither can C++ using virtuals) yet Java Collections looks and behaves a hell of a lot like STL. The latter is by all acounts an example of generic programming. The STL (to me at least) and Java collections represent abstract generic data structures, algorithms, and access methods. The implementation differences are mainly syntactic, as are the compile/runtime differences. These last are a result of the implemtation language not a fundamental property.
--locust
I can very easily override the insertion routeines for collections with, something that calls the instanceof operator... and return if it returns false. This gives me the sort of typesafety you're talking about.
Java doesn't have "const" (and friends) which means that when you give someone an object reference you have no control over what they do with that. When returning read-only object, the only solution is to clone() them. Very expensive!
Java does have final, so you can pass parameters can prevent thier alteration.
But where I really take issue here is the statement that generic programming is impossible in Java. Consider how STL (C++ standard template librarary) defines the use of your own types in its defined datastructures and algorithms library. They say: you must provide your own implementations of (for example) the == operator for list searches to be effective (don't have my book in front of me so can't be more specific right now). This is exactly analagous to saying in java, you must implement a specific interface, and only those classes which implement that interface can be operated on. The fact that you don't have templates is offset by the fact that you do have a common base class (Object), so you don't need templates. I can define a method in java to accept an instance of an interface, I can also define a method in C++ to accept an instance of a base, or virtual base class. These both acomplish the same thing, accept a general type in some algorithm, and allow operation using just a set of base methods. In both cases I can (if I want a big maintenance headache later) try to cast the objects passed in to any type I want to in the method.
The way you right generic code in Java and in C++ is different, but both allow it.
--locust
Basically xato went out and tried to figure out which bugs existed, which bug affected a given ms system, and which hot fix works for that bug... It was hell.
--locust
<Bastard> Its open source, if these things bug you so much why don't you help fix them. Isn't that the way the model is supposed to work. </Bastard>
Seriously, since I started using mozilla there have been a couple of times that I've come pretty damn close to getting the code to play with it myself. Haven't had those feelings much since I started to more or less live at work though.
--locust
but isn't part of the point of open source that we can develop better software instead of bloatware?
Do you actually code?
You want full (compliant) implementations with all sorts of things like style sheets, javascript, the latest html standard, and at the same time you want the brower to run like hot shit off a greased shovel. Hate to break it to you, but with the amounts that those things have evolved its a hell of a lot more than the NS3 team ever had to even think about. Even if you go feature for feature with NS3 (lets say javascript support) I garuantee you the current implementations are going to be slower (and larger), because the standards have grown to encompas more things. You have to put in new hooks and rewrite your code to support more stuff. Its not bloatware. Users expect a certain minimum set of features. That set is larger now than it was 2 years ago. The software has to grow to accomodate it, it has to do more work to implement them. Now add in some debugging code and hell no wonder its slower than 4.76 (at least on my P200 MMX) but it doesn't crash half as much.
--locust.
--locust
Technology is not the solution to all problems. --locust
So responsiblity through being voted out of a position? Right, we'll vote a local pusher out of his position because he's cutting the dope with icing shugar. That'll teach him. I'll start a campaign to remove my teachers because I failed a given test (starting at age 5 no less). My boss told me I was doing a crappy job so I'll have him replaced by someone who won't give me such a hard time.
Now lets consider if the average person picked where his/her tax dollars went (off a checklist)... I'm sure health and education would get a lot of money. Most people wouldn't give a rats ass about santiation, though.Nobody would move the trash, or improve water and sewer. Those things aren't glamourous, but they keep our cities going. How many are selfenlightened enough to pick those as where the money goes?
Finally theres: Ending police brutality. I may as well put world peace on an election platform. And how? Bye god we'll vote you out of office! Don't help the police deal with thier problems, or punish for transgressions, vote them out office. Officer Murphy... I'll remeber this speeding ticket next time we go to the polls.
Most of these things work assuming a wealthy educated populus who understand the nature and weight of the things they are voting on. How is a 5 year old going to know what they're voting for? For that matter who's going to have time to do anything. Sorry, can't deliver that module on wednesday we're voting on whether or not the barber can keep his license.
--locust
But then they would lose the magnetic shield that the propulsion system gives them. Worse, coming back they would have to counteract the force exerted by the solar wind.
--locust
From everything I hear MS puts a lot of emphasis on the software process. This doesn't prevent them from succumbing to the same failures. Complexity is the enemy of security, and paraphrasing Brook's law... The complexity of a piece of software goes up as the square of the number of modules (features?) involved. Examining a product like Netscape, or IE, even good engineering practice cannot prevent such an extremely complex systems from behaving chaotically at some point. Now add to this short deadlines, and insufficient knowledge: of programming, of the off-the-shelf modules being used; and of the design of the system by the programmers writing it and you have holes waiting to happen. It is a credit to the people writing the software that such holes are not discovered more often.
--locust