views:

1581

answers:

16

In programming, as many professions, there are mistakes you'll make now that you may not have made as a beginner. For instance, consider pointers:

In C++, is there any difference between arrays and pointers?

The beginner will say yes, they are two completely different concepts, and treat them as such.
The intermediate programmer (having learned that arrays are pointers internally) will tell you no, they are the same thing, and may miss some crucial bugs by interchanging them all willy-nilly.
The expert, however, will again say they are different things (ex. see here or here).

What other questions/mistakes are like this?

+10  A: 

Should I use PHP to develop a small web application?

The beginner will say yes, since PHP is widely deployed and easy to get started with.

The intermediate programmer will say no, since the language has an inconsistent (some would say ugly) syntax, and is notorious for security issues when not configured properly.

The expert will say yes, since a PHP environment can be configured to be relatively secure and the language supports well-structured code if the developer knows how to organize it properly. Most importantly, the project can be completed quickly and deployed with minimal hassle.

ElectricDialect
"the language supports well-structured code if the developer knows how to organize it properly" This is true for any language except malbolge, brainfuck, and their kin. Some languages don't require you to be an expert in order to write reasonably secure and well structured code, php is not one of those.
Justin Smith
i tell other people to use php, because I don't have the time or energy to help them set up for a language that isn't "plug and play". or explain to them why their non-php app doesn't work like php.
Tor Valamo
-1: The expert would not be using PHP.
Ben M
Any "expert" that deliberately uses PHP is either an unknowledgable expert (see n00b) or dumb.
Jonas Byström
+3  A: 

Take a look at this code:

x = x + 1

As a beginner, I said that this is mathematical nonsense since there is no x which is it's own successor.

Afterwards, I got used to this notation and intuitively interpreted it as an assignment (x becomes x + 1)

Now I'll again say it's mathematical nonsense and therefore stick to functional programming, where immutability counts.

Dario
Programming is not *pure* math, don't treat it as if it was. (I'm not saying that functional programming is bad!)
Wallacoloo
@wallacoloo: It is. Just because it has a succinct notation for emulating unpure operations, don't treat it as if it wasn't ;)
Dario
@Dario: In a sense you are right, programming is built upon math. Unfortunately, my definition of math has been highly mutilated by school, so it's not as obvious to me as it should be :( But in a way you're saying you should treat something like Python as if it were really C, just because it's built upon it. A major point of abstraction is to allow the user to think in a different, more relevant manner. So my suggestion to you is to think of programming as programming, and not anything else.
Wallacoloo
@wallacoloo: Yes, in a sense, you are right too. Abstraction is absolutely cool. But often, the *different, more relevant manner* is actually distracting from the true core of the problem, which is, most of the times, pure.
Dario
This is not defining x to be equal to the expression "x+1" at all times, like x=x+1 would in math. There is a difference.
Cam
an expert will realize that this is equivalent to `x++` and save two chars
Jason
@Jason: Or `x += 1` in some languages, which still saves you one character.
JAB
@dario @wallacoloo - EVERYTHING everything everything EV. ER. Y. THING. is pure math. There is nothing that exists that is not pure math.
Jason
@Jason Can you define a set that contains all sets. Would it contain sets that are defined to not be members of other sets?
csj
This proves again how good is Pascal for educational purposes. In Pascal you would have written the above code as `x := x + 1` (`:=` is assignment) or as `inc(x)`, and everything would have been clear from the beginning.
Cristian Ciupitu
+2  A: 

In C and C++:

const int* vs. int* const

The beginner will simply not use const.

The intermediate will write const int* and, giving themselves a false sense of security, may accidentally overwrite the pointer (for instance, the common mistake of = instead of ==)

The expert will know that const int* is a mutable pointer to a constant value; int* const is a constant pointer to a mutable int (to get a constant pointer to a constant value, use const int* const!)

