Overcoming Intuition In Programming (amasad.me) 237
An anonymous reader writes: Amjad Masad, a programmer who works at Facebook, has put up a post about intuition and programming. It's based on a series of experiments (PDF) into how the presentation of a problem affects the learning involved in solving it. Researchers found that if they made a test deliberately hard to understand, those taking the test would exhibit greater understanding after solving it than those who were presented with a more intuitive wording of the same problem. Masad discusses how the research applies to software engineering: "Programming is an intellectually challenging task, but luckily we invent tools to make it manageable. I find that up to a certain point, the intuitive and easy properties of a given language, framework, or library might start to have negative effects.
From personal experience and from mentoring beginners I noticed that when using tools that allow us to reason within our intuition, anytime we're faced with some difficulty we feel that we've done something wrong. And although we might have the necessary skills to overcome the difficulty, we often start questioning and revising our work." He concludes, "Code reuse, libraries, sharing, and open-source are very important to software engineering, but we should be careful to not enable the belief that programming should be as easy as gluing things together."
From personal experience and from mentoring beginners I noticed that when using tools that allow us to reason within our intuition, anytime we're faced with some difficulty we feel that we've done something wrong. And although we might have the necessary skills to overcome the difficulty, we often start questioning and revising our work." He concludes, "Code reuse, libraries, sharing, and open-source are very important to software engineering, but we should be careful to not enable the belief that programming should be as easy as gluing things together."
Too Late (Score:5, Insightful)
"Code reuse, libraries, sharing, and open-source are very important to software engineering, but we should be careful to not enable the belief that programming should be as easy as gluing things together."
That is the management view of programming and a major corporate goal. This way it reduces the skills needed to complete the task, and hence you can pay less for the less skilled laborers.
Why do you think the average salary of a Windows Admin is lower than that of a Unix/Linux Admin? Because Microsoft pushed the "we've made it simple, just push the button" marketing drek and aimed it squarely at the management crowd -- who bought it hook, line and sinker.
"They made it easy, so I shouldn't have to pay you as much because anyone can do it. I'll just hire some kid with the latest MS cert..."
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Too Late (Score:4, Informative)
If MS made their software easy enough to use that a low skilled person can do it, isn't that a good thing?
Only for Microsoft and their Partner when stuff breaks and you have to bring in experts because it's really foobar'd up the wazoo, so much so that only hands-on work by MS can solve the problem - on and it comes at really high billing rates too.
Re: (Score:2)
Re: (Score:3)
I am not making any claims about how hard or easy or how much skill is required to be a windows admin. All I am asking is this:
Scenario A: It requires 10 highly skilled admins to do job X.
Scenario B: It requires 2 highly skilled admins and 8 low skilled admins to do job X.
Isn't Scenario B better? The person I originally responded to seemed to be suggesting that Scenario A was better because it meant 10 people were highly paid rather than just 2.
I would say it depends on what X is.
My primary point was that X being Microsoft Exchange or any of the other big tools that Microsoft markets towards Scenario B is ripe for problems since those low skilled admins will create a lot of problems that fewer higher skilled admins would have prevented.
And the fact that you're comparing 10 high skilled versus 2 high skilled plus 8 lower skilled also highlights the problem because in reality the comparison would more likely be:
5 high skilled admins to do j
Re: (Score:3)
I would say it depends on what X is.
Of course it does
My primary point was that X being Microsoft Exchange or any of the other big tools that Microsoft markets towards Scenario B is ripe for problems since those low skilled admins will create a lot of problems that fewer higher skilled admins would have prevented.
Sure there are lots of jobs like that. My job is like that.
And the fact that you're comparing 10 high skilled versus 2 high skilled plus 8 lower skilled also highlights the problem because in reality the comparison would more likely be:
5 high skilled admins to do job X.
1 high skilled admins and 40 low skilled admins to do job X.
1 good high skilled admin is usually worth at least 10 low skilled admins.
Sure. For jobs like that you just don't hire low skilled workers, because it is not economically efficient. But if you can make a job a little easier, you should be able to hire at least slightly less skilled workers or at least fewer workers of equal skill.
All I am saying is that if you make a job easier to the point where it is actually easier (i.e.not just perception), that is a good thing. This is in contrast to the suggesti
Re:Too Late (Score:5, Insightful)
Right up until you meet the limits of what a low skilled person can do.
And then you can quickly get into uncharted territory which requires much more understanding.
Sure, that low skilled person can do "some", "many", or possibly even "most" of the tasks. And they can also drive you off a cliff through lack of understanding.
Anybody who has ever dealt with outsourced admins who can follow a script can tell you that when those people go outside of the script they will become utterly useless, if not outright dangerous.
And at that point, you're deeply screwed if there's not someone around who actually understands the rest of the stuff. It's not pretty to watch some noob with a little knowledge completely screw up a corporate environment.
Re: (Score:2)
Right up until you meet the limits of what a low skilled person can do.
And then you can quickly get into uncharted territory which requires much more understanding.
Sure, that low skilled person can do "some", "many", or possibly even "most" of the tasks.
If your entire shop is full of low skill people you are screwed anyway. If your daily work is simple enough that low skill employees can do most of the work, then that's why you keep senior employees around. Their job, besides doing daily work, is to jump in when the newer, less skilled employees run into problems they can't solve and also to train said lower skilled employees when those situations arise.
Re:Too Late (Score:4, Interesting)
Right up until you meet the limits of what a low skilled person can do.
There is always a limit to what a person of any skill level can do. All I am suggesting is that raising that limit is a good good thing, even if it means accomplishing a task pays less money.
For example I don't think it's a bad thing that any idiot can look at google maps and have a very accurate set of directions. I think it would be worse if getting good directions required a very highly skilled and well compensated cartographer.
Re: (Score:3)
Re: (Score:3)
There tends to be a perception amongst the windows/mac and web 3.0/mobile crowd that complex things be made simple at any cost, even if the result is only the appearance of simplicity, just to give newbs the impression they understand more than they actually do.
Re: (Score:3, Interesting)
I always like "update holidays" in our company.
The Windows Admins run around sweating, clicking this clicking that, checking there, trying thing a couple of time in the test environment, then switching to live, etc.....
I recline in my chair, open a terminal to run the update scripts I have tested beforehand, and a Media Player to watch some TV shows while they run. The thing is, the "little things" I have to install on the Windows machines are also scripted the same way, while the "Little things" the Window
Re: (Score:2)
Knives are very easy to use, but that doesn't mean I'll let some random bozo perform surgery on me.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I guess what I am asking is for you to think about what I am saying in a more meaningful way rather than the trivially incoherent way that you have decided to interpret what I said.
If I asked "What came first, the chicken or the egg?". An answer one might give is "Obviously the egg came first because lots of prehistoric animals had eggs before chickens ever existed". I am asking you not to give this answer.
Re: (Score:2)
Re: (Score:2)
You seem to be making a lot of very narrow assumptions interpreting what I said. I am not going to go into all the logical fallacies you are probably making with your reasoning, because I don't feel it's worth my time, and I don't like make assumptions about what people are thinking.
But I'll offer up a few hints...
1. The fact that not every high skilled person is high skilled in every possible skill, does not imply that every high skilled person is/ can be only skilled at one thing.
2. The skills that "peop
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
The Principle of Charity [wikipedia.org] is the first lecture in any decent university-level critical thinking course. It should be required knowledge for any Slashdot comment thread.
Re: (Score:2)
Their software can be easy enough to use, that's good, but the creation of the software should not necessarily be easy to do. The tieing together of complex parts does not create a complex product that's well designed. A turbo engine duct taped to a bicycle.
Re: (Score:3)
First of all I didn't say that MS's software is easy to use. I merely suggested that *if* MS software was easier to use (requiring less skill/effort for the same result), that that would be a good thing. Chill (the person I was responding to, seems to be suggesting the opposite is true (i.e. it's better if the software is harder to use).
Second of all, I would say that the job of software is precisely to make hard things easy. If the goal was to create a jet powered bike, then good software would generat
Comment removed (Score:5, Interesting)
Re:Too Late (Score:5, Insightful)
Why do you think the average salary of a Windows Admin is lower than that of a Unix/Linux Admin? Because Microsoft pushed the "we've made it simple, just push the button" marketing drek and aimed it squarely at the management crowd -- who bought it hook, line and sinker.
"They made it easy, so I shouldn't have to pay you as much because anyone can do it. I'll just hire some kid with the latest MS cert..."
It's more complicated than that. Salaries are lower because there's a herd of "kids with the latest MS Cert" that also bought into the "it's easy" line of thinking. It's not, but it sure looks that way. Managers are always looking to save a dollar of course, and many of them don't have any ability to distinguish talent from dreck. Even after they hire the dreck, they might be forced to put up with it as the "new normal".
It stems from a mentality of measuring salaries, but not measuring consequences of fucking up. Let's say John knows what the hell he's doing, but is paid $120,000 a year and rarely screws things up. John managed to increase productivity and save $50,000 last year through some innovative thinking. Joel is paid $50,000, but is constantly fucking shit up. Just last week Joel took down the network through one of his changes, and cost the company $20,000 in lost productivity. Over the past year Joel has cost the company approximately $200,000 in lost productivity due to his own point/click mentality and a management team that encourages this rather than learning and risk management.
So John costs $70,000 a year, and Joel costs $250,000 if you add up all the costs and savings from each. Yet if you only look at salaries, it looks like John should be replaced with 2 Joels, at a cost savings of $20,000!
So part of the problem is not measuring employees true worth.
Re:Too Late (Score:5, Funny)
There should be a moderation category "Scary".
Re: (Score:2)
Re: (Score:2)
Management wants stuff that works and costs to be low. They may want a Windows box or Mac on their desk, but they don't care what's running on the servers in the rack.
Re: (Score:3)
In my country both get payed the same, actually MS jockeys a bit more as they are rather rare. No one really wants to administrate such systems.
Re: (Score:2)
major corporate goal
Is there a technical reason why this shouldn't be a goal? I've spent the better part of my software career in making systems "as easy as gluing things together." Granted, I have written myself out of a lot of jobs, but I work for interest in the system and making something, not to give myself a job.
Re: (Score:3)
A shallow understanding of the way some things work is necessary to being productive. If a library has a good API I can use it's functionality effectively without understanding exactly how it works. There have been plenty of bad libraries with bad APIs that have forced me to learn exactly how they work, but I wouldn't consider this effective use of my time.
Some things are very important to understand in detail, and some things are not.
In fact part of the art of writing a good library or a good API is maki
Oh you mean you want unintuitive code (Score:2)
Like this
X 3 3÷9 Y DATA[DATA] A comment
I really don't mourn APL's passing.
It is nice to see that programming as a discipline has reached the point where it questions it's great successes.
Re: (Score:3)
I've known a lot of brilliant assembler programmers and I have to admit, I've always admired them for their skills. Even so, I can get a whole lot more done than they can us
Re: (Score:3)
The key is once you get a good knowledge of assembler, you stop using assembler as a general purpose tool and only use it were it would benefit.
Back in the day ham radio exams in parts of the world required building a functioning radio from supplied parts. You had to know how a radio worked, in the abstract.
That doesn't mean that once you have that knowledge you forever build your own radios from unassembled kit.
Re: (Score:2)
Re: (Score:2)
abstracting solutions to problems
I work on real time control. The basic for of every piece of software follows the same pattern for the last 60 years.
1 read (measure temperature, water level, etc)
2 evaluate (f(13cm of water, at 90c) = valve opening angle = 17.7 degrees - through some set of complicated functions and lookup tables)
3 output (writing 0x418d999a to location 0xFFBEAD408)
4 wait for timer
5 go to 1
The solution has been abstracted out for about 50 years now. The hard part is knowing not to optimize out &0x418d999a = 0x
Re: (Score:2)
I don't think anyone is saying that you should have N levels of abstraction in software designed to control a single servo from an embedded computer. There is a time and a place to be abstract, and a time and place to be explicit.
That said, there are benefits to software abstraction even in some low level code. Abstraction allows you to reuse logic that would otherwise be duplicated. All that duplicated logic needs to be tested and maintained.
Rather than hard coding all this stuff you could do something
Turn in your type-ball! (Score:2)
Harumph! If that's the way you feel, so be it. But please turn in your type-ball to the TA.
Re: (Score:2)
If I do that what am I going to use in my Selectric ?
Re: (Score:2)
Re: (Score:2)
I prefer to imagine he's such a dedicated programmer he cannot bring himself to insert unbalanced ' characters.
Re: (Score:2, Insightful)
Yeah, only people who speak perfect english can ever be credible.
Fuck Einstein, Curie and all those stupid Greek philosophers.
Re: (Score:2)
If you can post a back arrow here be my guest. I suspect I was writing APL code before you were born and probably stopped before you learned how to talk.
This message brought to you by.. (Score:4, Insightful)
Researchers found that if they made a test deliberately hard to understand, those taking the test would exhibit greater understanding after solving it than those who were presented with a more intuitive wording of the same problem.
Paid for by the society of project managers and business software analysts.
Specialization (Score:4, Insightful)
Code reuse, libraries, sharing, and open-source are very important to software engineering, but we should be careful to not enable the belief that programming should be as easy as gluing things together
This is the wrong conclusion. Most of the time, we should give preference to tools and practices that have already become best practices, without necessarily questioning each one every time. Of course, there is room for challenging best practices and libraries, but that's for people who are interested more in the best practices and libraries, than for the people trying to use them to create something useful to end users.
You don't need to know how to repair a car to drive one. The guy who repairs your car doesn't need to know how to build a motor or a transmission, only how to install them. The guy who assembles the motor doesn't need to know the finer points of metallurgy. The guy who refines the metals doesn't need to know the finer points of mining. Each of these stages of production can have their own issues that need to be resolved, but the guy driving the car needs to worry only about staying safe on the road and reaching his destination.
Programming should be the same way. I shouldn't have to debug the IP stack to make my program connect to the Internet, nor should I have to reinvent build systems to produce a product.
Specialize!
Re: (Score:2)
I agree with your general sentiment, but I would say that some amount of knowledge of levels just above and just below your own level is helpful or often necessary to do a job at a particular level.
Using my own example of a computer system:
Re: (Score:3)
Of the two, would you prefer to have a mechanic or a non-mechanic drive you to the other side of the country?
Re: (Score:2)
Clearly, you and I drive different kinds of cars. I never would even think to ask a potential travel companion of they knew how to fix a car! I would focus instead on ensuring that the car is in good running condition before the trip, and ride with the people I'm most interested in riding with.
The analogy holds. If you choose good quality software components, you don't need to have someone on-site who understands their inner workings, just the interface.
Re: (Score:2)
If there are no leaky abstractions [c2.com].
Re: (Score:3)
I've noted that businesses that have historically shown high growth and apparent long term stability seem to be looking for "T-shaped" employees. These are employees who know a little about a lot (a wide horizontal) and a lot about a little (a narrow vertical). Specialization is good, but you have to know enough to be able to respecialize in anything else quickly, which means dabbling in a bit of everything so that it's at least familiar.
Basically, a jack of all trades AND a master of one.
To use your anal
Re: (Score:2)
I've noted that businesses that have historically shown high growth and apparent long term stability seem to be looking for "T-shaped" employees. These are employees who know a little about a lot (a wide horizontal) and a lot about a little (a narrow vertical). Specialization is good, but you have to know enough to be able to respecialize in anything else quickly
Well said.
Re: (Score:2)
The trend in IT over the last 30 years hasn't been to specialize, it has been to dump every job on one poor slob, work him 100 hours a week and tell him to be grateful because there are a billion people in India who'd be glad to do it for a tenth the price.
I've done I.T. support contract work for the last ten years. My contracts have prohibited me from working more than 40 hours a week. I also specialized in cleaning up the messes left behind by a billion people from India who get paid a tenth of what I earn. This poor slob is laughing all the way to the bank.
Re: (Score:2)
This poor slob is laughing all the way to the bank.
I'm glad for you. I've done the outsourced code "integration" work as well.
It got me all the way to the bank alright, but I sure as hell wasn't laughing.
Correct as far as it goes. (Score:2)
This is a consideration for students and other people involved in learning a new language or skill set. In that case, yes, it makes sense to make the student work somewhat harder (within reason) to figure it out
On the other hand, in a business context, you're not trying to develop understanding; you're trying to accomplish a specific task as quickly, easily and cheaply as possible. In that case, intuitive presentation of the problem is desirable and fostering development of deep understanding may be neither
Odd title (Score:3)
A better title might be "Why Hipster Coders Shouldn't Think Super-High-Level JS-Framework-of-the-Month Calls Mean You're a Good Programmer"
It's hard not to extend this to a #kidstoday rant, and I'm by no means arguing to go back to assembly, but at some point forcing large amounts of programming to the lowered-barrier of entry just reduces the percentage of folks who actually know what they're doing and can critically analyze the situation.
Re:Odd title (Score:5, Informative)
Yeah, I always found coding (and especially debugging) required a level of intuition ... precisely because it was more than just gluing pieces together.
I understand you don't want to rely too much on intuition, because it's hard to sound like anything other than voodoo, but sometimes the voodoo is still a real thing.
I worked with someone years ago who liked to go on about how everything should be abstracted and pretty/elegant according to whatever was popular that month. He read the books and magazines incessantly, and wouldn't shut up about them.
The problem is he often wrote shit code he couldn't maintain or debug because he'd abstracted things so much it was impossible for him to follow his own code, or know where to look when things went wrong. A small enhancement request left him squealing how the code wasn't designed to do that and he'd have to rebuild it. Meanwhile the rest of us went "so, all of that is in here, and if I just nudge this a little it's all done".
I'm sure he got better over time, but for someone who was so loudly a proponent of the latest language theories and methodologies, he never seemed to understand how his neat intellectual model in no way translated into maintainable, readable, or sometimes even useful code. But his insistence on following all of these things usually had the result of him making absolutely terrible design choices.
These frameworks and methodologies sound awesome on paper, but you can still use them to write complete garbage code which is brittle, inflexible, and often completely wrong for what you're trying to use it for.
Whereas the guys who learned to program and debug without the syntactic sugar and frameworks to build upon, those guys tended to have a bigger picture view of the pieces. Which means you can zero in on where you think it likely went sideways instead of staring blankly wondering why your monument to methodology is now a teetering mess you have no idea where to begin with when there's a problem.
Re:Odd title (Score:4, Interesting)
Re:Odd title [over-abstraction] (Score:2)
I've sometimes been accused of doing something similar. Good abstractions allow one to be productive by not having to micro
Re: (Score:2)
My problem is with the strongly opinionated frameworks. You know, the ones where you use framework 'X' and now you have a 'X'-website or 'X' application? Where the framework's author makes the majority of architectural and project organization decisions. Sure, they make 80% of the common usage patterns easy, but that almost always results in making 10% of what's left hard and the remaining 10% near-if-not impossible.
In a world where the programmer makes the rules, this is fine - they can find some awkwar
Re: (Score:2)
Pass me the glue (Score:2)
Was this a dig against code.org? (Score:2)
>> we should be careful to not enable the belief that programming should be as easy as gluing things together
I just helped my daughter do the princess-themed exercises on code.org. Code.org is ALL about "gluing things together" and issuing a "computer science" certificate at the end. Is this post Facebook's dig against code.org or this just one random guy?
Depends on what is meant by "intuitive" (Score:2)
I think the main problem is that by "intuitive", a lot of people mean "sloppily glossing over distinctions as if they don't matter". Sometimes people try to simplify problems by treating new or difficult ideas or operations as if they're like other more common things, but this leads to problems insofar as those things actually differ. Intuition is hugely important and valuable in problem solving, but your intuition doesn't tell you the truth if you've trained it by thinking of things as being something ot
When something else does the hard work for you... (Score:2)
... you don't become good at doing it.
Wow, news at 11, guys.
Good find, Poor Understanding (Score:2)
There are a couple outcomes of this that I don't think they quite understand correctly:
1) I'm not sure whether we're really using a different part of our brain here but just having to dig deeper into the problem. The more time you have to spend figuring out how the code works to then find how it is not working the more you will understand that code. That's not a leap of imagination there it's straight cause and effect. As it is this inherently works its way into a new developer's role in a new company. Your
the triumph of perl (Score:2)
Or maybe there was a culling (Score:3)
For instance I really hate APIs where you have to have this huge pile of boilerplate with all kinds of factory classes pooping out this and that that you assemble into something that every other person using the API will do. Maybe it gives you a better peek into the internals but I would rather some kind of Init or Create function that gives me the end product that I and every other programmer wants. All that boilerplate might make my code look intimidating and keep the weak minded away but it didn't make me a better programmer by any amount to be worth the wasted time.
OMG! The Conservatives Are Right! (Score:2)
Right, be tough on them, makes them perform better. Except, maybe just in a statistical significant manner. And maybe a lot less people solved it if you made it deliberately hard. And maybe they understood it better because they spent more time on it.
Code everything in assembly (Score:2)
If you need a port, hire me to write it for your different CPU because it's already in my head as I had to have a deep understanding of the problem before I could write a solution in assembler.
True (Score:2)
I do find that easy interpreted languages that mostly do right thing tend to make you lazy in understanding.
Try for example the following two in python
a=[1,2]; b=a; b=b+b; print a,b
vs
a=[1,2]; b=a; b+=b; print a,b
Results are actually different, even if they should "intuitively" be the same. I found that after spending 3 years of hard coding in C++ made me appreciate what exactly is going on under the hood much better, even for python.
Re: (Score:2)
you forget there's an industry around designed to make things harder, that';s how they get paid.
If you can;t be part of the solution, there's good money to be made being part of the problem. Hence Scrum.
Re: (Score:2)
Having worked in a 10-hours-a-week-in-meetings company, I kinda like the less time wasted by Agile.
It is supposed to turn the manager into a problem-solving facilitator to the team instead of a controlling boss.
Sadly, most managers have an ego-problem, causing them to prefer span-of-control over productivity.
Agile was created to give managers a cool, hip buzzword to tack on their resume, while not being too disruptive to the workers.
Re:Glueing things together is how I teach OO desig (Score:4, Insightful)
C weilding academic to me
Say what? I don't know too many (computer science) academics who'd touch C with a ten foot pole. Those of us who use C do it for real work (and like it/won't get off it).
If I want to live in an ivory tower I'd either a) use the latest theory compliant language/compiler du jour or b) refuse to code at all since that is an implementation issue, and instead pontificate on what is missing from latest language.
Re:Glueing things together is how I teach OO desig (Score:4, Interesting)
That's my experience as well, at least, as of the middle 90's. Why use a mainstream, commercial language, when you could use a theoretically complete one? One where they recognize that features like "output" and "input" are dirty exceptions that spoil the purity of your program when you're trying to get a good hard proof using Hoare logic.
Better not clutter up the syntax either by using confusing, pre-existing symbols to form constructs, not when you can add whole new symbols requiring a special (APL) keyboard!
I remember having a TA once challenge me - I had written an algorithm to operate iteratively, rather than recursively, because I had noticed the program would run out of memory if I did it the other way when fed large data sets - because to him, recursion was theoretically perfect and not using it was a personal affront. The fact that my code worked and his crashed after 4-5 minutes didn't matter.
To paraphrase a professor of mine, "There's absolutely no reason for a computer scientist to use a computer."
This sort of attitude was pretty rampant all throughout my college career, fairly startling having already been employed in the industry for some years prior. No concept of real world usage at all, or worse, some strange bias against it.
Re: (Score:2)
CS is a large academic area. It covers a range from CS academics who use C, assembler, as well as functional language purists, and even those who don't even use computer languages.
I had a TA ask me once why I had spend so much effort making my Lisp program completely recursive instead of using PROG or PROGN, and I said I thought that's how it was supposed to be done. It was a good academic exercise though to think about how to program in a different way from normal procedural programming.
Re: (Score:3)
I remember having a TA once challenge me - I had written an algorithm to operate iteratively, rather than recursively, because I had noticed the program would run out of memory if I did it the other way when fed large data sets - because to him, recursion was theoretically perfect and not using it was a personal affront. The fact that my code worked and his crashed after 4-5 minutes didn't matter.
Tail recursion optimization usually takes care of problems like that, assuming the problem was running out of stack.
Re: (Score:2)
Holy shit, that's scary! Doesn't the school you're thinking of teach compilers, embedded computing, or high-performance computing?
Re: (Score:3, Informative)
If your C code leaks memory, you don't know WTF you're doing -- which is exactly why a department of CS professors who don't use C is so damn scary.
And I don't give a shit if you think you don't need to use pointers; that's fine. You still need to understand them so that -- if for no other reason -- you understand why in Java or C# not every IEnumerable should be a List.
Also, if you think a high-level language will save you from remote code exploits, I've got a bridge to sell you.
Re: (Score:2)
that leak memory like a sieve
I've worked on a number of very large software projects in C and have never had to do dynamic memory allocation. In fact, it's never been allowed.
Re: (Score:2)
Say what? I don't know too many (computer science) academics who'd touch C with a ten foot pole
Donald Knuth, for one (albeit with a literate programming pre-processor).
Re: (Score:2)
I did not use C since 30 years, and C++ on,y sporadicly since 1999.
The companies I worked for make billions, yes, billions in earnings, with my Java code. (E.g. EnBW.com)
No idea what your 'real work' is supposed to mean.
Re: (Score:3, Interesting)
I knew someone in late 90s who was upset that we weren't using Java for a highly complex embedded system used for medical work, and instead used something archaic like C++ (seriously, he thought it was archaic in its heyday). We'd explain to him that we can't throw out all the work and start from scratch without spending years, that Java at the time was terribly slow, that there were no distinct advantages of changing or reductions in complexity, etc. But it was his first job after his master's. Later on
Re:Glueing things together is how I teach OO desig (Score:5, Insightful)
Careful, C++ has its own share of unintuitive weirdness. Take the following example:
This prints out:
Nothing unusual there, right? std::map iterators are non-invalidating and you're not touching "iter", so it should be (and is) remaining the same. But what if we use reverse iterators (and correspondingly switch the side of the iterator we do the insert on)?
Despite sounding like the same sort of thing ("iterators"), forward and reverse operators have some very different properties in a key area. A non-invalidating forward iterator will always remain pointing to the exact same element regardless of what happens with other parts of the container. This does not apply to reverse iterators, as they are implemented in a rather unintuitive way - they actually point to the element after the element that they pretend to point to, and so changes to other elements can change what they appear to point to.
There's a lot of things like this in C++ that can slip past a person for years before it actually bites them. Don't get me wrong, I love C++ and think C is a rather dangerous language (from a memory safety standpoint) that requires that its authors reinvent the wheel over and over again. But C++ does have some weirdness in places that can pose hazards. For example, from a more beginner-perspective, what percentage of users have at one point been frustrated by trying to understand why a pointer in one of their classes is getting freed unexpectedly, due to not realizing the dangers of the implicit copy constructor/assignment operator when it comes to pointers? I bet that's bit almost everyone at some point in their career. Sure, you can "reason out" that that would happen, but most people learn it by being bitten once or twice.
Re: (Score:2)
Re: (Score:2)
Or in C, "x = ++x++ + ++x++;"
Re: (Score:2)
But C++ does have some weirdness in places that can pose hazards. For example, from a more beginner-perspective, what percentage of users have at one point been frustrated by trying to understand why a pointer in one of their classes is getting freed unexpectedly, due to not realizing the dangers of the implicit copy constructor/assignment operator when it comes to pointers? I bet that's bit almost everyone at some point in their career. Sure, you can "reason out" that that would happen, but most people learn it by being bitten once or twice.
This is why I vastly prefer Qt with QObjects that disable the copy constructor, structuring the application like a hierarchy with managers that act as resource owners. Consider the pot at a poker table, you could model it as players pushing money into the pot and the winner grabbing it. Screw up your winning logic and two players might try to grab the pot (double free). But if you model it with a dealer collecting the bets and handing it out to the winner you have a single resource owner controlling the res
Re:Glueing things together is how I teach OO desig (Score:4, Interesting)
C++ doesn't have "weirdness," C++ has bad design. Literally anything that you might think C++ would be good for is better solved by either C#, C, or a combination of both.
Re: (Score:3)
Literally anything that you might think C++ would be good for is better solved by either C#, C, or a combination of both.
This makes literally no sense. With minor caveats, C++ is C with more stuff. Even if you only use (say) namespaces or a modest amount of ad-hoc overloading, C++ is a better C.
The main cause of problems with C++ is using it as an object-oriented language, but you'd have the same problem in C#. What Alex Stepanov rightly said about Java [stlport.org] equally applies to C#: "I spent several months programming in Java. Contrary to its authors prediction, it did not grow on me. I did not find any new insights - for the first
Re:Glueing things together is how I teach OO desig (Score:4, Insightful)
That's fine for your own projects, but the problem comes in with dealing with other's code. Everyone seems to have their own subset of C++ they like to use. The problem is that everyone's subset is a bit different. So you have to be at least aware of everything in C++, just so you know it when you run across it. (once again, this doesn't apply for your own projects)
Re: (Score:2)
Re: (Score:2)
This, times 1000. I love C++ and use it professionally, and prefer it to a lot of languages - but if someone tells me they're a C++ expert I'll laugh in their face unless they're Stroustrup or Herb Sutter or someone like that.
I've been using C++ seriously for more than 5 years, and the more I learn about C++ the less I know. A few of my favorite are "what's the correct way to call swap" (and ADL in ge
Re: (Score:2)
The KISS principle always applies and has not become obsolete.
Re: (Score:2)
The thing is, iterators are presented as the preferred alternative to container indices or pointer incrementation over a container. Both of which are modification safe. So you either need to have them match the capabilities, or accept that they're not an alternative.
Re: (Score:2)
Not really OO design but modular design. OO is just a way to this end, functional programming is another one. And you can be modular in C, too, there are plenty of excellent C APIs out there, starting with the libc iteslf.
As for the Lego brick metaphor, it is very theoretical. In practice, abstractions leak. Which mean that to use the brick properly, you need to know what's inside the brick. Like, for example, garbage collectors that should manage the memory for you and yet, you need to help it in some case
Re: (Score:2)
Problems in the real world typically don't rephrase themselves for the benefit of the person trying to fix them.
Doing so in a test does a dis-service to the student.
Re: (Score:2)
But the usefulness of OO comes from modifying the behavior of objects not just replicating them.