I'm surprised to be arguing on behalf of Internet f'in Explorer, but I'm left wondering what the hell you're talking about.
Do you have any clue how many threads your OS is successfully managing right now?
I'm at work, my 4 year old 1.6ghz Latitude w/ 1GB ram is running over 300. FireFox, with 3 tabs, opened for just 20 minutes or so, is responsible for 20 of those.
And nothing is bogged down. Everything is responsive.
And the point of this, as any software developer could tell you, is that all threads are not created equal.
There is a little overhead in spawning a new thread, but very little to maintain it. An app could run on 1 single thread and bring down your system or, yes, it could use 171 concurrent threads and run perfectly fine.
You wrote an awful lot there, but you didn't say much of anything.
Here: The actual story I was referencing is the last one on this page. I remember it being a "driveway moment" for me -- I got home, and sat in the driveway until the story was over.
(I had trouble w/ streaming -- but I clicked the "pop out" button and there's a download link from there. It's just an MP3)
IIRC (And I may not), he set up a big demo for the press. They all trekked up to his compound. He flipped the switch and it APPEARED to work. And a bird apparently flew into the path of the transmission and the bird just fell like a brick, as if it died instantly.
Many people speculated that it was a hoax or, if not, it was at least very dangerous.
The story goes further that when he died, the Gov't confiscated his papers. US Scientists looked everything over and concluded it to be impossible.
Then, during the cold war, US Spy imagery showed a huge complex being built in a remote location in the USSR. The military had trouble figuring out what it was. Eventually a Gov't scientist familiar w/ the Tesla work had the 'aha moment' and he pulled-out the tesla papers and sure enough, it seemed as though the Soviets were building an energy weapon of some sort.
Again, IIRC, they never were able to make it work, which is why it's not famous and in school books. But it is interesting that they TRIED and I'd love to read about that project.
(Heard all this about a year ago on a radio program by either NPR or PRI)
You don't HAVE to use XML for RPC requests. Heck, the XmlHttpRequest object doesn't even force you to use XML.
JSON is a much more concise RPC vehicle.
Further, HTTP isn't SUCH a bad RPC protocol. It's remarkably light-weight. HTTP Headers can be a little as 2 lines of text. And a lot of RPC functionality that doesn't involve sending or receiving much data (for example, marking a message as Read in Gmail) you can use a simple HEAD request instead of GET or POST and use the HTTP Status code to determine success/failure in your browser.
A binary protocol would be faster. No doubt about it. But if a dev understands HTTP and uses JSON, it can be pretty speedy.
Olympic level competition is more a JOB than a sport.
And many countries, China among them, would have no compunction about working a child mercilessly if she shows talent and the ability to gain her nation the prestige of a gold medal.
It's not, IMO, as much about unfair competition. It's about having standards as a modern society that a person should have free will and children should be protected from exploitation. The cutoff has to be made somewhere, and right now that cutoff is 15.
You're right about those last 2. I make my devs code PHP at E_NOTICE so they can initialize variables before reading/appending them. It would be nice if there was a strict mode that could raise those errs as an E_WARNING instead of E_NOTICE.
And you're totally right about scoping issues w/ $this.
We have a company-wide template in Zend studio called 'thischk' that we put at the top of any non-static method. It checks that $this is an instanceof whatever the current class is, or else it throws an exception.
(That is, the template uses a variable so when the template is inserted into the code it's replaced by the actual name of the class. Important because the __class__ magic variable has the same scoping problem)
Lumping PHP & Perl together is incorrect. For one, PHP is finally approaching consideration as a "modern" language. It's still being improved upon. And while there's a lot of bad PHP, there's also a lot of bad Java.
Java is right for large applications. For small apps, it's over-engineered. It guides a dev into a multi-tiered architecture. This is good, except when it's overkill.
The secret to being a good dev, with highly marketable skills is simple:
Pick one language from each group:
Group A: Java, C#, Obj-C
Group B: Python, Ruby, PHP
Group C: Perl, VBScript
Obviously this depends on the technology stack at any given company. But if you're a dev that brings:
Java, Python, and Perl
or
C#, PHP and VBScript
or
Obj-c, Ruby, and Perl,
etc, etc, etc
then you're going to be a valuable team member and you're going to have no trouble finding work.
Of course, the judgment to know when to use each is also very important.
C++ is still around for a reason. There are whole classes of problems that simply cannot be solved using the higher level languages you're used to.
Anyone that's ever used C++ for more than the required chapter in school would probably agree that it's not a language for dabblers.
That is, if you want to get GOOD at C++, you need to use it regularly. You need to get GOOD at it. When you do, you learn how to avoid the most painful/tedious parts. You have easily accessible things in your toolbox, like a solid string class that you understand well.
And you learn to avoid things like MFC where they're not needed.
And more than anything, a good C++ developer knows that his language can do anything, and faster, than a higher level language. Device drivers. OS Kernels. Things like that.
I'm no longer a FT C++ dev, but I did it for a long time. The ability to create and boot your very own OS is so, so worth the investment you make in the language.
I'd never create a CRUD app in C++ because I can't see any reason I'd need to. But I could if I wanted to. And that's something that, say, a Ruby or PHP developer couldn't say (That they could build ANYTHING they wantetd to).
And, really, if you think PHP is a "nasty hack" then you seem to me to be trading only in cliches here.
I'm not a huge fan of PHP, but it's a modern language. It's library is ugly. It lacks naming conventions. But its actual code-base is really quite good. If you want to see some well done C++ code, check out the PHP internals. It's made a lot of progress in the last 5-7 years.
It's like saying "Most Basic & VB Code is Verbose, is it really fair to blame the language?"
YES!!
Every language has a unique idiom. And the best languages use this idiom to painlessly guide the developer to best practices.
For exammple, lots of devs consider Java to be over-engineered and overly-complex. You've probably heard a dev talk about building something in, say, RoR in a week that would've taken 4 weeks in Java.
That's probably true, because Java is a tool best designed for large applications and when you're using Java, it's idiom guides you into building multi-tiered architecture.
Python's idiom guides devs into producing well formatted code and it's a great language for web apps because it puts powerful data structures right in the developers face.
C# is a FANTASTIC language for teaching OOD to procedural developers. It's HARD for a procedural developer to think in terms of object hierarchies. The mechanics are easy to pick up. The ability to deconstruct a problem into an object hierarchy is hard.
But you put them in front of a new project in C# and the language -- entirely OO itself -- just guides a developer to the right thing. It's very hard to shoe-horn a procedural architecture into an OO-only language.
JavaScript makes it insanely easy to create an event-driven application. Anonymous functions, LAMBDAs, etc, guide a developer into producing code in an event/event-handler model.
Any developer can do nearly anything with any language. But a language itself can make it easy and obvious when you're doing things right, and painful for you when you're doing them wrong. And a good IDE will reinforce both of these behaviors.
Come on... you act like using a descriptive variable name is some huge overhead that gums up the works.
And to answer your question.. a project manager has to think in terms of TCO. Most systems live long lives. Maintenance, upgrade and troubleshooting WILL happen. And if you can spend dimes now to save dollars tomorrow, it's a wise business decision to do so.
First, let me ask, are you a professional software developer or project manager? (I'm not being arrogant, I'm just curious).
I've got more than a few years under my belt.
A developer gets a spec. He designs a solution and quotes the spec. Assuming he's given the green light, he schedules the projects start date and sets some milestones.
I've worked for DOZENS of companies, large and small, in all economic sectors, as both a contractor and a FTE, and invariably it's some variation on this theme.
The developer designs a solution and sets the schedule.
"Deliverables" means nothing more than the developer hitting the milestones/delivering the artifacts that he set for himself.
In smaller projects, this could be the entire application. In large projects, it's just a single function point.
You can bash the vernacular of the business all you want, but you don't offer any better solution.
If I'm being paid $50/hr to tap a keyboard, shouldn't I be held accountable for results?
But if you've ever actually worked in a large business and you use just a slight amount of common sense, you'd understand what the GP meant.
Most likely they're pulling data from access to Excel. And really, Access is most likely just being used as a front end for an Oracle, DB2, or MSSQL database.
I've honestly been dreaming of building this system since I was 9 years old.
I'm in my late 20's now, so needless to say, I've given it a lot of thought.
Implementing an autodrive system like this on city streets is at least an order of magnitude more difficult than it will be on limited access highways.
And while GPS is very helpful, I really don't think we can rely on a system like this, placing millions of lives every day into its hands, based soley on GPS. I think the road will need to be embedded with RFID posts of some sort. They can be built into the 1/4 mile markers or something, and they could be highly redundant so many could fail, and GPS would certainly be used, just not exclusively.
This is compounded by the transition period where "manual" cars will rule the roads.
So we'd start by picking high-throughput commuter routes. Think of the beltways that exist in most major cities.
The left-most lane becomes the autodrive lane. Over the years, it turns into an exclusively autodrive highway.
So these first autodrive cars will have to be "hybrids."
After 20, 30 years when (literally) every car on the road is autodrive capable, that's when you'd see large rollouts of autodrive on city streets.
This is also a much more difficult issue because of pedestrians.
So my thinking is that people would get used to carrying an RFID transmitter with them. This would serve as their car key when they get in their own car, and it would also serve as a transponder when you're on foot. So if you're standing at a corner waiting to cross the street, the cars 2 blocks away know you're there and you'll be figured in to the traffic flow.
And I really think that a P2P system is the only way to do this. But I also think that we'd need large, distributed traffic analysis and monitoring systems that are capable of watching for malfunctioning or hacked autodrivers.
I'm sorry for writing so much, but I love this shit.
Anyway, one final thought, is that autodrivers would go into defensive mode when they detect a manually driven car or a pedestrian. I imagine a convoy of autodrivers in the autodrive lane on a highway, they're cruising at 70mph and a manually driven car enters the highway and is in the lane beside the autodrivers.
I imagine the software switching into a defensive mode, all of the autodrive cars in the, say, 1/2 mile radius is aware of the manual car, and they perform a monte carlo analysis of thousands of possible evasive scenarios, any one of which could be activated in microseconds if the manually driven car enters the autodrive lane, swerves, crashes, etc.
And I'm sure the occupants of the vehicles would be alerted that defensive mode is in use.
And about speed... a system like this, no doubt, would be safe at very high speeds. But until we figure out how to do so efficiently it would be such a waste.
And as long as manually driven cars are allowed on the highways, you'd need to keep it going slower just to be safe.
Slashdot Mirror
I'm surprised to be arguing on behalf of Internet f'in Explorer, but I'm left wondering what the hell you're talking about.
Do you have any clue how many threads your OS is successfully managing right now?
I'm at work, my 4 year old 1.6ghz Latitude w/ 1GB ram is running over 300. FireFox, with 3 tabs, opened for just 20 minutes or so, is responsible for 20 of those.
And nothing is bogged down. Everything is responsive.
And the point of this, as any software developer could tell you, is that all threads are not created equal.
There is a little overhead in spawning a new thread, but very little to maintain it. An app could run on 1 single thread and bring down your system or, yes, it could use 171 concurrent threads and run perfectly fine.
You wrote an awful lot there, but you didn't say much of anything.
Sure, but that's in Metric. Convert it to Imperial and France = USA.
Trust me, I know. Last time I was in France I bragged about my 9cm cock. Women wouldn't touch me!
To summarize the other 2 replies to your post:
You're wrong. It's far more than a panorama stitcher.
Here: The actual story I was referencing is the last one on this page. I remember it being a "driveway moment" for me -- I got home, and sat in the driveway until the story was over.
(I had trouble w/ streaming -- but I clicked the "pop out" button and there's a download link from there. It's just an MP3)
http://www.studio360.org/episodes/2008/01/25
IIRC (And I may not), he set up a big demo for the press. They all trekked up to his compound. He flipped the switch and it APPEARED to work. And a bird apparently flew into the path of the transmission and the bird just fell like a brick, as if it died instantly.
Many people speculated that it was a hoax or, if not, it was at least very dangerous.
The story goes further that when he died, the Gov't confiscated his papers. US Scientists looked everything over and concluded it to be impossible.
Then, during the cold war, US Spy imagery showed a huge complex being built in a remote location in the USSR. The military had trouble figuring out what it was. Eventually a Gov't scientist familiar w/ the Tesla work had the 'aha moment' and he pulled-out the tesla papers and sure enough, it seemed as though the Soviets were building an energy weapon of some sort.
Again, IIRC, they never were able to make it work, which is why it's not famous and in school books. But it is interesting that they TRIED and I'd love to read about that project.
(Heard all this about a year ago on a radio program by either NPR or PRI)
You don't HAVE to use XML for RPC requests. Heck, the XmlHttpRequest object doesn't even force you to use XML.
JSON is a much more concise RPC vehicle.
Further, HTTP isn't SUCH a bad RPC protocol. It's remarkably light-weight. HTTP Headers can be a little as 2 lines of text. And a lot of RPC functionality that doesn't involve sending or receiving much data (for example, marking a message as Read in Gmail) you can use a simple HEAD request instead of GET or POST and use the HTTP Status code to determine success/failure in your browser.
A binary protocol would be faster. No doubt about it. But if a dev understands HTTP and uses JSON, it can be pretty speedy.
You're clearly no engineer.
If you were, you'd realize that all we need to do is starve them for a few months and, bam, double the capacity for hurtling lawyers into space.
...that I think is most important:
Olympic level competition is more a JOB than a sport.
And many countries, China among them, would have no compunction about working a child mercilessly if she shows talent and the ability to gain her nation the prestige of a gold medal.
It's not, IMO, as much about unfair competition. It's about having standards as a modern society that a person should have free will and children should be protected from exploitation. The cutoff has to be made somewhere, and right now that cutoff is 15.
You're right about those last 2. I make my devs code PHP at E_NOTICE so they can initialize variables before reading/appending them. It would be nice if there was a strict mode that could raise those errs as an E_WARNING instead of E_NOTICE.
And you're totally right about scoping issues w/ $this.
We have a company-wide template in Zend studio called 'thischk' that we put at the top of any non-static method. It checks that $this is an instanceof whatever the current class is, or else it throws an exception.
(That is, the template uses a variable so when the template is inserted into the code it's replaced by the actual name of the class. Important because the __class__ magic variable has the same scoping problem)
Lumping PHP & Perl together is incorrect. For one, PHP is finally approaching consideration as a "modern" language. It's still being improved upon. And while there's a lot of bad PHP, there's also a lot of bad Java.
Java is right for large applications. For small apps, it's over-engineered. It guides a dev into a multi-tiered architecture. This is good, except when it's overkill.
The secret to being a good dev, with highly marketable skills is simple:
Pick one language from each group:
Group A:
Java, C#, Obj-C
Group B:
Python, Ruby, PHP
Group C:
Perl, VBScript
Obviously this depends on the technology stack at any given company. But if you're a dev that brings:
Java, Python, and Perl
or
C#, PHP and VBScript
or
Obj-c, Ruby, and Perl,
etc, etc, etc
then you're going to be a valuable team member and you're going to have no trouble finding work.
Of course, the judgment to know when to use each is also very important.
C++ is still around for a reason. There are whole classes of problems that simply cannot be solved using the higher level languages you're used to.
Anyone that's ever used C++ for more than the required chapter in school would probably agree that it's not a language for dabblers.
That is, if you want to get GOOD at C++, you need to use it regularly. You need to get GOOD at it. When you do, you learn how to avoid the most painful/tedious parts. You have easily accessible things in your toolbox, like a solid string class that you understand well.
And you learn to avoid things like MFC where they're not needed.
And more than anything, a good C++ developer knows that his language can do anything, and faster, than a higher level language. Device drivers. OS Kernels. Things like that.
I'm no longer a FT C++ dev, but I did it for a long time. The ability to create and boot your very own OS is so, so worth the investment you make in the language.
I'd never create a CRUD app in C++ because I can't see any reason I'd need to. But I could if I wanted to. And that's something that, say, a Ruby or PHP developer couldn't say (That they could build ANYTHING they wantetd to).
And, really, if you think PHP is a "nasty hack" then you seem to me to be trading only in cliches here.
I'm not a huge fan of PHP, but it's a modern language. It's library is ugly. It lacks naming conventions. But its actual code-base is really quite good. If you want to see some well done C++ code, check out the PHP internals. It's made a lot of progress in the last 5-7 years.
Yes, it is.
It's like saying "Most Basic & VB Code is Verbose, is it really fair to blame the language?"
YES!!
Every language has a unique idiom. And the best languages use this idiom to painlessly guide the developer to best practices.
For exammple, lots of devs consider Java to be over-engineered and overly-complex. You've probably heard a dev talk about building something in, say, RoR in a week that would've taken 4 weeks in Java.
That's probably true, because Java is a tool best designed for large applications and when you're using Java, it's idiom guides you into building multi-tiered architecture.
Python's idiom guides devs into producing well formatted code and it's a great language for web apps because it puts powerful data structures right in the developers face.
C# is a FANTASTIC language for teaching OOD to procedural developers. It's HARD for a procedural developer to think in terms of object hierarchies. The mechanics are easy to pick up. The ability to deconstruct a problem into an object hierarchy is hard.
But you put them in front of a new project in C# and the language -- entirely OO itself -- just guides a developer to the right thing. It's very hard to shoe-horn a procedural architecture into an OO-only language.
JavaScript makes it insanely easy to create an event-driven application. Anonymous functions, LAMBDAs, etc, guide a developer into producing code in an event/event-handler model.
Any developer can do nearly anything with any language. But a language itself can make it easy and obvious when you're doing things right, and painful for you when you're doing them wrong. And a good IDE will reinforce both of these behaviors.
Come on... you act like using a descriptive variable name is some huge overhead that gums up the works.
And to answer your question.. a project manager has to think in terms of TCO. Most systems live long lives. Maintenance, upgrade and troubleshooting WILL happen. And if you can spend dimes now to save dollars tomorrow, it's a wise business decision to do so.
Oh, please.
First, let me ask, are you a professional software developer or project manager? (I'm not being arrogant, I'm just curious).
I've got more than a few years under my belt.
A developer gets a spec. He designs a solution and quotes the spec. Assuming he's given the green light, he schedules the projects start date and sets some milestones.
I've worked for DOZENS of companies, large and small, in all economic sectors, as both a contractor and a FTE, and invariably it's some variation on this theme.
The developer designs a solution and sets the schedule.
"Deliverables" means nothing more than the developer hitting the milestones/delivering the artifacts that he set for himself.
In smaller projects, this could be the entire application. In large projects, it's just a single function point.
You can bash the vernacular of the business all you want, but you don't offer any better solution.
If I'm being paid $50/hr to tap a keyboard, shouldn't I be held accountable for results?
Fair enough.
But if you've ever actually worked in a large business and you use just a slight amount of common sense, you'd understand what the GP meant.
Most likely they're pulling data from access to Excel. And really, Access is most likely just being used as a front end for an Oracle, DB2, or MSSQL database.
I've seen countless systems designed like this.
Most of the code in most of those applications has been written by large companies who pay developers to write the OSS software.
They do this because they think it gives them a competitive advantage and/or goodwill.
Do we really want textbooks written by corporations who hope to gain a competitive advantage?
The fact that you've got a horrible sys admin for your exchange server says a lot more about your company than it does about Microsoft and Exchange.
Fact is a lot of companies are running exchange w/ very little downtime at all.
Oh, the keyboard.
How quaint.
What is this "80s" you speak of?
Some sort of code?
Well, you got 1/2 of it right.
They then compared peoples reactions to the self-reported personality types of the people who submitted their email addresses to the researchers.
And, as it turns out, they found correlation on each of their metrics, the only exception being "extroversion."
i. your comment is a textbook strawman. But..
ii. it couldn't really be slavery if I'm selling MYSELF (and thus getting the proceeds myself). It's more like contract labor. Besides..
iii. That isn't a labor law, which is clearly the meaning behind "I don't need the government telling me how I can work".
I've honestly been dreaming of building this system since I was 9 years old.
I'm in my late 20's now, so needless to say, I've given it a lot of thought.
Implementing an autodrive system like this on city streets is at least an order of magnitude more difficult than it will be on limited access highways.
And while GPS is very helpful, I really don't think we can rely on a system like this, placing millions of lives every day into its hands, based soley on GPS. I think the road will need to be embedded with RFID posts of some sort. They can be built into the 1/4 mile markers or something, and they could be highly redundant so many could fail, and GPS would certainly be used, just not exclusively.
This is compounded by the transition period where "manual" cars will rule the roads.
So we'd start by picking high-throughput commuter routes. Think of the beltways that exist in most major cities.
The left-most lane becomes the autodrive lane. Over the years, it turns into an exclusively autodrive highway.
So these first autodrive cars will have to be "hybrids."
After 20, 30 years when (literally) every car on the road is autodrive capable, that's when you'd see large rollouts of autodrive on city streets.
This is also a much more difficult issue because of pedestrians.
So my thinking is that people would get used to carrying an RFID transmitter with them. This would serve as their car key when they get in their own car, and it would also serve as a transponder when you're on foot. So if you're standing at a corner waiting to cross the street, the cars 2 blocks away know you're there and you'll be figured in to the traffic flow.
And I really think that a P2P system is the only way to do this. But I also think that we'd need large, distributed traffic analysis and monitoring systems that are capable of watching for malfunctioning or hacked autodrivers.
I'm sorry for writing so much, but I love this shit.
Anyway, one final thought, is that autodrivers would go into defensive mode when they detect a manually driven car or a pedestrian. I imagine a convoy of autodrivers in the autodrive lane on a highway, they're cruising at 70mph and a manually driven car enters the highway and is in the lane beside the autodrivers.
I imagine the software switching into a defensive mode, all of the autodrive cars in the, say, 1/2 mile radius is aware of the manual car, and they perform a monte carlo analysis of thousands of possible evasive scenarios, any one of which could be activated in microseconds if the manually driven car enters the autodrive lane, swerves, crashes, etc.
And I'm sure the occupants of the vehicles would be alerted that defensive mode is in use.
And about speed... a system like this, no doubt, would be safe at very high speeds. But until we figure out how to do so efficiently it would be such a waste.
And as long as manually driven cars are allowed on the highways, you'd need to keep it going slower just to be safe.
I'm not sure where you live, but the tech market for software developers seems pretty strong right now.
I've got 6 years experience. I'm writing this from a private office in the Triangle where I'm paid about $85k. I like my job just fine.
Tomorrow evening I'm being flown to Sarasota for an interview for a company who called me and threw-out a 110-120k range.
I started my career as a developer in the immediate aftermath of the .com burst. THAT was a bad market. This is peaches and cream.
I'm not sure what kind of family you come from, but $60k TODAY is pretty good cash if you're not living on a coast.
It's not really an either/or.
You can be a salaried employee who is paid for OT.
And really, I don't need the government telling me how I can work. I'm a grown man. If I want to work for salary w/o OT, that's my call.