BlueRaja - Danny Pflughoeft
Assignment instead of comparison **is not a mistake of the intermediate**... Unless you want to tell me I'm an expert ;-)
James Morris
Obligatory reference to C++ faq: [Read const from right-to-left](http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.5).
BlueRaja - Danny Pflughoeft
@blue: [Read C identifier syntax from the inside out.](http://stackoverflow.com/questions/1749531/help-on-typedefs-basic-c-c/1749698#1749698)
Roger Pate
+12  A: 

Not really a question, but a behavior

Over design and making ie quasi classes in OOP

The beginner try to use as little fancy design as possible, learning the ropes. Short way from A to B.

The intermediate developer will start to create more and more quasi classes and over design in every new project. Believing complex is better. Long way from A to B.

The expert has get to a point where most projects are re-writes of old projects and now skip the excess classes and design better knowing where to put the flexibility needed. Short way from A to B.

epatel
I agreed until the expert doing projects that are rewrites. Any "expert" knows not to redo old projects (except for extreme corner cases).
Wallacoloo
+1  A: 

I'm sure I'm not speaking for other developers, but at the moment I'm mostly working in a language I'm extremely comfortable in, doing tasks that I know how to do really well. Because of this, design and programming mistakes are significantly reduced, so I'm finding a rising proportion in bugs are due to simple typos. You could say there's a bug between my brain and the keyboard, i.e. my clumsy fingers.

ZoFreX
I find that neatly formatted code as part of a v.strict coding standard helps eliminate those typos that sneak through the compile phase.
logout
Many of them have been typos in the configuration files for the project, followed by ten minutes of wondering why my plugin hasn't properly initialised. Ideas for checking config files welcomed!
ZoFreX
A good IDE can eliminate almost all typo-related problems in code, especially for dynamically typed languages (eg. for Python, Eclipse + Pydev)
BlueRaja - Danny Pflughoeft
A typical PEBKAC situation :)
runrunraygun
+4  A: 

When it comes to fixing and finding defects/bugs:

  • Over-analysing

When you have enough experience in debugging(but not really enough), then even for the most simplest defect, you ignore simple solutions("No way..how can it be so simple") and keep on over-analysing and finding complex solutions. Sometimes though, finally, you end up with the initial simplest solution.

But as you get really experienced, you start repsecting simple solutions and understand the elegancy in simplicity!!

Suraj Chandran
+2  A: 

Using frameworks

The beginner will say "Definitely. They make everything much easier. I use it for everything. I can make a hello world app in ten seconds. I just need to ship it with this 150 mb framework. No problem."

The intermediate will say "I don't use them at all. How are you ever going to learn programming if you just copy and paste? Also it bloats things."

The expert will say "I use it in some parts of my application. But just a few selected modules, which I've slightly altered to fit my requirements and reduce bloat."

Tor Valamo
My experience has been that the beginner won't try to use them; there's too much learning curve. The intermediate will use them everywhere, and create a cruise ship where a bicycle would have fit. The experienced programmer uses but doesn't overuse, hopefully.
Dean J
@Dean I think intermediates are often more arrogant; so they don't use frameworks because they think they can program anything.
Wallacoloo
@wallacoloo: It might split up more than three ways, I think. :-)
Dean J
My experience is closer to @Dean J's as well. The beginner is often busy learning the language itself--no time for frameworks!
musicfreak
+23  A: 

The young coder writes simple, straightforward code to avoid making mistakes.

The wicked coder shows his knowledge and expertise by wringing out as much functionality as possible from each character of code.

The wise coder uses the language effectively, writing code that is clear, concise, efficient, and maintainable ... generally favoring clarity and maintainablilty after supporting wicked code.

Adam Liss
Sadly, most people never get past the "wicked" stage ;)
RCIX
@RCIX: In time, you can inflict wisdom on your developers by having them debug or enhance their old code. (Does that makes me a wise or a wicked manager?)
Adam Liss
Well said, Adam.
ydobonmai
And the coder who does not yet know how to code... uses vbscript. (Happy passover :-)
roufamatic
@roufamatic: Thank you for totally making my day!
Adam Liss
A: 
Difference between Class and Structure ?


