|
Excellent topic.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
It seems to me not only null is the problem, but programming knowledge in general.
Throughout my career I've seen very bad code by very "experienced" people.
Not just the young kids, but the old farts too.
It's so bad I'm now convinced that about 90% of the people are just plain bad at their job 
|
|
|
|
|
Because there's null to understand.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Nobody teaches to use a debugger, a real one at least. For my first months in the real World I debugged with printf - I did image analysis. Debugging imaging algorithms by printing 1024x1024 tables of numbers? I did that.
One of my dreams is to get a teaching position in CS. I will not let anybody out of the room until they learn to place breakpoints and use the watch window.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Depends on the definition of "young"  But, seriously, I see so many powers that be in a high tech company internalize their fears of mistakes by programmers who simply don't get the deeper meaning of a sort-of tri-state logic, so that when when you apply it correctly, you're going to get smacked by individuals who wallow in this fearmongering mindset. Thinking, "if I can't comprehend this to treat the information properly and make a mess, I'm going to force you into that same fear, so that I won't look incompetent and alone".
The real issue though, is the hiring policy. Like, who the ***k hired you, and worse, who made you the boss around here? Do you have more skeletons in the closet regarding your pretend-strong, feeble character?
Ok I digress. But if you lack the technical grid to understand what your responsibility is towards the state of a variable, you should really be looking for another job. No wonder IT systems have so many vulnerabilities.
|
|
|
|
|
This happens because young programmers learn (at first) languages like python, C#, or other high-level languages right away. Old farts like me have had to put up with C, if not even assembly language. At least on K&R, it is explained what a null pointer is, although my favorite chapter is the one where complicated declarations (which are not complicated at all) are described.
It's fine to learn high-level languages right away, but don't we want to take a look at how things work internally? Maybe with the help of the old, decrepit, and "very dangerous" C? I'm not saying to delve into Assembly ... C is sufficient.
I am always amazed when I see young computer science students get stunned when I tell them about the two's complement.
Old languages may be old and decrepit (though still widely used), but they would still be very useful for many people. To be picky, even high-level languages run on hardware whose principles are still those of John von Neumann's architecture, evolved or not. Many people would still have a lot to learn from "very very very ugly and dangerous" languages like C. And I don't find anything complicated or difficult to understand in malloc(0) either. It must be because I am an old fart.
Cheers
|
|
|
|
|
So true. I started with machine code and progressed to Assembler, and thence to high level languages. I still think C is the most elegant and easy to learn of all.
giulicard wrote: It must be because I am an old fart.
Ha, ha; you and me both.
|
|
|
|
|
Meh, because often it's a pain in the neck? Look at most languages and the various operators or functions built around 'null'. Then there's things like empty, not set, nothing, and default 'blank' types. Gets into a lot of fun, especially with databases and SQLs.
Speaking of fun, and a fun discussion, I had a young programmer use the three values of a boolean. I asked what he was doing. I said go get that switch on the wall to be 'not answered', lol. I'm a firm believer in two boolean values. If you're looking for 3 answers, use a different data type and clearly capture the intent. In my database designs, I leave no null values. Saves that pesky code, lol.
|
|
|
|
|
Because so many programmers do not understand pointers… or the fact that a pointer has to point to something/anything before you use it/dereference it.
If you understand pointers, then you know how Java/C#/etc deal with objects.
|
|
|
|
|
I don't understand the problem. People actually don't know what null is? Are you able to educate them on it once you get your jaw off the floor?
|
|
|
|
|
In my case, before retiring, it wasn't youth. It was aggressive ignorance by people who were "professional" developers for decades.
Hence my retirement.
|
|
|
|
|
i tried to explain that to C# students (back when i had a few) by saying that a "null reference" is a named/typed placeholder/slot for a pointer/reference to something which is not defined.
you, the programmer, have the "freedom" to create the named/typed slot.
and, that the common exception "null reference" was what happened after your running code made demanded/needed/required a defined pointer.
you have a favorite metaphor, or explanation ... i am all ears !
of course, now, Visual Studio/C# compiler (and ReSharper) are going to ... suggest a check.
and, now, C#/>NET has new Attributes for static Type analysis: [^].
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
See my leash metaphor further down
|
|
|
|
|
I have to deal with Microsoft employees not understanding null for dates or GUIDs, thereby actually making programming, especially if a database is involved, even more difficult.
|
|
|
|
|
Richard MacCutchan wrote: Do those of you who still work in teams find this is a common problem with younger team members?
Versus other problems by inexperienced (younger) persons in any craft?
I didn't get better with null until I burned myself so many times that I started focusing on it intently. Thus experience.
|
|
|
|
|
I didn't have that problem, but I did have a junior developer think that the font was causing a unicode problem.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
I have seen that.
'I loaded the file into my editor and I can't see the character!'
'Does your editor support unicode?...uh...Is your computer set up to display unicode?...uh...'
|
|
|
|
|
That whole futbal thing with "nil" muddies the water for me. Then there is the script thing with "nul" which is not "null", "NULL", or "nil".
C had it right, just compare to 0 and go on.
|
|
|
|
|
No. Where are you finding these people? It seems hard to get far in life without knowing what null is.
KNIGHT: The Knights Who Say Null demand a sacrifice!
ARTHUR: O, Knights Who Say Null, we are but simple travelers who seek an enchanter who lives beyond these woods.
KNIGHT: NULL! NULL! NULL!
ARTHUR and PARTY: Ooh, ow!
KNIGHT: We shall say NULL again to you, if you do not appease us.
ARTHUR: Well, what is it you want?
KNIGHT: We want... a :shipit: on this code-review.
|
|
|
|
|
The best concept I found to explain Java/C# object references to newcomers is to use a “leash” as the metaphor.
Just because you have a leash in your hand, does not mean there is a dog on the other end. The object variable/leash is in the null/no-dog state.
Many Java programming errors occur when multiple leashes are attached to the same dog. (And each leash holder thinks they have a unique dog!) [This is why immutable objects are a good idea]
A new leash is attached to your dog every time you call a method and “pass” your leash by value. The method can “pull” your dog around or stuff it with treats.
How do you free the dog so it becomes a stray so that the dog catcher/garbage collector can pick it up? Assign the variable/leash to null, of course.
You can also mix types in with cat leashes vs dog leashes. This can work into leashes as interface holders.
This works with C pointers to some extent. You can build on the metaphor to include pointer arithmetic.
This is partly a reply to BillWoodruff but I wanted the reply at top level as I always found this a great metaphor.
|
|
|
|
|
Besides my full time job as a developer I also teach Computer Science one night a week at a community college. My observation is that the focus for young developers/students is HOW to do things rather than WHY things need to be done. Having mentored many developers over the last 40+ years I always focus on the WHY, because once they understand the WHY the HOW not only becomes fairly obvious they find they often have multiple HOWs to choose from.
This is not unique to Computer Science, my 3 daughters are all teachers, High School English, High School Biology, and Elementary school. There is hope, perhaps slight and teacher dependent. The Elementary school teacher pioneered Common Core math in her school district and discovered kids she had taught math to that way in 1st and 2nd grade had significantly better performance in 4th grade. Of course, not universally, but sufficient to clearly see a difference.
|
|
|
|
|
Our office is moving to a location, way to far to me to commute every day (an additional hour and half to the existing two hours)...
So I will start to work from home most of the days, and the question is - for those doing it already - what are the important things for a productive home office?
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
|
|
|
|
|
Quiet is good, a comfortable chair and a good desk. A designated work area is a good idea, rather than lying on the sofa with the lappie on your chest. If you act like it's an office, then you work like it's an office. Dress smart casual - like you would in an office. It may sound weird, but what you wear affects how you think. Slobbing out in tracky bottoms and a T is comfortable, but it's also "slobby" - and your brain knows that so the inclination is to act like a slob as well.
A time lock on the fridge helps keep the weight down ... there is a lot of potential for snacking which is a problem. If you go to the kitchen for a coffee, ket a coffee and leave. Don't grab a sandwich, or biscuits - if you normally eat bickies at work, keep them in the office area.
Time management is also important: have "work hours" and "off hours" - and try to stick to them. Don't goof off in work hours, don't work in off hours.
And enjoy the commute! I didn't realize how much stress and wasted time was involved until I stopped doing it and started walkign ten paces to get to my desk. 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I have a separate room - check
Chair and desk (to be here in two days) are picked - check
Dress - was thinking pajamas... Reconsider it now (never was thinking of it, but makes sense)
Snacking - this is a real problem (just lost 20 kg in the last year and not eager to find it). Not sure how to solve it realistically... I have kids also at home at different times of the day... I may prepare the food just as I do for the office and close the door...
Time management - very good point! I will work on it...
Thank you for the tips!!!
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
