I think most people who become famous have that possibility in the back of their head the whole time, and it guides their decisions. C'mon, girls, toss your upbringing aside and work on those egomaniacal fantasies!
that just isn't achievable with all the carriers competing for the same markets and without any kind of central planning.
Obviously a great deal of regulation and planning would be required to set up the market. What pieces of spectrum are sold, and what limitations are the winning bidders required to abide by, in terms of what services they offer?
In areas where there is a need for coverage, but no profitable way to provide it, let government sweeten the deal enough to make it profitable. As long as the spectrum auctions are open and competitive, there shouldn't be any way for a company to get sweetheart contracts and milk the taxpayers.
Having local government subsidize wireless service in places where it's unprofitable would stop the de facto welfare system whereby rural cell coverage is funded by urban subscribers, but if we really want such a welfare system, we can vote on it;-)
Regulation doesn't have to mean monopoly. Right now, small providers get squeezed out because everybody wants a cheap cell contract that works everywhere. The more spectrum you control in more places, the better and cheaper service you can provide, thus supporting your brand and gaining more national market share.
If local wireless coverage is only a simple service sold as a commodity, with no consumer-visible branding, then (hopefully) the economic value of the spectrum will depend on how efficiently the service provider can use it. The highest bidder for spectrum will tend to be the most efficient service provider, whether it's AT&T or Mom and Pop.
Of course, QoS will have to be part of the deal negotiated by your phone on your behalf, to prevent a race to the bottom in terms of quality.
communications networks, like other societal infrastructure, are natural monopolies. that's the way in which they function the most efficiently.
I disagree. Unlike roads, wireless communications networks are not physically mutually exclusive: multiple networks can operate in the same physical space. Unlike phone and sewage lines, it's easy to redistribute capacity among individual consumers: an individual doesn't have just one line that must be operated by one company.
Wireless communications are perfect for competition, because all an operator needs to do is rent some frequencies, set up a tower, and make sure it can negotiate with phones and route traffic to the rest of the phone network.
There are two problems: fraud and privacy. Fraud might be solvable, and I sure as hell don't trust AT&T or Verizon privacy-wise, so how could things get worse on that front?
Totally off-topic, but it sounds like a nice simple plugin architecture to me, nothing to be ashamed of. It's easy enough to understand (though I didn't realize you can find inner classes using reflection): all inner classes in class Foo implementing interface Command are instantiated and registered as commands. Any decent Java programmer should have no problem inheriting the code from you, assuming you put that one-sentence explanation in the class documentation for the class containing the command classes.
It's not surprising that live code replace didn't work, but that's hardly a significant issue. The biggest issue I see is having a bunch of code in a single huge source file, which is stylistically bad when coding in Java. For that reason, it would have been better to rely on explicit registration of commands, but it should be easy to refactor to that.
Larman's "Applying UML and Patterns" is a good introduction to object oriented programming.
Dangerous advice. You should ignore anything until you understand the need for it. There are too many software engineering methods that sound like really good ideas but must be applied judiciously because they're only worthwhile under certain circumstances. If there's a Dark Side to the art of programming, it's the way of Impressiveness: using techniques that sound progressive and responsible, without thinking hard about their true cost and true value.
UML is a great example of something that is presented as a Good Thing that programmers never use enough of, just like kids never eat enough broccoli. In reality, there's a proper amount of UML to use on every project, and on most projects it's zero. (And in reality, you really don't want to sit near a guy who eats a pound of broccoli a day.) Teaching UML in an introductory OO book is irresponsible -- the value of UML only emerges in circumstances that the readers can't appreciate yet, so you have to lie to them about its domain of usefulness.
Design patterns are a borderline case. I wouldn't recommend them for a brand-new coder, but if you're already experienced, you'll understand the need for some of them right away. Others might be a mystery for years until you see, in a real life project, a situation where they apply. Just don't be the guy who adds Visitor patterns and Mediator patterns in places where they don't make sense and don't contribute anything to the subsequent evolution of the code.
Read all you want, but be somewhat closed-minded and only use things that you really understand the need for.
A great book if you know C++ is The C++ Programming Language. Stroustrup talks about the cost of everything and warns against misusing language features. He's a great person to absorb your programming philosophy from, because he teaches that every language feature and programming technique ever invented can be counterproductive in the wrong context.
You should expect this from every author, and when you sense that an author is taking a one-sided approach to his subject matter, advocating something or trying to get you excited about it instead of explaining when it is good and when it is bad, then you should put it down and avoid polluting your brain.
Incidentally, this means you will have to be very selective when reading about Java,.NET, or any other technology where people are trying to drive adoption. Enterprise technologies are especially problematic because the best technical publications often come from vendors or consultants, but you have to be extremely skeptical when consuming those publications because they are designed to give you a somewhat-less-than-objective enthusiasm.
With some technologies (*cough* Microsoft *cough*) boosterism has become the customary writing style, even among people who have no financial stake in the technology. Some readers expect an injection of enthusiasm every time they pick up a book. Don't be a sucker -- those guys are clowns, and everyone hates working with them.
I've worked on code with blocks that size that were not documented as you describe. Finding the corresponding start or end of a block was a big pain in the ass. And you know what? It was a trivial pain in the ass next to the problem of tracing through those garguantuan loops. I document ends of classes and namespaces (}// class Foo) just for convenience, but if you need to document if, for, and while blocks that way, then the code needs to be rewritten. If you have a hundred big loops, then it's better use of time to rewrite one of them than to document all of them.
There's a famous epigram (hopefully someone can provide it) to the effect that it's twice as hard to read code as to write it, so if you write your code as cleverly as possible, you will most certainly be unable to read it.
If you're proud of a clever solution and can't wait to show it off, then it's an unsatisfactory solution. The best solution to a difficult problem is the one that is so clear that after reading it, nobody can comprehend that the problem presented any difficulty in the first place. The sign of a really great programmer is that he never gets stuck with any difficult projects. Everything assigned to him turns out to have a simple, easy solution -- what luck!
I found myself using the ternary operator in a proof for a set theory class. It saved me so much verbiage that I retained it when I presented the proof to the class. I just explained what it meant and used it -- no one was the slightest bit confused despite never having seen it before. I remember seeing it used a few times by other people later in the semester, even though their only exposure to it was my fifteen minutes at the chalkboard. So it isn't that counterintuitive, at least not to logic-oriented people like programmers and mathematicians.
And anyone should feel free to use IN CODE something that makes sense to programmers, regardless of whether it makes sense to "normal" human beings. The bad reputation of:? is entirely due to the confusion caused when a programmer fails to realize it's an operator -- a mistake he will only make once, at most, in his entire career.
Clean code can be high performing, but most of the time, high performing code is not clean. Look at encryption algorithms. Look at Qt's premoc compiler. The nature of performance in code is inherently low-level.
Quite the opposite. High-level factors determine performance to within a scaling factor. Only after you get the high-level structure right does it make sense to optimize at lower levels, and then you can usually limit the optimizations to a few hot spots in the code. (There are well-known exceptions to the rule that most of your execution time is spent in a small minority of code, and compilers are usually exceptions, so your point about premoc stands, but most code isn't like that.)
Most preformance related code makes use of multiple calls in a single function to ensure that the scope usage is as short as possible. I wouldn't call 20 functions in one line of code readable. How do most people make it readable? Separate function return values into variables causing the variable to live in the entirety of its parentÃ(TM)s scope.
I'm not sure exactly what you're talking about, but any decent compiler will happily reuse registers containing data that will not be used again, regardless of whether the objects are in scope are not. You only have to worry about scope if the objects have nontrivial destructors.
Also, you don't have to use a function or a single line to create a scope; you can use curly braces. You can't have written much C++ code without knowing that, because that's often the only readable way to be precise about RAII resource scopes. It sounds like you're getting way too fancy for your own good and writing "optimized" code in a language you don't understand.
Re:This should come naturally but...
on
Clean Code
·
· Score: 1
Who in a classroom can teach students to write clean code? Being taught by a typical TA is the equivalent of being taught by a guy with less than one year of industry experience. When it comes to coding style, they should be learning, not teaching. Most professors aren't any better.
I'm not sure it can be taught anyway. Just like writing in a natural language, you learn what good and bad code is by reading it, especially your own.
Re:I really want a copy of this...
on
Clean Code
·
· Score: 1
Don't assume the guys running around in fancy suits are the only ones making money. In honest-to-goodness dirty-hands engineering fields, many of the millionaires are middle-aged engineers who decided that entrepreneurship sounded like more fun than retirement. Those guys need software too; it isn't just banks and insurance companies that hire programmers. And no, they don't have to go out and buy a bunch of fancy suits or go to Tony Robbins seminars in order to become "businessmen." They're the same nerdy guys they've always been, living out their childhood dreams of playing with dangerous chemicals and humongous machines. They were already accustomed to being trusted with large sums of money, and they were already acquainted with the people who handed it out, so they didn't feel like they had to acquire a new wardrobe to mark the occasion.
I'm probably not going to end up rich like them, but it isn't because of how I dress. It's because their decades of technical experience are more economically valuable than mine will ever be.
T-shirt: not to a job interview, but I usually don't know when I'm about to meet a future boss, so check.
Yahoo email address: check, though these days it's Gmail.
Consistent employment doing the work I want: check.
The people who hire me are middle-aged engineers who moved into management and entrepreneurship and who still dress like engineering dorks. Their generation of engineers tends to wear short-sleeved button-downs and blue jeans, which were possibly even *more* dorky and less professional in the context of the '70s and '80s than t-shirts are today. So they sympathize.
One guy gave me a business with his phone number and email address handwritten on the back because the ones on the front of the card were five years out of date. He had written his new contact info onto a whole stack of old cards, apparently because he was too cheap to order new ones.
Fitting in with the values and social expectations of the people who hire me: check.
I have to disagree with "childish," unless the poster works in IT himself. Most people, even in computing, do work that has nothing to do with managing domains and email servers. When someone hires a consultant to write Java middleware, or write Flash games, or port Fortran code to C++, or help a company move to a distributed build system, they don't give a damn whether he receives mail at his own domain. It has nothing to do with his job.
Setting up and administering your own domain is an IT hobby that people outside of IT (including most professional programmers) have little appreciation for. To them, it's like the difference between sewing your own clothes and buying them in a store. Sounds like a lot of work -- who would bother unless it was a hobby they enjoyed?
It's apparently hit and miss. Some people report everything working automatically, but Gutsy and Hardy didn't handle either of my Fuji Finepix cameras. They aren't even recognized as cameras. Even when I open the camera app, choose exactly the right model, and ask the app to find the camera, it can't see it. So I'm stuck using Windows to manage my photographs.
I remember when C/C++/ASM programming was fun to hack, until the age of monolithic libraries like MFC and OWL (and now things like the JDK and.Net) came and ruined that fun by restricting your freedom.
How do libraries and application frameworks restrict your freedom? Your boss makes you use them? Sorry, I don't follow your argument at all. If you want to write your own socket library, regular expressions library, and logging framework, go ahead and do it. Nobody's stopping you.
If modern amenities have made you bored with programming, I suggest attacking a problem domain that hasn't yet been made trivially easy. Get a four-core box and convert a single-threaded application into one that uses all four cores efficiently. That's something that Java and.NET won't solve for you. Whenever one problem is rendered trivial by Moore's law or by some helpful library author, there is always a bigger problem to tackle.
I use Eclipse on Ubuntu installed straight from eclipse.org, and I have the same nagging problem with corrupted workspaces. If the OP googles around, he can find some tips for fixing a corrupted workspace, such as by deleting specific directories out of it. You still lose a lot of state, including all your preferences. Sometimes you lose everything except your projects, which is almost as bad as rebuilding the whole workspace.
I use Eclipse 3.3 (Europa), the RCP download. I haven't heard that 3.4 has any stability improvements over 3.3, but I plan on upgrading anyway because headless builds have supposedly been greatly simplified -- *wonderful* news for those of use who still shamefacedly use the application export wizard because we can't take a week off to figure out the Eclipse build system.
P.S. Despite these complaints, I'm happy using Eclipse for my RCP app and would still pick Eclipse if I had the choice over again.
SGI's STL site is excellent, though I'm not not sure how up-to-date it is.
The C++ Programming Language, by Bjarne Stroustrup, is the only essential and authoritative language reference, other than the standard itself. It isn't a web site, but programming in C++ isn't something you pick up on a whim.
And of course Boost, the first place to look when you think, "There should be a library for this."
Re:Presentation versus inside guts
on
Tech Vs. Business?
·
· Score: 2, Interesting
In my experience there can be a persistent problem where sales guys have no understanding of the product or service they're supposed to sell. Their managers know it, the engineering managers know it, executives know it, but the situation is tolerated and the sales guys are expected to keep on selling. Don't ask me why, but I've seen people tolerate that state of affairs for years as if there were no cure for it.
Quantitative techniques in business
on
Tech Vs. Business?
·
· Score: 5, Insightful
In my experience the biggest driver of tech's disdain for business is the farcical nature of some managers' attempts at quantifying certain aspects of their business.
All businesses manage to quantify a few things extremely well -- payroll, revenue, taxes, and so forth. There are many other things that can be quantified in a useful way. However, many business types engage in persistent fantasies about quantifying things like programmer productivity, ROI on buying software tools, and the effect of different business methodologies. Quantifying things is an excellent idea, but it's so overwhelmingly difficult to measure things like management productivity and (God help us all) "project velocity" that 98.6% of all attempts to do so are essentially fraudulent -- just as dishonest as if I pretended that number I just read off my rectal thermometer had any meaning more precise than "most."
Engineers are likely to feel a little twitchy just looking at the number "98.6" because they associate it with the classic overprecise and somewhat incorrect statement that normal body temperature is 98.6 degrees fahrenheit. If that number annoys us, what do you think we feel like when some business type says we should use Scrum because 87% of all enterprise-scale software projects come in 50% over budget, while only 63% of Scrum projects come in 50% over budget? Whenever engineers and business types speak in a common language (mathematics, logic, statistics, controlled studies) it turns out that the business types come off as STUPID, GULLIBLE, OVERCONFIDENT, AND FULL OF SHIT.
Which is not to say that business types are stupid. There are honest and intelligent managers who aspire to quantitative precision and may work very hard at it, but they don't go around waving numbers and graphs because they know the results are extremely difficult to interpret -- more "food for thought" than "results." The guys who make a big deal out of numbers like the ones in the last paragraph are either con artists or victims of con artists. They think that making quantitatively precise comparisons of programming methodologies is a strategic managerial decision that you implement by repeating numbers you read in [blog summaries of] management journals, just like creativity is a lifestyle choice that you implement by your choice of haircut, clothing, and a certain brand of digital accessories. It never crosses their mind that it might be something intrinsically difficult that you can work really hard at without ever producing anything worth sharing -- that's how poorly they understand it.
But it always seems like it's the guys who make up bullshit numbers who write the papers, run the consultancies, get the attention of upper management, and get put in charge of things they don't understand. Business types may have enough patience and faith in management to sit back and watch the pretenders rise meteorically and flame out, but engineers are used to calling bullshit on bullshit when numbers are involved.
Anyway, I could go on, but you get the picture. Engineers accept that not everything can be quantified, and every business decision must, of necessity, rely heavily on guesswork, folklore, and intuition in addition to hard numbers. We can't accept that the business world is full of people who pretend otherwise, without any reasonable justification, and somehow escape being laughed at by their supervisors and peers.
If you think the media player and web browser are "PDA features" then we have a semantic disagreement that can't be settled by argument.
Anyway, before I get into that, I did just get an iPhone (between my post and your reply) and it's spiffy:-) Since you have a such strong interest in the iPhone, I'm sure you're curious about my experience. In the week I've had it, I've had no dropped calls (knock on wood) and 3G reception everywhere in town. The 3G reception is always displayed at one bar, which is a bit disappointing since I'm in a major city, but it never disappears completely unless I go out of town. So far I have declined to let iTunes update the firmware and will continue to decline until I'm confident that Apple has figured out the 3G issues.
Battery life isn't an issue for me because I've been in the habit of recharging my phone almost every night, ever since I got my first cell phone. The iPhone doesn't last two full days if I make heavy use of the camera or media player, but recharging has never been a problem for me -- between the wall plug, USB plug, and car charger, I'm covered unless I'm backpacking, in which case I always turn my phone off completely. The iPhone has never had a problem lasting all day, even though I've been playing with it a lot since I bought it.
Back to the categorization: I guess my best argument that iPhones are in a different market segment from Blackberries and Windows Mobile devices is that the overlap in ownership is almost entirely in tech-industry people. The vast majority of iPhones and Blackberries are sold to people other than programmers, IT folks, and tech executives, but those are the only folks who seem to seriously consider both kinds of devices. When iPhones get better at Exchange integration and can sync with your Outlook calendar, I suppose there will be a category of young, fashion-sensitive business types who would consider both kinds of devices.
From my personal point of view, I never felt like they were the same kind of device. Blackberries have no appeal for me; I don't do a lot of email or instant messaging and don't want half my device to be dedicated to a keyboard. To me, the most attractive alternatives to the iPhone were stylus-based Windows Mobile phones with slide-away keyboards. Before I bought the iPhone, I paid a lot of attention to my colleagues when they were using their Windows Mobile devices and iPhones. Stylus systems have always disappointed me, and after watching people use Windows Mobile stylus systems, I've come to believe that this is due to the inherent physical inconvenience, not just bad implementations. The Windows Mobile devices seemed better prepared to scale up to arbitrary levels of complexity and to accomodate desktop apps with less adaptation required. I probably would have bought a Windows Mobile device if I wanted to run third-party applications or spend a lot of time intently using complex business applications. For that kind of focused, sustained usage, the stylus makes sense. I thought of Windows Mobile as being a good platform for someone who wants his phone to be as close as possible to having a full PC in his pocket. Obviously the iPhone is pretty candy-assed if that's what you want, so in my mind the iPhone doesn't compete in that category.
I was equally convinced by my observations that Windows Mobile devices don't compete with the iPhone when it comes to doing the handful of core tasks that are built into the iPhone. The first time I watched someone using Safari on the iPhone, it was a revelation. You can pull the iPhone out of your pocket, perform a simple task, and not feel like the device has imposed a lot of overhead on you. I never felt that way with a stylus, and the touch-screen systems I've seen (other than the iPhone) were so clunky I wished I could use a 10-digit keypad instead. I have to admit that the iPhone is more sluggish than I'd like, but not enough to piss me off. If you want to let your tech-illiterate friend browse your music or
Is the imap server not handling that practice efficiently? "Bad imap server", *not* "bad user".
May God grant you long life and free beer. A successful approach to supporting applications at the filesystem level will make it much easier to write scripts that manipulate application data. Just eyeball the data stored in the filesystem using standard filesystem tools, write a script that manipulates it, again using standard filesystem tools, and voila -- no hidden metadata to find, parse, and massage to get things to work.
Linux nerds like scripting and command-line work, but occasionally we also like big, integrated applications. When big, integrated applications can't use the filesystem in a straightforward way, they develop complex, inscrutable storage solutions that can't be directly manipulated by casual usernerds.
The biggest "problems" with Javascript are the browser inconsistencies and the fact that it is used by web designers, who don't write code to the tastes and standards of software developers. Neither of these has anything to do with Javascript.
The first is a problem of power and economics. You can't force the standardization of browser APIs just by announcing a new language or extending an old one.
The second isn't a problem, except in the heads of software developers. If we stop web developers from writing "crappy" Javascript code, then meaningful, user-visible functionality will take a nose dive. "Real" software developers don't really want to write client-side web UI code, they just want to stop the web designers from doing it. Result: nothing gets done, everything sucks.
Slashdot Mirror
I think most people who become famous have that possibility in the back of their head the whole time, and it guides their decisions. C'mon, girls, toss your upbringing aside and work on those egomaniacal fantasies!
Obviously a great deal of regulation and planning would be required to set up the market. What pieces of spectrum are sold, and what limitations are the winning bidders required to abide by, in terms of what services they offer?
In areas where there is a need for coverage, but no profitable way to provide it, let government sweeten the deal enough to make it profitable. As long as the spectrum auctions are open and competitive, there shouldn't be any way for a company to get sweetheart contracts and milk the taxpayers.
Having local government subsidize wireless service in places where it's unprofitable would stop the de facto welfare system whereby rural cell coverage is funded by urban subscribers, but if we really want such a welfare system, we can vote on it ;-)
Regulation doesn't have to mean monopoly. Right now, small providers get squeezed out because everybody wants a cheap cell contract that works everywhere. The more spectrum you control in more places, the better and cheaper service you can provide, thus supporting your brand and gaining more national market share.
If local wireless coverage is only a simple service sold as a commodity, with no consumer-visible branding, then (hopefully) the economic value of the spectrum will depend on how efficiently the service provider can use it. The highest bidder for spectrum will tend to be the most efficient service provider, whether it's AT&T or Mom and Pop.
Of course, QoS will have to be part of the deal negotiated by your phone on your behalf, to prevent a race to the bottom in terms of quality.
I disagree. Unlike roads, wireless communications networks are not physically mutually exclusive: multiple networks can operate in the same physical space. Unlike phone and sewage lines, it's easy to redistribute capacity among individual consumers: an individual doesn't have just one line that must be operated by one company.
Wireless communications are perfect for competition, because all an operator needs to do is rent some frequencies, set up a tower, and make sure it can negotiate with phones and route traffic to the rest of the phone network.
There are two problems: fraud and privacy. Fraud might be solvable, and I sure as hell don't trust AT&T or Verizon privacy-wise, so how could things get worse on that front?
Totally off-topic, but it sounds like a nice simple plugin architecture to me, nothing to be ashamed of. It's easy enough to understand (though I didn't realize you can find inner classes using reflection): all inner classes in class Foo implementing interface Command are instantiated and registered as commands. Any decent Java programmer should have no problem inheriting the code from you, assuming you put that one-sentence explanation in the class documentation for the class containing the command classes.
It's not surprising that live code replace didn't work, but that's hardly a significant issue. The biggest issue I see is having a bunch of code in a single huge source file, which is stylistically bad when coding in Java. For that reason, it would have been better to rely on explicit registration of commands, but it should be easy to refactor to that.
Dangerous advice. You should ignore anything until you understand the need for it. There are too many software engineering methods that sound like really good ideas but must be applied judiciously because they're only worthwhile under certain circumstances. If there's a Dark Side to the art of programming, it's the way of Impressiveness: using techniques that sound progressive and responsible, without thinking hard about their true cost and true value.
UML is a great example of something that is presented as a Good Thing that programmers never use enough of, just like kids never eat enough broccoli. In reality, there's a proper amount of UML to use on every project, and on most projects it's zero. (And in reality, you really don't want to sit near a guy who eats a pound of broccoli a day.) Teaching UML in an introductory OO book is irresponsible -- the value of UML only emerges in circumstances that the readers can't appreciate yet, so you have to lie to them about its domain of usefulness.
Design patterns are a borderline case. I wouldn't recommend them for a brand-new coder, but if you're already experienced, you'll understand the need for some of them right away. Others might be a mystery for years until you see, in a real life project, a situation where they apply. Just don't be the guy who adds Visitor patterns and Mediator patterns in places where they don't make sense and don't contribute anything to the subsequent evolution of the code.
Read all you want, but be somewhat closed-minded and only use things that you really understand the need for.
A great book if you know C++ is The C++ Programming Language . Stroustrup talks about the cost of everything and warns against misusing language features. He's a great person to absorb your programming philosophy from, because he teaches that every language feature and programming technique ever invented can be counterproductive in the wrong context.
You should expect this from every author, and when you sense that an author is taking a one-sided approach to his subject matter, advocating something or trying to get you excited about it instead of explaining when it is good and when it is bad, then you should put it down and avoid polluting your brain.
Incidentally, this means you will have to be very selective when reading about Java, .NET, or any other technology where people are trying to drive adoption. Enterprise technologies are especially problematic because the best technical publications often come from vendors or consultants, but you have to be extremely skeptical when consuming those publications because they are designed to give you a somewhat-less-than-objective enthusiasm.
With some technologies (*cough* Microsoft *cough*) boosterism has become the customary writing style, even among people who have no financial stake in the technology. Some readers expect an injection of enthusiasm every time they pick up a book. Don't be a sucker -- those guys are clowns, and everyone hates working with them.
I've worked on code with blocks that size that were not documented as you describe. Finding the corresponding start or end of a block was a big pain in the ass. And you know what? It was a trivial pain in the ass next to the problem of tracing through those garguantuan loops. I document ends of classes and namespaces (} // class Foo) just for convenience, but if you need to document if, for, and while blocks that way, then the code needs to be rewritten. If you have a hundred big loops, then it's better use of time to rewrite one of them than to document all of them.
You missed one.
There's a famous epigram (hopefully someone can provide it) to the effect that it's twice as hard to read code as to write it, so if you write your code as cleverly as possible, you will most certainly be unable to read it.
If you're proud of a clever solution and can't wait to show it off, then it's an unsatisfactory solution. The best solution to a difficult problem is the one that is so clear that after reading it, nobody can comprehend that the problem presented any difficulty in the first place. The sign of a really great programmer is that he never gets stuck with any difficult projects. Everything assigned to him turns out to have a simple, easy solution -- what luck!
I found myself using the ternary operator in a proof for a set theory class. It saved me so much verbiage that I retained it when I presented the proof to the class. I just explained what it meant and used it -- no one was the slightest bit confused despite never having seen it before. I remember seeing it used a few times by other people later in the semester, even though their only exposure to it was my fifteen minutes at the chalkboard. So it isn't that counterintuitive, at least not to logic-oriented people like programmers and mathematicians.
And anyone should feel free to use IN CODE something that makes sense to programmers, regardless of whether it makes sense to "normal" human beings. The bad reputation of :? is entirely due to the confusion caused when a programmer fails to realize it's an operator -- a mistake he will only make once, at most, in his entire career.
Quite the opposite. High-level factors determine performance to within a scaling factor. Only after you get the high-level structure right does it make sense to optimize at lower levels, and then you can usually limit the optimizations to a few hot spots in the code. (There are well-known exceptions to the rule that most of your execution time is spent in a small minority of code, and compilers are usually exceptions, so your point about premoc stands, but most code isn't like that.)
I'm not sure exactly what you're talking about, but any decent compiler will happily reuse registers containing data that will not be used again, regardless of whether the objects are in scope are not. You only have to worry about scope if the objects have nontrivial destructors.
Also, you don't have to use a function or a single line to create a scope; you can use curly braces. You can't have written much C++ code without knowing that, because that's often the only readable way to be precise about RAII resource scopes. It sounds like you're getting way too fancy for your own good and writing "optimized" code in a language you don't understand.
Who in a classroom can teach students to write clean code? Being taught by a typical TA is the equivalent of being taught by a guy with less than one year of industry experience. When it comes to coding style, they should be learning, not teaching. Most professors aren't any better.
I'm not sure it can be taught anyway. Just like writing in a natural language, you learn what good and bad code is by reading it, especially your own.
Make up symbols? How do I type the "lipstick"?
Don't assume the guys running around in fancy suits are the only ones making money. In honest-to-goodness dirty-hands engineering fields, many of the millionaires are middle-aged engineers who decided that entrepreneurship sounded like more fun than retirement. Those guys need software too; it isn't just banks and insurance companies that hire programmers. And no, they don't have to go out and buy a bunch of fancy suits or go to Tony Robbins seminars in order to become "businessmen." They're the same nerdy guys they've always been, living out their childhood dreams of playing with dangerous chemicals and humongous machines. They were already accustomed to being trusted with large sums of money, and they were already acquainted with the people who handed it out, so they didn't feel like they had to acquire a new wardrobe to mark the occasion.
I'm probably not going to end up rich like them, but it isn't because of how I dress. It's because their decades of technical experience are more economically valuable than mine will ever be.
No business cards: check.
T-shirt: not to a job interview, but I usually don't know when I'm about to meet a future boss, so check.
Yahoo email address: check, though these days it's Gmail.
Consistent employment doing the work I want: check.
The people who hire me are middle-aged engineers who moved into management and entrepreneurship and who still dress like engineering dorks. Their generation of engineers tends to wear short-sleeved button-downs and blue jeans, which were possibly even *more* dorky and less professional in the context of the '70s and '80s than t-shirts are today. So they sympathize.
One guy gave me a business with his phone number and email address handwritten on the back because the ones on the front of the card were five years out of date. He had written his new contact info onto a whole stack of old cards, apparently because he was too cheap to order new ones.
Fitting in with the values and social expectations of the people who hire me: check.
I have to disagree with "childish," unless the poster works in IT himself. Most people, even in computing, do work that has nothing to do with managing domains and email servers. When someone hires a consultant to write Java middleware, or write Flash games, or port Fortran code to C++, or help a company move to a distributed build system, they don't give a damn whether he receives mail at his own domain. It has nothing to do with his job.
Setting up and administering your own domain is an IT hobby that people outside of IT (including most professional programmers) have little appreciation for. To them, it's like the difference between sewing your own clothes and buying them in a store. Sounds like a lot of work -- who would bother unless it was a hobby they enjoyed?
It's apparently hit and miss. Some people report everything working automatically, but Gutsy and Hardy didn't handle either of my Fuji Finepix cameras. They aren't even recognized as cameras. Even when I open the camera app, choose exactly the right model, and ask the app to find the camera, it can't see it. So I'm stuck using Windows to manage my photographs.
How do libraries and application frameworks restrict your freedom? Your boss makes you use them? Sorry, I don't follow your argument at all. If you want to write your own socket library, regular expressions library, and logging framework, go ahead and do it. Nobody's stopping you.
If modern amenities have made you bored with programming, I suggest attacking a problem domain that hasn't yet been made trivially easy. Get a four-core box and convert a single-threaded application into one that uses all four cores efficiently. That's something that Java and .NET won't solve for you. Whenever one problem is rendered trivial by Moore's law or by some helpful library author, there is always a bigger problem to tackle.
I use Eclipse on Ubuntu installed straight from eclipse.org, and I have the same nagging problem with corrupted workspaces. If the OP googles around, he can find some tips for fixing a corrupted workspace, such as by deleting specific directories out of it. You still lose a lot of state, including all your preferences. Sometimes you lose everything except your projects, which is almost as bad as rebuilding the whole workspace.
I use Eclipse 3.3 (Europa), the RCP download. I haven't heard that 3.4 has any stability improvements over 3.3, but I plan on upgrading anyway because headless builds have supposedly been greatly simplified -- *wonderful* news for those of use who still shamefacedly use the application export wizard because we can't take a week off to figure out the Eclipse build system.
P.S. Despite these complaints, I'm happy using Eclipse for my RCP app and would still pick Eclipse if I had the choice over again.
SGI's STL site is excellent, though I'm not not sure how up-to-date it is.
The C++ Programming Language , by Bjarne Stroustrup, is the only essential and authoritative language reference, other than the standard itself. It isn't a web site, but programming in C++ isn't something you pick up on a whim.
And of course Boost, the first place to look when you think, "There should be a library for this."
In my experience there can be a persistent problem where sales guys have no understanding of the product or service they're supposed to sell. Their managers know it, the engineering managers know it, executives know it, but the situation is tolerated and the sales guys are expected to keep on selling. Don't ask me why, but I've seen people tolerate that state of affairs for years as if there were no cure for it.
In my experience the biggest driver of tech's disdain for business is the farcical nature of some managers' attempts at quantifying certain aspects of their business.
All businesses manage to quantify a few things extremely well -- payroll, revenue, taxes, and so forth. There are many other things that can be quantified in a useful way. However, many business types engage in persistent fantasies about quantifying things like programmer productivity, ROI on buying software tools, and the effect of different business methodologies. Quantifying things is an excellent idea, but it's so overwhelmingly difficult to measure things like management productivity and (God help us all) "project velocity" that 98.6% of all attempts to do so are essentially fraudulent -- just as dishonest as if I pretended that number I just read off my rectal thermometer had any meaning more precise than "most."
Engineers are likely to feel a little twitchy just looking at the number "98.6" because they associate it with the classic overprecise and somewhat incorrect statement that normal body temperature is 98.6 degrees fahrenheit. If that number annoys us, what do you think we feel like when some business type says we should use Scrum because 87% of all enterprise-scale software projects come in 50% over budget, while only 63% of Scrum projects come in 50% over budget? Whenever engineers and business types speak in a common language (mathematics, logic, statistics, controlled studies) it turns out that the business types come off as STUPID, GULLIBLE, OVERCONFIDENT, AND FULL OF SHIT.
Which is not to say that business types are stupid. There are honest and intelligent managers who aspire to quantitative precision and may work very hard at it, but they don't go around waving numbers and graphs because they know the results are extremely difficult to interpret -- more "food for thought" than "results." The guys who make a big deal out of numbers like the ones in the last paragraph are either con artists or victims of con artists. They think that making quantitatively precise comparisons of programming methodologies is a strategic managerial decision that you implement by repeating numbers you read in [blog summaries of] management journals, just like creativity is a lifestyle choice that you implement by your choice of haircut, clothing, and a certain brand of digital accessories. It never crosses their mind that it might be something intrinsically difficult that you can work really hard at without ever producing anything worth sharing -- that's how poorly they understand it.
But it always seems like it's the guys who make up bullshit numbers who write the papers, run the consultancies, get the attention of upper management, and get put in charge of things they don't understand. Business types may have enough patience and faith in management to sit back and watch the pretenders rise meteorically and flame out, but engineers are used to calling bullshit on bullshit when numbers are involved.
Anyway, I could go on, but you get the picture. Engineers accept that not everything can be quantified, and every business decision must, of necessity, rely heavily on guesswork, folklore, and intuition in addition to hard numbers. We can't accept that the business world is full of people who pretend otherwise, without any reasonable justification, and somehow escape being laughed at by their supervisors and peers.
If you think the media player and web browser are "PDA features" then we have a semantic disagreement that can't be settled by argument.
Anyway, before I get into that, I did just get an iPhone (between my post and your reply) and it's spiffy :-) Since you have a such strong interest in the iPhone, I'm sure you're curious about my experience. In the week I've had it, I've had no dropped calls (knock on wood) and 3G reception everywhere in town. The 3G reception is always displayed at one bar, which is a bit disappointing since I'm in a major city, but it never disappears completely unless I go out of town. So far I have declined to let iTunes update the firmware and will continue to decline until I'm confident that Apple has figured out the 3G issues.
Battery life isn't an issue for me because I've been in the habit of recharging my phone almost every night, ever since I got my first cell phone. The iPhone doesn't last two full days if I make heavy use of the camera or media player, but recharging has never been a problem for me -- between the wall plug, USB plug, and car charger, I'm covered unless I'm backpacking, in which case I always turn my phone off completely. The iPhone has never had a problem lasting all day, even though I've been playing with it a lot since I bought it.
Back to the categorization: I guess my best argument that iPhones are in a different market segment from Blackberries and Windows Mobile devices is that the overlap in ownership is almost entirely in tech-industry people. The vast majority of iPhones and Blackberries are sold to people other than programmers, IT folks, and tech executives, but those are the only folks who seem to seriously consider both kinds of devices. When iPhones get better at Exchange integration and can sync with your Outlook calendar, I suppose there will be a category of young, fashion-sensitive business types who would consider both kinds of devices.
From my personal point of view, I never felt like they were the same kind of device. Blackberries have no appeal for me; I don't do a lot of email or instant messaging and don't want half my device to be dedicated to a keyboard. To me, the most attractive alternatives to the iPhone were stylus-based Windows Mobile phones with slide-away keyboards. Before I bought the iPhone, I paid a lot of attention to my colleagues when they were using their Windows Mobile devices and iPhones. Stylus systems have always disappointed me, and after watching people use Windows Mobile stylus systems, I've come to believe that this is due to the inherent physical inconvenience, not just bad implementations. The Windows Mobile devices seemed better prepared to scale up to arbitrary levels of complexity and to accomodate desktop apps with less adaptation required. I probably would have bought a Windows Mobile device if I wanted to run third-party applications or spend a lot of time intently using complex business applications. For that kind of focused, sustained usage, the stylus makes sense. I thought of Windows Mobile as being a good platform for someone who wants his phone to be as close as possible to having a full PC in his pocket. Obviously the iPhone is pretty candy-assed if that's what you want, so in my mind the iPhone doesn't compete in that category.
I was equally convinced by my observations that Windows Mobile devices don't compete with the iPhone when it comes to doing the handful of core tasks that are built into the iPhone. The first time I watched someone using Safari on the iPhone, it was a revelation. You can pull the iPhone out of your pocket, perform a simple task, and not feel like the device has imposed a lot of overhead on you. I never felt that way with a stylus, and the touch-screen systems I've seen (other than the iPhone) were so clunky I wished I could use a 10-digit keypad instead. I have to admit that the iPhone is more sluggish than I'd like, but not enough to piss me off. If you want to let your tech-illiterate friend browse your music or
May God grant you long life and free beer. A successful approach to supporting applications at the filesystem level will make it much easier to write scripts that manipulate application data. Just eyeball the data stored in the filesystem using standard filesystem tools, write a script that manipulates it, again using standard filesystem tools, and voila -- no hidden metadata to find, parse, and massage to get things to work.
Linux nerds like scripting and command-line work, but occasionally we also like big, integrated applications. When big, integrated applications can't use the filesystem in a straightforward way, they develop complex, inscrutable storage solutions that can't be directly manipulated by casual usernerds.
The biggest "problems" with Javascript are the browser inconsistencies and the fact that it is used by web designers, who don't write code to the tastes and standards of software developers. Neither of these has anything to do with Javascript.
The first is a problem of power and economics. You can't force the standardization of browser APIs just by announcing a new language or extending an old one.
The second isn't a problem, except in the heads of software developers. If we stop web developers from writing "crappy" Javascript code, then meaningful, user-visible functionality will take a nose dive. "Real" software developers don't really want to write client-side web UI code, they just want to stop the web designers from doing it. Result: nothing gets done, everything sucks.