EDIT:

First of all this is entirely language dependent. so may be someone don't want to agree with me.

Beginner:

Structure member are public in default and class members are privare in default. (I know only this difference at the beginning of my education.)

Intermediate: (Something like this)

  • A structure can't be abstract, a class can.
  • Classes are used for large amounts of data. Structs are used for smaller amount of data.
  • Classes could be inherited whereas structures could not be inherited.
  • The structures are value types and the classes are reference types.
  • A structure couldn't have a destructor such as class.
  • You cannot override any methods within a structure except those belong to type of object.
  • A structure couldn't be Null like a class.

Expert:

From OO perspective, there are no difference. From technical point, there can be many differences but that depends on the language. Ignore Structure.

NAVEED
Classes can be inherited, Structures cannot.The default access for a class is private whereas a structure's default access is public.See http://stackoverflow.com/questions/13049/whats-the-difference-between-struct-and-class-in-net for class vs structure in .Net
clyc
is there any technology defined in my above question ? And that is the point that I want tell. You provide me a question about .NET technology and I work in open source technologies like PHP and JAVA.
NAVEED
look at this http://stackoverflow.com/questions/1920849/difference-between-class-and-structure-in-php-and-java/1920901#1920901 and what about this http://stackoverflow.com/questions/1920849/difference-between-class-and-structure-in-php-and-java/1920870#1920870
NAVEED
what about this http://stackoverflow.com/questions/1920849/difference-between-class-and-structure-in-php-and-java/1920888#1920888
NAVEED
You won't find a unique answer unless you specify what language you're talking about, and exactly what kind of difference you want. In C++, the language difference between a class and a struct is whether default access is private or public. However, they tend to be used in much different ways, a class being used as a real data type and a struct being used as a bundle of data.
David Thornley
@David: and when someone ask you it without defining any language ? what about that question ?
NAVEED
@NAVEED: If you're a beginner, you answer it in whatever language you know where it makes sense. If you're an intermediate, you ask which language. If you're an expert in enough things, you might possibly narrow the possible answers enough down to be useful, but in a case like this won't be able to.
David Thornley
@David: It means that there are different answers by expert,intermediate and beginner. Now look at the topic of this thread(question). They asked such type of questions, therefore I mentioned this question which creates confusion. Then why downvote???
NAVEED
A class is a reference type, a struct is a value type. It is C#. Is this really different in other languages?
ydobonmai
@Ashish: You got another difference but also confused. And this thread is for those confused questions but I am surprised that why I am down voted. :)
NAVEED
@NAVEED, :-) Well, when you ask this question "What is the difference between class and struct?", you and the other person know which language you are talking about. I am not confused. I was just asking if this behaviour is any different in other languages from C#/Java as I dont know others.
ydobonmai
@Ashish: It is different in different languages. OK. Answer my question without questioning me. My question is "What is the difference between Class and Structure? Any confusion?"
NAVEED
@NAVEED: I think the problem is that you answered in an unexpected form, not pointing out that the different answers. Since I didn't downvote you, this is speculation on my part.
David Thornley
@Ashish: See my earlier comment for the difference in C++. In C and C++, there is no such thing as a reference type or value type, since objects of either type can be either.
David Thornley
People are downvoting but no one able to answer a generalised answer to my above question in this answer. Everyone asking which technology? hahahhahahah
NAVEED
Maybe they're downvoting because they don't see the connection between the question and one-line statement you posed and the topic at hand. Instead of being so smug about it, perhaps you could just edit your answer to explain in more detail what exactly you mean.
indiv
+10  A: 

A user calls and complains about an ugly bug he just discovered!

