Why does everyone always assume that not putting on a suit and tie makes one 'lazy' and/or 'sloppy'? Last I checked, it took me about the same time to put my Jeans on as it did to put my Khakis on. The tie is the obvious exception, but other than that - dressing time is pretty nominal. If my jeans are clean and have no holes, my shoes are clean, and my flannel is likewise fresh, I see no reason why I should be treated any better or worse than someone who chose a different looking ensemble.
Where I work, Jeans are seen as unprofessional. Not even perfectly clean, hole-less jeans. I don't quite understand how the fiber something is made out of makes it unprofessional. Its like purchasing clothing that is rugged and lasts is seen as a sign of the proletariat. I personally think they look pretty good... but i'm not a PHB.
He never said.Net wasn't fast. Rather he claimed that.Net performance is inferior to an equivalent application written in C++ (or equivalent). Whether you think its fast and dont mind the extra memory is totally irrelevant to his point.
Throw enough hardware at a problem and it will (usually) be perceived as fast. Many financial industry applications operate under this ideology.
This has been mentioned before, but like Java,.Net will only protect you while in the VM (or its JIT'd output, or whatever). System services tend to do low level things, and will most likely need to call at least one compiled DLL. While writing services in.Net would likely reduce the number of bugs/holes by some amount, it would most likely not remove the larger ones.
You do realize that a good number of.Net controls are just wrappers around the very same native code controls you are claiming are the cause of the problem, right?
While it is true that there is nothing wrong with the concept of doing it in.Net (there are filesystem explorers in Java too), you claimed you wouldn't notice a performance difference. I am refuting that claim. I say that instead of not noticing a difference, you would, in fact, notice a difference - in both speed and memory signature. While it may not be apparent on the newest of boxes, the performance difference would most likely be noticable on my parent's PC.
In addition, I also wonder exactly how you know that the windows tree-view/list-view/etc controls are not efficient. They are, after all, running in native code, and have been a part of windows for a very long time. Logic would dictate that they are some of the more efficient controls in the OS, since they were created when system resources were very much less than they were today.
Well, there is a really easy way to test your theory. Try creating a windows explorer clone in.Net. I dont think you will find it as efficient as you seem to think it will be. The native code version already hangs when listing directories with mere thousands of files. In addition to some added slowness, I predict you will most likely also notice a considerable memory bloat.
Not much, but why rewrite something? The net result is just a notepad that runs about the same as the original, with no physical difference. Joe End User is not impressed. Rewriting things in the latest and greatest programming language of the day always sounds cool from a geek perspective, but from a business standpoint (and just plain old efficiency standpoint) its wasteful.
Now if they wanted to write some new app in.Net that would be cool. But just as with VB, you will notice Microsoft stays away from their own tools. They know their business strategy, and they know that the current cool buzzword be obsoleted for the next flavor of the month tech that they want to sell to their users.
Nearly every system at my workplace was chosen by the users, and had no input from the IT staff. As such, we are forced into maintaining terribly crippled and lethargic systems that we could have easily identified beforehand.
Democracy rocks. Played that thing non stop for a while. Its also a great game to jump into for a few turns whenever you have a few minutes. Haven't quite figured out how to get Japan out of debt yet, though...
If I get a PHD in compsci, I am also a doctor, and may freely call myself so. Same thing. Or do you now also claim that only people with doctorates in medicine can be called doctors, cuz only they are special like that?
To put it another way, we call the people who designed the pyramids engineers, yet they havent taken my state's test. I say we sue them. While we are at it, we should sue GE, since they call their people software engineers. We should be suing a lot of software businesses, come to think of it.
Yeah, see, that whole ego thing again. "You must be judged by our standards, even though its a completely different field". A good portion of people have more sense than that, and know that software engineering takes a different skill set than other varieties of engineering. And a bad software engineer can do as much damage as any other kind, although generally in a different way. Usually no one dies because of it, but some do have to worry about such things. The software engineers who work for the military, or a health care company like GEMS, do have to worry about such things and go through extensive systematic testing in order to prevent fatalities from poorly engineered code.
I think for the very first semester or two, OO is just a bit too much. Since procedural logic is very much a part of OO ( or any other style of programming ), I feel its important to get that down early. Its also a much easier concept for people to grasp.
Of course, this is how I learned, and I seem to have turned out reasonably well, so I assume it would work for others. For me, the starting language was C++... the whole throw them to the lions and see who survives idea. 20 hour programming assignments every week (I usually did them in half the time, but others didn't catch on so quick) meant a 50+% drop rate in the second semester of programming. They did go into objects, and the basics behind object oriented programming, but it wasn't stressed like a true OO class.
I do believe OO should be taught right after you figure all this stuff out, though. The OOP class at my university was like a junior/senior level course, and I think it should probably be held right after the procedural/OO intro.
Yeah, but I take that as a bit of an ego thing. After all, most of the engineering types I know spend the bulk of their time in AutoCAD and writing programs for cnc machines. If he gets to be called an engineer, I sure the heck can be.
Well, the lack of needed OO support was kind of the reason why I thought Perl would make a good language. Its easy to get into and do non-OO stuff at first, instead of throwing you headlong into OO which, IMO, first year students are not ready for.
Besides, aren't you missing the static main with the args, and the surrounding class, and the system import? The perl code I quoted will run as it is.
With the.Net stuff, you have to at least explain the reason for all these things in a cursory way. In the case of Perl, you just have to tell them that the print command prints stuff.
Yeah, Perl 5.8 does have pretty good OO support, but until you get some stronger typing and parameter control its kind of unwieldy. It can still work just as well as any other, but it lacks the static clarity of most of the other languages.
Of course, Perl 6 seems likely due slightly before the time Duke Nukem Forever comes out...
Its not that bad... at least, it doesn't have to be. Most of the Perl code you see out there, like the code of most languages, is crap. Moreso in the case of Perl, due to its accessability. 5.6+ has had some pretty good OO support, and Perl 6 promises to be a great leap forward in the language in general, especially OO.
Yes, Engineering is an applied science. Most universities that I know of classify it as such. The thing is, in order to apply science, you must first _know_ science.
To be honest, I have never used the language. Mostly an application developer, although I dabble in PHP when I get the chance. You are right, and most of the JavaScript I have looked at is godawful, but my roommate actually attempted to build a fairly extensive JavaScript japaneseenglish program to help teach the language (Japanese, not JavaScript), so I know it has some potential.
Slashdot Mirror
The vast majority of people in general are hilarious idiots.
That you would rather spend 20 minutes a night coding, reading, or otherwise _accomplishing_ something?
Why does everyone always assume that not putting on a suit and tie makes one 'lazy' and/or 'sloppy'? Last I checked, it took me about the same time to put my Jeans on as it did to put my Khakis on. The tie is the obvious exception, but other than that - dressing time is pretty nominal. If my jeans are clean and have no holes, my shoes are clean, and my flannel is likewise fresh, I see no reason why I should be treated any better or worse than someone who chose a different looking ensemble.
Where I work, Jeans are seen as unprofessional. Not even perfectly clean, hole-less jeans. I don't quite understand how the fiber something is made out of makes it unprofessional. Its like purchasing clothing that is rugged and lasts is seen as a sign of the proletariat. I personally think they look pretty good ... but i'm not a PHB.
XBOX Live is $5 a month.
Two possibilities to avoid buyout.
#1 : Dont go public. This does deprive you of initial startup money, but leaves you free to do whatever you want.
#2 : Go public, but dont relinquish the majority of shares. You lose some initial revenue, but you are safe from buyout.
I prefer 1, personally.
He never said .Net wasn't fast. Rather he claimed that .Net performance is inferior to an equivalent application written in C++ (or equivalent). Whether you think its fast and dont mind the extra memory is totally irrelevant to his point.
Throw enough hardware at a problem and it will (usually) be perceived as fast. Many financial industry applications operate under this ideology.
This has been mentioned before, but like Java, .Net will only protect you while in the VM (or its JIT'd output, or whatever). System services tend to do low level things, and will most likely need to call at least one compiled DLL. While writing services in .Net would likely reduce the number of bugs/holes by some amount, it would most likely not remove the larger ones.
You do realize that a good number of .Net controls are just wrappers around the very same native code controls you are claiming are the cause of the problem, right?
.Net (there are filesystem explorers in Java too), you claimed you wouldn't notice a performance difference. I am refuting that claim. I say that instead of not noticing a difference, you would, in fact, notice a difference - in both speed and memory signature. While it may not be apparent on the newest of boxes, the performance difference would most likely be noticable on my parent's PC.
While it is true that there is nothing wrong with the concept of doing it in
In addition, I also wonder exactly how you know that the windows tree-view/list-view/etc controls are not efficient. They are, after all, running in native code, and have been a part of windows for a very long time. Logic would dictate that they are some of the more efficient controls in the OS, since they were created when system resources were very much less than they were today.
You do realize that Direct X is all native code, right?
I can make pretty geometry in Perl using OpenGL, but that doesn't mean Perl is particularly fast.
Well, there is a really easy way to test your theory. Try creating a windows explorer clone in .Net. I dont think you will find it as efficient as you seem to think it will be. The native code version already hangs when listing directories with mere thousands of files. In addition to some added slowness, I predict you will most likely also notice a considerable memory bloat.
Not much, but why rewrite something? The net result is just a notepad that runs about the same as the original, with no physical difference. Joe End User is not impressed. Rewriting things in the latest and greatest programming language of the day always sounds cool from a geek perspective, but from a business standpoint (and just plain old efficiency standpoint) its wasteful.
.Net that would be cool. But just as with VB, you will notice Microsoft stays away from their own tools. They know their business strategy, and they know that the current cool buzzword be obsoleted for the next flavor of the month tech that they want to sell to their users.
Now if they wanted to write some new app in
w0rd to that.
Nearly every system at my workplace was chosen by the users, and had no input from the IT staff. As such, we are forced into maintaining terribly crippled and lethargic systems that we could have easily identified beforehand.
I see the attempt at humor, but unfortunately I know people who sound like this, and they aren't trying to be funny.
Democracy rocks. Played that thing non stop for a while. Its also a great game to jump into for a few turns whenever you have a few minutes. Haven't quite figured out how to get Japan out of debt yet, though ...
If I get a PHD in compsci, I am also a doctor, and may freely call myself so. Same thing. Or do you now also claim that only people with doctorates in medicine can be called doctors, cuz only they are special like that?
To put it another way, we call the people who designed the pyramids engineers, yet they havent taken my state's test. I say we sue them. While we are at it, we should sue GE, since they call their people software engineers. We should be suing a lot of software businesses, come to think of it.
Yeah, see, that whole ego thing again. "You must be judged by our standards, even though its a completely different field". A good portion of people have more sense than that, and know that software engineering takes a different skill set than other varieties of engineering. And a bad software engineer can do as much damage as any other kind, although generally in a different way. Usually no one dies because of it, but some do have to worry about such things. The software engineers who work for the military, or a health care company like GEMS, do have to worry about such things and go through extensive systematic testing in order to prevent fatalities from poorly engineered code.
I think for the very first semester or two, OO is just a bit too much. Since procedural logic is very much a part of OO ( or any other style of programming ), I feel its important to get that down early. Its also a much easier concept for people to grasp.
... the whole throw them to the lions and see who survives idea. 20 hour programming assignments every week (I usually did them in half the time, but others didn't catch on so quick) meant a 50+% drop rate in the second semester of programming. They did go into objects, and the basics behind object oriented programming, but it wasn't stressed like a true OO class.
Of course, this is how I learned, and I seem to have turned out reasonably well, so I assume it would work for others. For me, the starting language was C++
I do believe OO should be taught right after you figure all this stuff out, though. The OOP class at my university was like a junior/senior level course, and I think it should probably be held right after the procedural/OO intro.
Yeah, but I take that as a bit of an ego thing. After all, most of the engineering types I know spend the bulk of their time in AutoCAD and writing programs for cnc machines. If he gets to be called an engineer, I sure the heck can be.
Well, the lack of needed OO support was kind of the reason why I thought Perl would make a good language. Its easy to get into and do non-OO stuff at first, instead of throwing you headlong into OO which, IMO, first year students are not ready for.
.Net stuff, you have to at least explain the reason for all these things in a cursory way. In the case of Perl, you just have to tell them that the print command prints stuff.
Besides, aren't you missing the static main with the args, and the surrounding class, and the system import? The perl code I quoted will run as it is.
With the
Yes, with full support for all 7 layers of the fully realized OSI model.
Yeah, Perl 5.8 does have pretty good OO support, but until you get some stronger typing and parameter control its kind of unwieldy. It can still work just as well as any other, but it lacks the static clarity of most of the other languages.
...
Of course, Perl 6 seems likely due slightly before the time Duke Nukem Forever comes out
Its not that bad ... at least, it doesn't have to be. Most of the Perl code you see out there, like the code of most languages, is crap. Moreso in the case of Perl, due to its accessability. 5.6+ has had some pretty good OO support, and Perl 6 promises to be a great leap forward in the language in general, especially OO.
Yes, Engineering is an applied science. Most universities that I know of classify it as such. The thing is, in order to apply science, you must first _know_ science.
To be honest, I have never used the language. Mostly an application developer, although I dabble in PHP when I get the chance. You are right, and most of the JavaScript I have looked at is godawful, but my roommate actually attempted to build a fairly extensive JavaScript japaneseenglish program to help teach the language (Japanese, not JavaScript), so I know it has some potential.