>When I'm looking to hire someone I couldn't care less what languages they know! As long as they >are decent programmer its easy to teach them a new langange.
I don't disagree with your point in general, but it's *NOT* so easy for a "decent" programmer to ramp up in a new language doing anything of decent complexity. It takes a good bit of time to get comfortable with a language and the libraries available. Getting something work at all is one thing, having enough comfort that you don't want to re-write everything now that you "know better" is entirely different. The latter isn't a matter of a few weeks, even for someone that's "above average".
I've seen this process over and over in the development world. As a side note, there is no question in my mind people who've worked at a slightly lower level (IE - C/C++ programmers) who've had some real experience with memory mangement/pointers, generally have a FAR easier time moving to Java/C# than vice versa.
Forgive me as I continue to be a little lost on how you've gained moderator points on this one as well.
I'm quite curious to know what exactly the project(s) were that had you maintaining code from the 60s with an expected lifetime of decades. Just what computer from the 60s was this code written on? What database backend in pure assembler did you have your hands in? What kernel? What drivers?
You don't have to learn anything in college, or school at all for that matter, do you now?
I found your previous 3 point summary of all computer work less than insightful. I was particularly amused with the statement that virtually everything had been "solved" in the 60s. Java == cobol, business programming is some simple issue, and whatever other silliness. What's up with this stupid google company making zillions off basically text searching and sorting algorithms. Sheesh. It sounds like you've missed your opportunity several times over.
proper task and memory management and inter-process communication in multi-threaded, multi-process, and distributed environments in a formal setting
Hah. No kidding. In theory you could also benefit from a 4th semester calculus class rather than trying to teach that stuff to yourself too.
I've never met a single person who's done anything of any significance who doesn't consider programming challenging. Good programmers are bright people -- and they get attracted to it in part because it's a challenge. Writing complex software that's fast, secure, and reliable is not easy.
I've seen several studies which cite a 10-20x difference in productivity between a "good" and "average" programmer. If you've ever worked on a development team with a variety of skill levels you don't need studies to verify this -- and not everyone is cut out for it who goes in (desire and/or ability).
Anyway I'm biting on a troll that got modded insightful. Time to move on. If you choose to pontificate any further on this, please take a moment to point out some of the projects you've worked on (or even better, your code).
Another poster already made a clarification on this. I didn't "mis-speak" I was just a bit obscure with my meaning. Point being, if you code in C/C++ you'll spend a lot of time making the program work correctly. If you write in eg Java or Python you can get the program working correctly in a fraction of the time. This means you can add polish or move on to new stuff.
These statements about programming productivity given X language spouted as truisms still make me grind my teeth. I've spent most of my time programming in C++ and Java. After gaining a good bit of experience with Java, I awaited the epiphany that I was suddenly experiencing a boost in productivity coding in Java. This never happened. My experience in dealing with other professional developers (the company I am currently with employs 80+) is that most with significant experience in both worlds share this opinion. The languages are simply not that far apart on the language tree. Java's "out of the box" libraries dwarf the STL, but it is not as if its difficult to find mature C++ libraries (QT, ACE, BOOST, etc) which cover the bases and provide a cross-platform framework. The level of depth is simply not that wide - nothing like ASM->C. Does anyone really feel writing a complex swing GUI is more efficient than a similar QT one? Back in the day, the lack of templates was a checkmark in the Java win column for "simplicity and productivity". So here we are now with Generic's in Java's latest incantation, along with our old friends enum and printf. It also always amazed me when operator overloading was touted as some highly confusing mess that Java managed to avoid -- when page 3 or so of any Java book has you concatenating strings using +. If anything, Java and C++ continue to grow more similar and this trend is only bound to continue. The popularity of Java has in no small way influenced the thinking and proposals for the impending C++0x standard.
During my time at the university I had a couple professors who were large fans of functional programming. If anything this argument is far more interesting to me as it involves an entirely different programming paradigm (whereas Java and C++ are both "OOP" languages, with extremely similar syntax). LISP has been a garbage collected language since the 60s. However functional programming continues to dodge any real mainstream acceptance.
First off, I'm willing to bet that virtually none of the little apps you currently have running are written in Java/Python whatnot. A sloppy coder can leak memeory in any language. (In fact I'd say it's a lot easier to leak memory in a language without a GC.) So moving to C/C++ doesn't really fix the memory issue.
Yes, it is obviously easier to leak memory in a non-GC language. However, your implication that memory management in a non-GC language is so difficult (and leaks so prevalent) equalizes the greater memory footprint of a GC language is a little baffling. It's simply not that difficult, particularly with the maturity of memory checking toolkits and a variety of well developed smart pointer libraries.
Regarding your comments about performance, let me point you to some interesting comments in "One Half a Manifesto" by Jaron Lanier...
"If anything, there's a reverse Moore's Law observable in software: As processors become faster and memory becomes cheaper, software becomes correspondingly slower and more bloated, using up all available resources...
One part of the answer is fundamental. It turns out that when programs and datasets get bigger (and increasing storage and transmission capacities are driven by the same processes that drive Moore's exponential speedup), internal computational overhead often increases at a worse-than-linear rate. This is because of some nasty mathematical facts of life regarding algorithms. Making a problem twice as large usually makes it take a lot more than twice as long to solve. Some algorithms are worse in this way than others, and one aspect of getting a solid underg
"I'm sorry, tyrantnine. Your claim that the two statements I made contridict each other doesn't support your argument. Instead it provides evidence that you sometimes misunderstand what you are told."
I didn't claim it supported my argument. I pointed it out as you flat directly contradicted yourself as far as what it means to draw a gun within the span of few sentences.
"The rule is that you make the decision that you ARE AREADY JUSTIFIED in using the gun and WILL use the gun if necessary before you pull and point it."
...
"But the point is that you made the decisions that you are legally (and morally) justified to shoot, and you will do so, before you drew."
You got it right the second time. "you will do so". Not "if necessary". People who draw a gun unsure about their expectation to fire it should not draw a gun.
So I'm sorry Ungrounded Lightning that you're wrong, or perhaps just muddled the point and refuse to back down, but thats the way it is. Since you seem to be a fan of logic, you undoubtedly realize your appeal(s) to authority do not support your case. They simply prove that you continue talking in the face of fact and probably do so regularly!
Any further activity in this thread will be ignored/unknown to me. Have a nice day.
No I did not misunderstand the lesson. I find it interesting having no knowledge of it, you'd choose to argue about it. Regardless, the very simple point that is stressed quite clearly is that if you are drawing your gun, you have decided to shoot, immediately. Period. End of story. The flip side of that coin is that if you have not yet made the decision when you draw your gun you are going to immediately fire it, you DO NOT DRAW IT. Period. It is not "will use the gun if necessary" as you allude to (before contradicting yourself later by saying "you will do so"). That directly contradicts the point.
Anyway, the point really cant be more simple. If you draw, you plan to fire, NOW. That is how it is taught down here in Texas, and you are free to call any gun store and ask for an instructor to confirm it.
Re:Replaced by: My gun didn't know me so I got kil
on
Smart Guns are Coming
·
· Score: 1
Maybe once in eight average lifetimes only a gun will protect you from murder. Maybe several times in an average lifetime a gun will protect you and/or yours from death or serious bodily harm from criminal activity. (Your mileage WILL vary greatly.) In each of these situations, maybe nineteen times in twenty showing the gun is enough, one time in twenty your "bluff gets called" and you actually have to FIRE the gun....
When one of these things happens, if you need your gun to fire it MUST fire.
I live in Texas, where we have a concealed hangun law. One must undergo (and pass) training to get such a permit.
One thing stressed heavily in every single class is that one does not pull out a gun with no intention of using it. Pulling out a gun in hopes that it will defuse or get a situation under control is beyond irresponsible. You are taught explictily that if you pull out your gun, you are going to fire it. Period. Pulling a gun on someone is going to enhance the severity of any situation you're in, not calm it down.
So anyway, your statement that 19/20 times you'll only need to pull a gun to get a situation under control is flat stupid. If you can't see the logic of it, perhaps you would benefit from a few hours of handgun training in Texas.
I agree with you basic HTML is not "programming". I just assume when talking about a programmer there's a premise of a sane definition. That said I've never once heard a web page designer refer to themselves as a programmer.
However you also conflate programming with CS.
Attributed to Dijkstra, "Computer Science is no more about computers than astronomy is about telescopes"
For a somewhat alternate view from Stroustrup, "In some well-respected computer science departments, you can graduate without having written any code. That ought not be possible. Nobody should graduate with a degree in computer science or computer engineering without having completed a significant programming project. Code is the base of computing and people without a "feel" for code tend to seriously misjudge what skills, tools, and time are needed to build good systems."
My University certainly put the emphasis on theory. While the core reqs did require a good dose of programming, if thats all you ever took (and did nothing more outside of coursework), you would be graduating a programming novice. And many, many did (and still do).
Anyway, thats not to say anyone who's not really into programming doesn't love computers (or CS). Visit any LUG to find some prime examples. However in terms of difficulty, becoming a skilled programmer is a lot more difficult than virtually any other CS-related career.
I agree that programming is absolutely not for dummies. However you make a serious error equating programming with a job in industry. Many people interested in computers, or even computer science, are not interested in programming nor are they cut out for it.
Some time back I went to a company reception that preceded on-campus interviews for a software engineering job. It was amazing to me how many questions directed at the recruiter could be summarized as "how fast can I get out of programming to do something else?".
My university had a very highly rated computer science department. Only a small fraction of my peers really had the talent/interest to become good computer programmers. The rest were wannabe System Administrators, QA/Testers, "Web Designers", etc. Elective courses requiring heavy programming were almost never full.
Wow, you're trying to get the most money from your employer and they're trying to get the most work they can out of you? Horrible. Call the NYT right away.
You speak of this as if its an even battle. The reality is corporations/employers usually have an extreme advantage. Thus the advent of Unions and Labor Laws attempting to protect individuals from being forced spend the entire waking lives working. It took many, many decades for this to happen
You might as well save your breath and spend your time figuring out how you're going to compete in this new global environment. I know I have.
It's going to be a long road down if any multinational corporation can pick the easiest/cheapest to exploit national labor pool and work them like dogs. I dont think a global economy means we need to throw out the decades of progress made in some first world countries as far as workers rights.
Great. Next time you need surgery, go see a biologist. When your pipes break, ask a metallurgist. When your TV breaks, ask a semiconductor designer.
These silly analogies still don't correlate. A biologist does not use surgical equipment. A metallurgist does not use plumbing tools. And on and on. A developer uses a computer, and interacts with an OS, every day.
but to simply make people realize that I might be slow and error-prone when I'm trying to fix their printer.
You've changed your tune here a bit. So indeed, its not quite like asking the bridge designer to fix a car. Your general experience with computers (and whatever OS's configuration) and apparently vast background with networking gives you a fairly good idea of how to click through network setup wizards in windows. Probably a greater edge than many folks at the Best Buy service department who your family/friends might otherwise turn to. Of course, if your brother happens to do Windows Desktop support for a living, you might refer calls to him instead.
Why should knowing something about how cares are put together translate into ability to repair them?
The relationship is blindingly obvious, so I am not quite sure how this is even a question.
I have experience in setting up networks, writing networking software, writing network analyzers, and I know a lot of theory behind the whole thing, but in the end it didn't save me, because I had no experience with Windows.
You're seriously claiming this apparently healthy background of yours was useless? Yes, Windows (and Linux, or any OS, or virtually any piece of complex software) is loaded with details and quirks. Given what you've just said about your background, I'd assume you'd not only be able to figure out how it works, but perhaps fix a bug in it given the source code. Or modify it. Or flat write your own network configuration wizard if MS hired you to do so tomorrow.
You're a Windows user, right? It seems like you don't realize that the bizarre and inexplicable which plague Windows computers simply don't happen on any other system. Maybe you do realize it, and I'm misinterpreting.
Ah the smell of ignorance and zealotry. Actually, I'm typing to you from Linux, and I personally prefer it. However to claim I've never spent two hours on configuration issue I figured would be a simple matter, that led me down a twisty road of quirks and strange details, is amusing.
You're a software developer being asked to figure out other software. So, about as far as your analogy carries is that you're a "designer" asked to be a "mechanic". This appeal to complete apples and oranges (bridges vs cars) doesn't make any sense
While I wouldn't expect a design engineer at ford to be as quick on figuring out whats wrong with my Jetta as the mechanics at a Ford Dealership, he sure as hell knows something about how cars are put (and operate) together.
Anyway, I would expect most developers have had a decent level on interaction with setting up and configuring their own workstations, peripherals, LANs, and whatnot. While they might not be as proficient at hammering out problems as someone who does it for a living, I'd sure be concerned if they were as helpless as you claim to be.
>1. Employers seeking ridiculously diverse skill >sets. What do you want, a software developer >with ten years experience, or a GIS specialist >with database skills? Pick ONE!
I agree with this sentiment, and it hits on another point. While its my impression the job market is better in general (though still rough), I think its particularly rough for new graduates or those with only a year or two of experience.
This seems to be a shift from years of old (pre-boom days). I'd say it's partially due to the explosion of different technologies as well as employer attitudes. Employers now seem to be far more inclined to seek an exact matches on experience and skills than they used to be. They want someone to come in and work miracles immediately with as little ramp up time as possible. Again perhaps it's just my perception but this seems to be a shift from the idea that a solid foundation (a CS/EE degree, general programming (language agnostic), etc) and the ability to adapt was more important than a few years of specific experience with widget X. I'd say its both a sign of the times and the fact a lot of technology has matured over that time period -- it's still odd to me.
I'll also say in the interviews I went through a few months ago, virtually no one advertises nor promises any sort of even (relatively) short-term job stability. I knew those days were gone awhile ago, but its still strange when getting the semi-sales pitch at the beginning of an interview to hear the phrase "As you know, nowhere is really stable".
The boom has been over for quite awhile, and there have been plenty of stories right here on slashdot (as well as many other information sources) showing job trends for "IT" and "Software Engineers" have generally been pretty dismal over intervals as recent as Jan-June 2004.
It's my *assumption* that the vast majority of people who were drawn into the tech boom and weren't particularly qualified have been out of the industry since, at most, late 2002. Crazy internet petfood selling startups went under long ago. This constant appeal to "these are the idiots from the boom" is a really weak argument to me at this point
At what point in examining employment numbers are we supposed to finally accept that there are no more "boom-era idiots" still losing jobs? To me, that point already happened some time ago. However virtually any story hitting on job trends pops up numerous comments about the need to wipe out the idiots and whatnot. To these diehards still convinced that the industry is loaded with clueless folks that have somehow managed to keep themselves in the industry after the boom... whens the cutoff? When can you actually accept there's no crazy artificial bloat of boom time morons out there turning any statistic about tech sector employment into a worthless figure? 2005? 2015?
I took a class awhile back dubbed "Ethics of Computing" and during the last half of the course most of the topics focused on future technologies and their potential impact. Therefore I read a lot of Kurzweil's work as well as many other futurists.
A lot of rather fantastic predictions are made for the short term future (~2020). Even if you believe nanotech at this level is going to be available so quickly, are you going to be able to afford it? Marshall Brain, http://www.marshallbrain.com/, predicts the concentration of wealth is going to accelerate even faster and move to the owners of our impending robotic workforce! Will you be going to the clinic to have your robotic doctor inject these life-altering nanobots, or will you be plotting revolution to overthrow the wild economic imbalance created by a robotic workforce displacing millions?
The comment above is meant to be slightly sarcastic. My overall impression is that many futurists (particularly the optimists, like Kurzweil) predictions are on timeframes that are wildly unrealistic. Does anyone really believe nanotech at this level is even going to be available in their lifetime? Much less cheap enough that sub-billionaires are going to be able to afford treatments?
For someone who's on a much more even keel I suggest reading: http://edge.org/documents/archive/edge74.html
Re:Meanwhile, C++ goes nowhere
on
Java 1.5 vs C#
·
· Score: 1
Sockets, as an operating system specific issue, don't really have a place in the language standard. Especially for C++, which is used for embedded development etc.
I guess you might say the same thing about something like Swing? I guess it's a difficult call - though I certainly hope the impending C++0x standard isn't conservative about increasing the size of the STL. Personally my biggest hope is for a decent threading implementation.
As for "being used for embedded development". I sit here with a dual boot Linux/W2K system loaded with zillions of applications large and small. Of the stuff I haven't written myself, I run exactly 0 C# applications and 1 Java application - Eclipse. Thats it - virtually everything else running on my computer from the bottom up is either C or C++ (save python, which forms the base of package mgmt in Gentoo). So I am always confused when people start talking as if C++ is some "low level" or even legacy language that only EE's touch. Marketroids and zealots have really quite a sales job on exaggerating the death/"inferiority"/utility of C++. That and college-age folk who've learned Java as their primarly language and are in the process of trying to assure themselves, through everyone else, that Java's the best thing since the wheel. Anyway eople not only still use it C++, but still *choose* it, for far more than embedded development.
good software engineering is required for large systems. when you are developing hundred thousand lines of code to million lines of code. no amount of good programming will guarrante a good system without solid software engineering processes.
Agreed. Interestingly, I'd also say this was a large hole in my undergraduate CS education. From talking with friends and co-workers, I'd say I wasn't an isolated case either.
I wouldn't expect all that much effort to move a 2.2 driver to 2.6 (which would apply to the original poster's TV card)
Sounds reasonable, though in thinking about it a little more it'd also obviously depend on how much functionality the driver needs, and whether there's optimizations to be made. I'd guess writing or even updating a driver for a video card would be quite a bit more work than for a ethernet card.
f course, if those cards had "binary" drivers, it's unlikely I would have been able to use them in recent kernels (quoting your "6+" year figure, that would probably mean the binary drivers stopped being updated around 1998), irrespective of them still working perfectly, and would have had to buy both new network cards and a new machine to fit them. I have no need to spend any money on "better" performance for what I'm using this machine for (IP routing if you're interested, not throughput based, just an experiment "lab" running routing protocols such as OSPF, BGP etc.), I would be being forced to spend money needlessly just because a hardware manufacturer won't tell me or anybody else how to get their hardware to do what it is designed to do.
I didn't mean worthless junk in terms of "non-functional". Let's assume those cards werent supported, but have an open spec (ala the original posters TV card. Your situation is different - someone has done the work already). You have three possibilities -- 1) You write a driver yourself 2) You go purchase 4 brand new, cheapy (but faster) ethernet adapters for $25 brand new that are supported 3) You pay someone else to write the driver.
That is what I meant by worthless junk. If no one has developed a driver yet, paying for someone else to do it (or doing it yourself) is not cheaper than simply replacing it. If you can think of a single piece of commodity PC hardware you bought 6+ years ago where this wouldn't be the case, I'm all ears.
I'm not arguing against the value of open specs. However "at least you could do it yourself" or "at least you could pay someone to update it" are both are weak arguments. The original posters point:
"And unless you have the skills to write your own drivers (and most of us, including large numbers of application developers, *don't*), the having specs/source or not is irrelevant.
Is the pragmatic reality. If no one happened to do the work previously, its really of no use to you.
Do you really expect an individual is going to be able to afford this? I have no real idea what kind of timeline it'd take to write a driver from scratch, nor how much an update from 2.2->2.6 would take. Anyone with any background in writing a driver, please inject.
I think its safe to assume the time commitment for someone with the skills wouldn't be complete peanuts. I think its safe to assume the cost of paying someone or a bounty would eclipse the cost of the hardware by several orders of magnitude.
In that case, I suppose you might try and form a group of like-minded owners of the same hardware to spread the burden. I'd imagine pulling this off would be nigh impossible (and quite a bit of work on the part of the organizers too, just to get a bit of old hardware functioning), but if theres a story out there of something like this sucessfully happening at a grassroots level (IE - no company involved), I'd like to hear about it.
I also have to take issue with the other implication you made regarding open specs. I'm all for them, but do you really expect this guy is going to worry about drivers in 2010 for his ancient TV tuner card? Whatever consumer level PC hardware you have today is going to be worthless junk in that sort of timeframe (6+ years). Its not much of an argument for open specs.
An individual funding this sort of development/bounty is not within reality.
I've never argued in this context that C/C++ doesn't offer you more ways to blow your foot off as far as insecure code goes than the other two languages we've targeted. However its rather odd that you responded to my statement about performance with a "retort" about security.
I'm sorry, a rational viewpoint rather than rabid fandom (or hatred) of widely similar languages doesn't quite equate with your implication. If you're truly naive enough to believe switching to Java or C# (if, it were possible in all cases) will magically transform all the code in the world to secure, bug free, resource light, faery paradise, you are truly lost. Frankly I have almost no doubt you've greatly exaggerated your experience as a programmer.
Anyway, I now remember why I so rarely choose to get involved in extended comment discussions on slashdot. You've got a small mind and a big mouth, never a good combination.
"You don't pay for what you don't use" makes a great slogan. But products often promise something and fail to deliver. In particular, in C/C++, you pay dearly for the use of manual storage management, both in terms of performance and in terms of safety.
Another broad claim, and certainly in the case of performance, struggling to grip with a wide variety of blindlingly obvious fact.
"Java and Java-without-new would be nearly identical languages, yet they would be very different in practice. To discuss similarity between languages, one has to talk about how the languages work for software development."
Actually, no. When time gives us perspective, I am quite sure any genealogy of languages will be grouping Java 5, C++ '98 and C# very closely on the same branch of the tree. Good grief - just look whats been added to in Java in it's latest incantation - enums, "generics", and wonder of wonders, printf!
A real example of something thats quite different to use in practice might be a functional language like say, Haskell. Java C++ transistion is rather easy to describe to a programmer of either language preciesly because the language structure and syntax are so incredibly similar. Java Haskell is not at all, though both feature a GC.
As I was saying, there are plenty of decent languages and platforms. Just pick anything other than C/C++ and chances are you will be much better off.
I guess I was right in the first place - you are just a language war flameboy.
Why should I? It has taken a while, but the industry is coming around to my point of view: Java and C# are hugely popular for new projects, while C and C++ are more and more relegated to legacy code. You are the anachronism, the software equivalent of a member of the "flat earth society". Sounds to me like it's time for you to retire
Once again, I never promoted anything. I know you're desperate to attack something since you're wildly trying to win a hopeless point, so I'll forgive you.
Rabid love or hate one way or the other is irrational and usually the sign of a novice. Sorry! Most people want to believe whatever they know best, or prefer, is the best. _Most_ programmers with any measurable breadth can sit back and shake their head. Sorry!
You are absolutely right, they have
Your arrogance is amusing
They are quite similar in the sense that they all use a lot of braces. That's pretty much where the similarity ends, however.
Are you joking? The syntax and semantics are in many cases nearly identical. Most keywords are shared, and others are basically simple synonyms, and the same goes for syntax differences. There are little details here and there, but things are very similar right up until memory management and pointers, where C++ obviously breaks off
Like your other ideas, you are wrong there as well. I have more than 20 years and several hundred KLOC of C programming under my belt (Saber C and Purify made it more bearable). Unlike you, however, I know better than to think that just because it can be done and people pay for it, it must be a good idea.
I stated one of the design decisions behind C++ and that it will never therefore have a GC - and to say that a language without a GC is somehow horribly broken is just pure naivety. Neither did I disparge one language over another, as you seem to imply I did.
Perhaps you are anti-fanboy after all. Maybe you're one of those who bloviates as if they know something while making it clearly obvious they don't. To you, and your obvious genius, everything is flawed, all stifling your abilities. Your suggestion about System-level programming and language choice is just flat stupid, and your comments regarding QT/GTK were at best ignorant. If you really have 20 years of coding experience, I suggest you consider an early retirment.
It's a myth that C/C++ is particularly fast or efficient for those applications: in the absence of language-provided features like garbage collection, runtime safety, or dynamic typing, people end up reinventing those features over time, badly and less efficiently.
I'm sorry, it's a myth? Apparently many millions of people, many far better programmers than you, have completely been deceived! Please back up this wonderfully baseless statement with some substance.
One of the core ideas behind the design of C++ is "if you don't use it, you don't pay for it". Do a quick look around at talk of the impending C++0x standard, and you'll see this mantra is alive and well to this very day... and the lack of some "language features", like forced garbage collection, don't exist it for this very reason.
To point to QT and GTK and somehow equate these very fine libs/toolkits was a "sad example" of how C/C++ forces people to "re-design things badly" reflects some serious ignorance. It only took one reply to another poster to totally contradict yourself and say GTK is in fact, a well designed toolkit. The fact you qualified it with "as well as could be done in C" shows you're a language war fanboy, and most fanboys are beginners who don't know any better.
Java/C# and even C++ really aren't wildly different languages. Fanatics claiming 500x speedups in their development time are immediately red flagged to me as ignorant.
What strikes me as more than a little amusing is post like this, complaining about resource hungry software, gains many head nods when any heavyweight application comes out.
Yet if you flip over to the replies to whatever language is better than X thread, you will find just as many people (more?) casually claiming suffering a 1.25x slowdown and 15% more memory usage is nothing because computers are ultra fast, memory is cheap, etc.
The latest and greatest heavyweight feature packed software has always found a way to expand it's needs to meet it's income, so to speak. Writing efficient code, both in terms of speed in memory, is not going out of vogue anytime soon, no matter how much you want to believe otherwise!
Slashdot Mirror
>When I'm looking to hire someone I couldn't care less what languages they know! As long as they >are decent programmer its easy to teach them a new langange.
I don't disagree with your point in general, but it's *NOT* so easy for a "decent" programmer to ramp up in a new language doing anything of decent complexity. It takes a good bit of time to get comfortable with a language and the libraries available. Getting something work at all is one thing, having enough comfort that you don't want to re-write everything now that you "know better" is entirely different. The latter isn't a matter of a few weeks, even for someone that's "above average".
I've seen this process over and over in the development world. As a side note, there is no question in my mind people who've worked at a slightly lower level (IE - C/C++ programmers) who've had some real experience with memory mangement/pointers, generally have a FAR easier time moving to Java/C# than vice versa.
Forgive me as I continue to be a little lost on how you've gained moderator points on this one as well.
I'm quite curious to know what exactly the project(s) were that had you maintaining code from the 60s with an expected lifetime of decades. Just what computer from the 60s was this code written on? What database backend in pure assembler did you have your hands in? What kernel? What drivers?
You don't have to learn anything in college, or school at all for that matter, do you now?
I found your previous 3 point summary of all computer work less than insightful. I was particularly amused with the statement that virtually everything had been "solved" in the 60s. Java == cobol, business programming is some simple issue, and whatever other silliness. What's up with this stupid google company making zillions off basically text searching and sorting algorithms. Sheesh. It sounds like you've missed your opportunity several times over.
proper task and memory management and inter-process communication in multi-threaded, multi-process, and distributed environments in a formal setting
Hah. No kidding. In theory you could also benefit from a 4th semester calculus class rather than trying to teach that stuff to yourself too. I've never met a single person who's done anything of any significance who doesn't consider programming challenging. Good programmers are bright people -- and they get attracted to it in part because it's a challenge. Writing complex software that's fast, secure, and reliable is not easy.I've seen several studies which cite a 10-20x difference in productivity between a "good" and "average" programmer. If you've ever worked on a development team with a variety of skill levels you don't need studies to verify this -- and not everyone is cut out for it who goes in (desire and/or ability).
Anyway I'm biting on a troll that got modded insightful. Time to move on. If you choose to pontificate any further on this, please take a moment to point out some of the projects you've worked on (or even better, your code).
Another poster already made a clarification on this. I didn't "mis-speak" I was just a bit obscure with my meaning. Point being, if you code in C/C++ you'll spend a lot of time making the program work correctly. If you write in eg Java or Python you can get the program working correctly in a fraction of the time. This means you can add polish or move on to new stuff.
These statements about programming productivity given X language spouted as truisms still make me grind my teeth. I've spent most of my time programming in C++ and Java. After gaining a good bit of experience with Java, I awaited the epiphany that I was suddenly experiencing a boost in productivity coding in Java. This never happened. My experience in dealing with other professional developers (the company I am currently with employs 80+) is that most with significant experience in both worlds share this opinion. The languages are simply not that far apart on the language tree. Java's "out of the box" libraries dwarf the STL, but it is not as if its difficult to find mature C++ libraries (QT, ACE, BOOST, etc) which cover the bases and provide a cross-platform framework. The level of depth is simply not that wide - nothing like ASM->C. Does anyone really feel writing a complex swing GUI is more efficient than a similar QT one? Back in the day, the lack of templates was a checkmark in the Java win column for "simplicity and productivity". So here we are now with Generic's in Java's latest incantation, along with our old friends enum and printf. It also always amazed me when operator overloading was touted as some highly confusing mess that Java managed to avoid -- when page 3 or so of any Java book has you concatenating strings using +. If anything, Java and C++ continue to grow more similar and this trend is only bound to continue. The popularity of Java has in no small way influenced the thinking and proposals for the impending C++0x standard.
During my time at the university I had a couple professors who were large fans of functional programming. If anything this argument is far more interesting to me as it involves an entirely different programming paradigm (whereas Java and C++ are both "OOP" languages, with extremely similar syntax). LISP has been a garbage collected language since the 60s. However functional programming continues to dodge any real mainstream acceptance.
First off, I'm willing to bet that virtually none of the little apps you currently have running are written in Java/Python whatnot. A sloppy coder can leak memeory in any language. (In fact I'd say it's a lot easier to leak memory in a language without a GC.) So moving to C/C++ doesn't really fix the memory issue.
Yes, it is obviously easier to leak memory in a non-GC language. However, your implication that memory management in a non-GC language is so difficult (and leaks so prevalent) equalizes the greater memory footprint of a GC language is a little baffling. It's simply not that difficult, particularly with the maturity of memory checking toolkits and a variety of well developed smart pointer libraries.
Regarding your comments about performance, let me point you to some interesting comments in "One Half a Manifesto" by Jaron Lanier...
"If anything, there's a reverse Moore's Law observable in software: As processors become faster and memory becomes cheaper, software becomes correspondingly slower and more bloated, using up all available resources...
One part of the answer is fundamental. It turns out that when programs and datasets get bigger (and increasing storage and transmission capacities are driven by the same processes that drive Moore's exponential speedup), internal computational overhead often increases at a worse-than-linear rate. This is because of some nasty mathematical facts of life regarding algorithms. Making a problem twice as large usually makes it take a lot more than twice as long to solve. Some algorithms are worse in this way than others, and one aspect of getting a solid underg
"I'm sorry, tyrantnine. Your claim that the two statements I made contridict each other doesn't support your argument. Instead it provides evidence that you sometimes misunderstand what you are told."
...
"But the point is that you made the decisions that you are legally (and morally) justified to shoot, and you will do so, before you drew."
I didn't claim it supported my argument. I pointed it out as you flat directly contradicted yourself as far as what it means to draw a gun within the span of few sentences.
"The rule is that you make the decision that you ARE AREADY JUSTIFIED in using the gun and WILL use the gun if necessary before you pull and point it."
You got it right the second time. "you will do so". Not "if necessary". People who draw a gun unsure about their expectation to fire it should not draw a gun.
So I'm sorry Ungrounded Lightning that you're wrong, or perhaps just muddled the point and refuse to back down, but thats the way it is. Since you seem to be a fan of logic, you undoubtedly realize your appeal(s) to authority do not support your case. They simply prove that you continue talking in the face of fact and probably do so regularly!
Any further activity in this thread will be ignored/unknown to me. Have a nice day.
No I did not misunderstand the lesson. I find it interesting having no knowledge of it, you'd choose to argue about it. Regardless, the very simple point that is stressed quite clearly is that if you are drawing your gun, you have decided to shoot, immediately. Period. End of story. The flip side of that coin is that if you have not yet made the decision when you draw your gun you are going to immediately fire it, you DO NOT DRAW IT. Period. It is not "will use the gun if necessary" as you allude to (before contradicting yourself later by saying "you will do so"). That directly contradicts the point.
Anyway, the point really cant be more simple. If you draw, you plan to fire, NOW. That is how it is taught down here in Texas, and you are free to call any gun store and ask for an instructor to confirm it.
Maybe once in eight average lifetimes only a gun will protect you from murder. Maybe several times in an average lifetime a gun will protect you and/or yours from death or serious bodily harm from criminal activity. (Your mileage WILL vary greatly.) In each of these situations, maybe nineteen times in twenty showing the gun is enough, one time in twenty your "bluff gets called" and you actually have to FIRE the gun. ...
When one of these things happens, if you need your gun to fire it MUST fire.
I live in Texas, where we have a concealed hangun law. One must undergo (and pass) training to get such a permit.
One thing stressed heavily in every single class is that one does not pull out a gun with no intention of using it. Pulling out a gun in hopes that it will defuse or get a situation under control is beyond irresponsible. You are taught explictily that if you pull out your gun, you are going to fire it. Period. Pulling a gun on someone is going to enhance the severity of any situation you're in, not calm it down.
So anyway, your statement that 19/20 times you'll only need to pull a gun to get a situation under control is flat stupid. If you can't see the logic of it, perhaps you would benefit from a few hours of handgun training in Texas.
I agree with you basic HTML is not "programming". I just assume when talking about a programmer there's a premise of a sane definition. That said I've never once heard a web page designer refer to themselves as a programmer.
However you also conflate programming with CS.
Attributed to Dijkstra, "Computer Science is no more about computers than astronomy is about telescopes"
For a somewhat alternate view from Stroustrup, "In some well-respected computer science departments, you can graduate without having written any code. That ought not be possible. Nobody should graduate with a degree in computer science or computer engineering without having completed a significant programming project. Code is the base of computing and people without a "feel" for code tend to seriously misjudge what skills, tools, and time are needed to build good systems."
My University certainly put the emphasis on theory. While the core reqs did require a good dose of programming, if thats all you ever took (and did nothing more outside of coursework), you would be graduating a programming novice. And many, many did (and still do).
Anyway, thats not to say anyone who's not really into programming doesn't love computers (or CS). Visit any LUG to find some prime examples. However in terms of difficulty, becoming a skilled programmer is a lot more difficult than virtually any other CS-related career.
Well, to continue the tangent...
I agree that programming is absolutely not for dummies. However you make a serious error equating programming with a job in industry. Many people interested in computers, or even computer science, are not interested in programming nor are they cut out for it.
Some time back I went to a company reception that preceded on-campus interviews for a software engineering job. It was amazing to me how many questions directed at the recruiter could be summarized as "how fast can I get out of programming to do something else?".
My university had a very highly rated computer science department. Only a small fraction of my peers really had the talent/interest to become good computer programmers. The rest were wannabe System Administrators, QA/Testers, "Web Designers", etc. Elective courses requiring heavy programming were almost never full.
Wow, you're trying to get the most money from your employer and they're trying to get the most work they can out of you? Horrible. Call the NYT right away.
You speak of this as if its an even battle. The reality is corporations/employers usually have an extreme advantage. Thus the advent of Unions and Labor Laws attempting to protect individuals from being forced spend the entire waking lives working. It took many, many decades for this to happen
You might as well save your breath and spend your time figuring out how you're going to compete in this new global environment. I know I have.
It's going to be a long road down if any multinational corporation can pick the easiest/cheapest to exploit national labor pool and work them like dogs. I dont think a global economy means we need to throw out the decades of progress made in some first world countries as far as workers rights.
Great. Next time you need surgery, go see a biologist. When your pipes break, ask a metallurgist. When your TV breaks, ask a semiconductor designer.
These silly analogies still don't correlate. A biologist does not use surgical equipment. A metallurgist does not use plumbing tools. And on and on. A developer uses a computer, and interacts with an OS, every day.
but to simply make people realize that I might be slow and error-prone when I'm trying to fix their printer.
You've changed your tune here a bit. So indeed, its not quite like asking the bridge designer to fix a car. Your general experience with computers (and whatever OS's configuration) and apparently vast background with networking gives you a fairly good idea of how to click through network setup wizards in windows. Probably a greater edge than many folks at the Best Buy service department who your family/friends might otherwise turn to. Of course, if your brother happens to do Windows Desktop support for a living, you might refer calls to him instead.
Why should knowing something about how cares are put together translate into ability to repair them? The relationship is blindingly obvious, so I am not quite sure how this is even a question. I have experience in setting up networks, writing networking software, writing network analyzers, and I know a lot of theory behind the whole thing, but in the end it didn't save me, because I had no experience with Windows. You're seriously claiming this apparently healthy background of yours was useless? Yes, Windows (and Linux, or any OS, or virtually any piece of complex software) is loaded with details and quirks. Given what you've just said about your background, I'd assume you'd not only be able to figure out how it works, but perhaps fix a bug in it given the source code. Or modify it. Or flat write your own network configuration wizard if MS hired you to do so tomorrow. You're a Windows user, right? It seems like you don't realize that the bizarre and inexplicable which plague Windows computers simply don't happen on any other system. Maybe you do realize it, and I'm misinterpreting. Ah the smell of ignorance and zealotry. Actually, I'm typing to you from Linux, and I personally prefer it. However to claim I've never spent two hours on configuration issue I figured would be a simple matter, that led me down a twisty road of quirks and strange details, is amusing.
That's because your analogy doesn't work
You're a software developer being asked to figure out other software. So, about as far as your analogy carries is that you're a "designer" asked to be a "mechanic". This appeal to complete apples and oranges (bridges vs cars) doesn't make any sense
While I wouldn't expect a design engineer at ford to be as quick on figuring out whats wrong with my Jetta as the mechanics at a Ford Dealership, he sure as hell knows something about how cars are put (and operate) together.
Anyway, I would expect most developers have had a decent level on interaction with setting up and configuring their own workstations, peripherals, LANs, and whatnot. While they might not be as proficient at hammering out problems as someone who does it for a living, I'd sure be concerned if they were as helpless as you claim to be.
>1. Employers seeking ridiculously diverse skill >sets. What do you want, a software developer >with ten years experience, or a GIS specialist >with database skills? Pick ONE!
I agree with this sentiment, and it hits on another point. While its my impression the job market is better in general (though still rough), I think its particularly rough for new graduates or those with only a year or two of experience.
This seems to be a shift from years of old (pre-boom days). I'd say it's partially due to the explosion of different technologies as well as employer attitudes. Employers now seem to be far more inclined to seek an exact matches on experience and skills than they used to be. They want someone to come in and work miracles immediately with as little ramp up time as possible. Again perhaps it's just my perception but this seems to be a shift from the idea that a solid foundation (a CS/EE degree, general programming (language agnostic), etc) and the ability to adapt was more important than a few years of specific experience with widget X. I'd say its both a sign of the times and the fact a lot of technology has matured over that time period -- it's still odd to me.
I'll also say in the interviews I went through a few months ago, virtually no one advertises nor promises any sort of even (relatively) short-term job stability. I knew those days were gone awhile ago, but its still strange when getting the semi-sales pitch at the beginning of an interview to hear the phrase "As you know, nowhere is really stable".
Yes, in the *late 90s*.
The boom has been over for quite awhile, and there have been plenty of stories right here on slashdot (as well as many other information sources) showing job trends for "IT" and "Software Engineers" have generally been pretty dismal over intervals as recent as Jan-June 2004.
It's my *assumption* that the vast majority of people who were drawn into the tech boom and weren't particularly qualified have been out of the industry since, at most, late 2002. Crazy internet petfood selling startups went under long ago. This constant appeal to "these are the idiots from the boom" is a really weak argument to me at this point
At what point in examining employment numbers are we supposed to finally accept that there are no more "boom-era idiots" still losing jobs? To me, that point already happened some time ago. However virtually any story hitting on job trends pops up numerous comments about the need to wipe out the idiots and whatnot. To these diehards still convinced that the industry is loaded with clueless folks that have somehow managed to keep themselves in the industry after the boom... whens the cutoff? When can you actually accept there's no crazy artificial bloat of boom time morons out there turning any statistic about tech sector employment into a worthless figure? 2005? 2015?
I took a class awhile back dubbed "Ethics of Computing" and during the last half of the course most of the topics focused on future technologies and their potential impact. Therefore I read a lot of Kurzweil's work as well as many other futurists.
A lot of rather fantastic predictions are made for the short term future (~2020). Even if you believe nanotech at this level is going to be available so quickly, are you going to be able to afford it? Marshall Brain, http://www.marshallbrain.com/, predicts the concentration of wealth is going to accelerate even faster and move to the owners of our impending robotic workforce! Will you be going to the clinic to have your robotic doctor inject these life-altering nanobots, or will you be plotting revolution to overthrow the wild economic imbalance created by a robotic workforce displacing millions?
The comment above is meant to be slightly sarcastic. My overall impression is that many futurists (particularly the optimists, like Kurzweil) predictions are on timeframes that are wildly unrealistic. Does anyone really believe nanotech at this level is even going to be available in their lifetime? Much less cheap enough that sub-billionaires are going to be able to afford treatments?
For someone who's on a much more even keel I suggest reading: http://edge.org/documents/archive/edge74.html
Sockets, as an operating system specific issue, don't really have a place in the language standard. Especially for C++, which is used for embedded development etc.
I guess you might say the same thing about something like Swing? I guess it's a difficult call - though I certainly hope the impending C++0x standard isn't conservative about increasing the size of the STL. Personally my biggest hope is for a decent threading implementation.
As for "being used for embedded development". I sit here with a dual boot Linux/W2K system loaded with zillions of applications large and small. Of the stuff I haven't written myself, I run exactly 0 C# applications and 1 Java application - Eclipse. Thats it - virtually everything else running on my computer from the bottom up is either C or C++ (save python, which forms the base of package mgmt in Gentoo). So I am always confused when people start talking as if C++ is some "low level" or even legacy language that only EE's touch. Marketroids and zealots have really quite a sales job on exaggerating the death/"inferiority"/utility of C++. That and college-age folk who've learned Java as their primarly language and are in the process of trying to assure themselves, through everyone else, that Java's the best thing since the wheel. Anyway eople not only still use it C++, but still *choose* it, for far more than embedded development.
good software engineering is required for large systems. when you are developing hundred thousand lines of code to million lines of code. no amount of good programming will guarrante a good system without solid software engineering processes.
Agreed. Interestingly, I'd also say this was a large hole in my undergraduate CS education. From talking with friends and co-workers, I'd say I wasn't an isolated case either.
I wouldn't expect all that much effort to move a 2.2 driver to 2.6 (which would apply to the original poster's TV card)
Sounds reasonable, though in thinking about it a little more it'd also obviously depend on how much functionality the driver needs, and whether there's optimizations to be made. I'd guess writing or even updating a driver for a video card would be quite a bit more work than for a ethernet card.
f course, if those cards had "binary" drivers, it's unlikely I would have been able to use them in recent kernels (quoting your "6+" year figure, that would probably mean the binary drivers stopped being updated around 1998), irrespective of them still working perfectly, and would have had to buy both new network cards and a new machine to fit them. I have no need to spend any money on "better" performance for what I'm using this machine for (IP routing if you're interested, not throughput based, just an experiment "lab" running routing protocols such as OSPF, BGP etc.), I would be being forced to spend money needlessly just because a hardware manufacturer won't tell me or anybody else how to get their hardware to do what it is designed to do.
I didn't mean worthless junk in terms of "non-functional". Let's assume those cards werent supported, but have an open spec (ala the original posters TV card. Your situation is different - someone has done the work already). You have three possibilities -- 1) You write a driver yourself 2) You go purchase 4 brand new, cheapy (but faster) ethernet adapters for $25 brand new that are supported 3) You pay someone else to write the driver.
That is what I meant by worthless junk. If no one has developed a driver yet, paying for someone else to do it (or doing it yourself) is not cheaper than simply replacing it. If you can think of a single piece of commodity PC hardware you bought 6+ years ago where this wouldn't be the case, I'm all ears.
I'm not arguing against the value of open specs. However "at least you could do it yourself" or "at least you could pay someone to update it" are both are weak arguments. The original posters point:
"And unless you have the skills to write your own drivers (and most of us, including large numbers of application developers, *don't*), the having specs/source or not is irrelevant.
Is the pragmatic reality. If no one happened to do the work previously, its really of no use to you.
Do you really expect an individual is going to be able to afford this? I have no real idea what kind of timeline it'd take to write a driver from scratch, nor how much an update from 2.2->2.6 would take. Anyone with any background in writing a driver, please inject.
I think its safe to assume the time commitment for someone with the skills wouldn't be complete peanuts. I think its safe to assume the cost of paying someone or a bounty would eclipse the cost of the hardware by several orders of magnitude.
In that case, I suppose you might try and form a group of like-minded owners of the same hardware to spread the burden. I'd imagine pulling this off would be nigh impossible (and quite a bit of work on the part of the organizers too, just to get a bit of old hardware functioning), but if theres a story out there of something like this sucessfully happening at a grassroots level (IE - no company involved), I'd like to hear about it.
I also have to take issue with the other implication you made regarding open specs. I'm all for them, but do you really expect this guy is going to worry about drivers in 2010 for his ancient TV tuner card? Whatever consumer level PC hardware you have today is going to be worthless junk in that sort of timeframe (6+ years). Its not much of an argument for open specs.
An individual funding this sort of development/bounty is not within reality.
I've never argued in this context that C/C++ doesn't offer you more ways to blow your foot off as far as insecure code goes than the other two languages we've targeted. However its rather odd that you responded to my statement about performance with a "retort" about security.
I'm sorry, a rational viewpoint rather than rabid fandom (or hatred) of widely similar languages doesn't quite equate with your implication. If you're truly naive enough to believe switching to Java or C# (if, it were possible in all cases) will magically transform all the code in the world to secure, bug free, resource light, faery paradise, you are truly lost. Frankly I have almost no doubt you've greatly exaggerated your experience as a programmer.
Anyway, I now remember why I so rarely choose to get involved in extended comment discussions on slashdot. You've got a small mind and a big mouth, never a good combination.
"You don't pay for what you don't use" makes a great slogan. But products often promise something and fail to deliver. In particular, in C/C++, you pay dearly for the use of manual storage management, both in terms of performance and in terms of safety.
Another broad claim, and certainly in the case of performance, struggling to grip with a wide variety of blindlingly obvious fact.
"Java and Java-without-new would be nearly identical languages, yet they would be very different in practice. To discuss similarity between languages, one has to talk about how the languages work for software development."
Actually, no. When time gives us perspective, I am quite sure any genealogy of languages will be grouping Java 5, C++ '98 and C# very closely on the same branch of the tree. Good grief - just look whats been added to in Java in it's latest incantation - enums, "generics", and wonder of wonders, printf!
A real example of something thats quite different to use in practice might be a functional language like say, Haskell. Java C++ transistion is rather easy to describe to a programmer of either language preciesly because the language structure and syntax are so incredibly similar. Java Haskell is not at all, though both feature a GC.
As I was saying, there are plenty of decent languages and platforms. Just pick anything other than C/C++ and chances are you will be much better off.
I guess I was right in the first place - you are just a language war flameboy.
Why should I? It has taken a while, but the industry is coming around to my point of view: Java and C# are hugely popular for new projects, while C and C++ are more and more relegated to legacy code. You are the anachronism, the software equivalent of a member of the "flat earth society". Sounds to me like it's time for you to retire
Once again, I never promoted anything. I know you're desperate to attack something since you're wildly trying to win a hopeless point, so I'll forgive you.
Rabid love or hate one way or the other is irrational and usually the sign of a novice. Sorry! Most people want to believe whatever they know best, or prefer, is the best. _Most_ programmers with any measurable breadth can sit back and shake their head. Sorry!
You are absolutely right, they have Your arrogance is amusing
They are quite similar in the sense that they all use a lot of braces. That's pretty much where the similarity ends, however. Are you joking? The syntax and semantics are in many cases nearly identical. Most keywords are shared, and others are basically simple synonyms, and the same goes for syntax differences. There are little details here and there, but things are very similar right up until memory management and pointers, where C++ obviously breaks off
Like your other ideas, you are wrong there as well. I have more than 20 years and several hundred KLOC of C programming under my belt (Saber C and Purify made it more bearable). Unlike you, however, I know better than to think that just because it can be done and people pay for it, it must be a good idea. I stated one of the design decisions behind C++ and that it will never therefore have a GC - and to say that a language without a GC is somehow horribly broken is just pure naivety. Neither did I disparge one language over another, as you seem to imply I did.
Perhaps you are anti-fanboy after all. Maybe you're one of those who bloviates as if they know something while making it clearly obvious they don't. To you, and your obvious genius, everything is flawed, all stifling your abilities. Your suggestion about System-level programming and language choice is just flat stupid, and your comments regarding QT/GTK were at best ignorant. If you really have 20 years of coding experience, I suggest you consider an early retirment.
It's a myth that C/C++ is particularly fast or efficient for those applications: in the absence of language-provided features like garbage collection, runtime safety, or dynamic typing, people end up reinventing those features over time, badly and less efficiently.
I'm sorry, it's a myth? Apparently many millions of people, many far better programmers than you, have completely been deceived! Please back up this wonderfully baseless statement with some substance.
One of the core ideas behind the design of C++ is "if you don't use it, you don't pay for it". Do a quick look around at talk of the impending C++0x standard, and you'll see this mantra is alive and well to this very day... and the lack of some "language features", like forced garbage collection, don't exist it for this very reason.
To point to QT and GTK and somehow equate these very fine libs/toolkits was a "sad example" of how C/C++ forces people to "re-design things badly" reflects some serious ignorance. It only took one reply to another poster to totally contradict yourself and say GTK is in fact, a well designed toolkit. The fact you qualified it with "as well as could be done in C" shows you're a language war fanboy, and most fanboys are beginners who don't know any better.
Java/C# and even C++ really aren't wildly different languages. Fanatics claiming 500x speedups in their development time are immediately red flagged to me as ignorant.
What strikes me as more than a little amusing is post like this, complaining about resource hungry software, gains many head nods when any heavyweight application comes out.
Yet if you flip over to the replies to whatever language is better than X thread, you will find just as many people (more?) casually claiming suffering a 1.25x slowdown and 15% more memory usage is nothing because computers are ultra fast, memory is cheap, etc.
The latest and greatest heavyweight feature packed software has always found a way to expand it's needs to meet it's income, so to speak. Writing efficient code, both in terms of speed in memory, is not going out of vogue anytime soon, no matter how much you want to believe otherwise!