Junior: What? Bug? Where did it come from? Don't worry, we'll fix it quickly.

Experienced: Bug? What bug? Okay, it's a known bug, don't worry, we'll fix it soon.

Senior: What bug? All right, it's a known bug, don't worry.

Developer Art
Jedi: What bug? That's a feature!
j_random_hacker
+5  A: 

Dynamical memory allocation in C++.

The beginner won't know about it.

The intermediate will write code with memory leaks or without exception safety.

The expert will know the proper use of smart pointers.

dan04
The *expert* will know not to use C++! ;)
Mason Wheeler
It seems like the "intermediate" has been becoming more and more like the beginner D:
Wallacoloo
+1  A: 

The beginner will have heard of and maybe even used version control (CVS/SVN/git etc). They are only learning of build engineers and are hearing for the first time the concepts of release management. They also are reluctant to do frequent and regular checkins.

The Intermediate engineer will know more than one version control systems, know what build engineers do, know the value of logical commits, and are curious of DVCS like git and Mercurial and why they are useful. They will also know the value of clear and descriptive commit messages.

The expert engineer has lived through more than one manual merges (and will do everything in his power to reduce the need for merging), knows the pitfalls and uses of branching and merging, knows when to use SVN vs Mercurial, knows use of tools like Araxis Merge, and unless he is starving (and has already chewed and eaten his toes), will not want to work at a place that uses VSS for source control.

I know I am dating myself with this, but you don NOT want to use VSS.

omermuhammed
I give +1 to anybody who says not to use VSS. (ARGH! I *still* fight this on a semi-regular basis. Fortunately, I'm starting to win...except for a few pockets of resistance...)
JasCav
+21  A: 

Should I read the documentation?

The beginner: yes, I know nothing.
The intermediate: no, I know it.
The expert: yes, I know how much I don't know.

drawnonward
Also seems to apply to reading programming books in general.
BlueRaja - Danny Pflughoeft
Haha...this made me smile as I have just started devouring computer science and software engineering books lately as I have realized how little I actually know (and I want to learn more). Good answer!
JasCav
Documentation is the cyberspace fabric boredom is woven of.
Jonas Byström
+1  A: 

The beginner knows nothing of design patterns, so never uses them.

The intermediate can name every design pattern there is to know, and will suggest one of them as a solution to any problem - he thinks in terms of design patterns.

The expert will use a design pattern when it is called for, but this is the (fairly rare) exception rather than the rule - he thinks in terms of coherent units (such as modules and classes).

BlueRaja - Danny Pflughoeft
I would say that the expert will never build to a design pattern, but will notice them when they appear.
dash-tom-bang
+1 for understanding how people use design patterns! http://stackoverflow.com/questions/1820106/when-can-a-design-pattern-make-your-software-worse/1820830#1820830
Patrick Karcher
+7  A: 

The beginner will try to google for a solution in vain

The intermediate will not google and try to code himself

The expert will google the solution in no time (but then will spend time reading stackoverflow!!)

sambha
but then will spend time reading stackoverflow!! ... the new wikipedia...
FastAl
sambha
A: 

When you run into a bug in a framework your application is based on:

The beginner won't fix it, because it's difficult and they're scared to delve into framework code.

The intermediate programmer will dive in and create a large pile of code to replace the allegedly buggy framework component. They'll have fixed the immediately observed bug.

The expert will try to find a solution that works with the framework, not against it. Sometimes they'll leave the original bug unresolved when they know that to fix it will leave them open for more severe bugs down the line.

Peter
I think the expert would find an immediate workaround, but contact the framework authors with a bug-report and (if it's something he's paying for) request a patch.
BlueRaja - Danny Pflughoeft
Maybe, but if your bug is in something like .NET, for example, you might have to wait a year for an update that'd fix it. My point is that if a fix or workaround is not available, the expert knows that sometimes it's better to leave well alone than to make things worse through lots of busywork.
Peter