Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Early vs. Beginning Coders

zedshaw.com

Post reply on HN
Print view View original

151–160 of 178 posts

Re: Early vs. Beginning Coders

#151

Post by btilly »

WalterGR wrote: post #143
mdpopescu wrote: post #79

Earlier quoted context omitted.

I had a similar experience with Code Complete (I know most of what's in it but I have no idea when I learned it). I don't know if it's as basic as @schoen wanted but it might be close.

I don't know if it's as basic as @schoen wanted but it might be close. I remember Code Complete as being a guide for advanced developers on how to take their craft to the next level. Does my memory deceive me?

You will likely have seen advanced developers recommending it. But it is meant to teach routine daily stuff like how to name variables, lay out functions, why we want abstraction layers, and the like. And it really is aimed at people who may know nothing about code construction.

Re: Early vs. Beginning Coders

#152

Post by JoshTriplett »

schoen wrote: post #60

Is there a book somewhere that tries to set out all of the things that experts know about computing that they don't remember learning? (In Zed Shaw's conception, this might correspond to "learn computing the hard way".) I see his examples and other examples here in this discussion, and it makes me wonder about the value (or existence) of a very thorough reference. I've also encountered this when working with lawyers…

> Another example might be "if a field is included in a protocol and neither that layer nor a lower layer is encrypted with a key that you don't know, you can see the contents of the field by sniffing packets on the network segment". It might be challenging to find a citation for this claim!

The term of art here (as used in patent law, for instance) would be "person having ordinary skill in the art". Something like that (if you don't encrypt something in a network protocol, it can be sniffed) is "obvious to a person having ordinary skill in the art".

But yeah, that does make it difficult to cite sources for them. And in particular, it's difficult to throw the book at someone who doesn't take those things as obvious when there's no such book.

Another "obvious" thing that I don't know a citation for: it's impossible to store a piece of information in a binary such that it cannot be read by a person who has a copy of that binary. (Practical corollary: there's no such thing as a piece of information that's too secret to include in an Open Source driver, but that can be included in a binary driver.)

Re: Early vs. Beginning Coders

#153

Post by WalterGR »

btilly wrote: post #151
WalterGR wrote: post #143

Earlier quoted context omitted.

I don't know if it's as basic as @schoen wanted but it might be close. I remember Code Complete as being a guide for advanced developers on how to take their craft to the next level. Does my memory deceive me?

You will likely have seen advanced developers recommending it. But it is meant to teach routine daily stuff like how to name variables, lay out functions, why we want abstraction layers, and the like. And it really is aimed at people who may know nothing about code construction.

Okay, thanks. I read it cover-to-cover before I interviewed at Microsoft my senior year in college. But - like the developer in Zed's article - I must have forgotten. :)

Re: Early vs. Beginning Coders

#154

Post by loup-vaillant »

jordanpg wrote: post #54
loup-vaillant wrote: post #48

Earlier quoted context omitted.

> I would also recommend that beginners/early programmers learn 1 programming language really well That's a dangerous approach. The first language is very hard to learn, because, well, it's your first. And when you stick to one language, you easily conflate the syntax and the semantics. So when you learn a second language, you have to unlearn the syntax of the first, in addition to learn the genuinely different conce…

I just don't see it. No one would ever recommend learning Spanish and Mandarin at the same time, for any reason. All of the things you said are true, and yet the beginner has only so much time, so much patience, so much learning to do in one day. Given this, I see larger advantages to spending all of that time and energy in one ecosystem. There are many perspectives on, say, Java coding styles, patterns, and idioms.…

> I would further argue that you simply cannot (usefully) see the global commonalities and idioms among languages until you've been doing this for a while. Years.

That's assuming you are not shown the commonalities explicitly, and have to figure them out by yourself. A course on programming languages teaches just that, and it takes only a semester (possibly a brutal one, but still).

> I've not known any "experts" at 20 languages, ever.

Lucky you. I've never met any expert, period.

Anyway, expertise in a language is not interesting. You want to be an expert at programming. Then translating your thoughts in any language is easy —including languages you don't know.

My "expert at 20 languages" isn't really an expert in those languages. She's an expert at programming, and proficient in 20 languages. Personally, that's what I strive for. I'll leave language lawyering to the compiler writers. (I may write a compiler someday, but it will be for a simple language of my own design. I have no interest in cancerous horrors such as C++ —which by the way is the language I happen to know best.)

Re: Early vs. Beginning Coders

#156

Post by FigBug »

schoen wrote: post #60

Is there a book somewhere that tries to set out all of the things that experts know about computing that they don't remember learning? (In Zed Shaw's conception, this might correspond to "learn computing the hard way".) I see his examples and other examples here in this discussion, and it makes me wonder about the value (or existence) of a very thorough reference. I've also encountered this when working with lawyers…

I was recently working on a case and I need a definition of software library. Couldn't find one anywhere. So many of the basics of programming are undefined it makes arguing about programming incredibly difficult -- see every discussion of what a functional language is or strong vs weak typing.

Re: Early vs. Beginning Coders

#157

Post by sbov »

WalterGR wrote: post #140
amalcon wrote: post #132

Earlier quoted context omitted.

No; the correct answer in that case is "Why are you trying to do that?"

That's what pedants do. When I was a kid learning line number BASIC, adults answered my questions knowing that I'd figure out The Right Way before anyone hired me to write the code for radiation treatment devices. The tech community's obsession with "The Five Why's" is toxic. When asking questions, you always have to first prove that you deserve an answer. It becomes a process of trying to anticipate any potential re…

Dunno. If someone asked me how to get the bytes of a string, I would ask why. Not because theres The Right Way to do things, but because they might be doing things The Hard Way.

A why can reduce the amount of code written by 100%.

Re: Early vs. Beginning Coders

#158

Post by cbd1984 »

skrebbel wrote: post #109
jakobegger wrote: post #105

Earlier quoted context omitted.

I'd actually consider that kind of knowledge pretty advanced. Beginners (and early up to even junior coders) usually don't know much about the internals of their environment; they just use stuff. I'm always interested in the internals; but it's often surprisingly hard to find information on the internals. There are few books, and you'll often need to read lots of source code and specifications and reverse engineer th…

> I'd actually consider that kind of knowledge pretty advanced. For someone from a C background, that's not advanced: it's simply what strings are. The whole idea that characters aren't bytes may be very strange to someone who's only ever done C and C++. It's probably just as strange to them as the idea that there's any relationship between bytes and "the characters that make up a piece of text" is to someone entirel…

In Haskell, the facetious answer is simple:

    No instance for (Eq (a0 -> a0)) arising from a use of `=='
That is, functions aren't comparable (for equality, anyway), so the type system won't allow you to compare them.

The better answer is either "Look at their type signatures" or "See if they evaluate to the same values when given the same input"; the first is trivial, the second won't, in general, terminate, so you need a more nuanced conception of "equality" to apply in this instance. This is non-trivial to come up with.

Kent Pitman has an interesting essay on this problem from a Common Lisp perspective: "The Best of Intentions: EQUAL Rights—and Wrongs—in Lisp"

http://www.nhplace.com/kent/PS/EQUAL.html

Re: Early vs. Beginning Coders

#159

Post by jlarocco »

skrebbel wrote: post #109
jakobegger wrote: post #105

Earlier quoted context omitted.

I'd actually consider that kind of knowledge pretty advanced. Beginners (and early up to even junior coders) usually don't know much about the internals of their environment; they just use stuff. I'm always interested in the internals; but it's often surprisingly hard to find information on the internals. There are few books, and you'll often need to read lots of source code and specifications and reverse engineer th…

> I'd actually consider that kind of knowledge pretty advanced. For someone from a C background, that's not advanced: it's simply what strings are. The whole idea that characters aren't bytes may be very strange to someone who's only ever done C and C++. It's probably just as strange to them as the idea that there's any relationship between bytes and "the characters that make up a piece of text" is to someone entirel…

I'd have to disagree, but maybe I'm not getting your point.

It's more work in C and C++ (and a lot of other languages) to treat strings correctly, but unless you're talking about a C programmer who's been living under a rock for 20 years, most of them are familiar with the issues around Unicode, UTF-*, etc., and they choose to ignore the issue when they can get away with it. When it's important, there are libraries like iconv and ICU for handling it. C++ even has some character conversion builtin to the locale system, but it's super ugly (which goes without saying, because almost everything in C++ is ugly ;-)

As far as your anecdote goes, I know both C and Haskell, and the question doesn't make any sense to me either. It's provably impossible to compare two functions for equality. Even in Haskell, function types don't derive from the Eq type class, so it wouldn't be possible.

Re: Early vs. Beginning Coders

#160

Post by phkahler »

Lawtonfogle wrote: post #104
alphast0rm wrote: post #94

Earlier quoted context omitted.

A good analogy I've heard to explain this is how you'd request a glass of water from the kitchen from a friend versus a computer. You can simply tell your friend "get me a glass of water" and they'll understand what you're asking. With a computer though, you must be completely explicit with your instructions, for example: walk to the kitchen, open the top left cabinet, take out a glass, put it underneath the faucet,…

Day one CS 101 class. Bring in a few loaves of bread, jars of peanut butter, and jars of jelly, with a few utensils. Also, lots of paper napkins. Have the students spend 10-15 minutes writing a 'how to make PB&J sandwiches'. Select volunteers to read their instructions while you follow them as a computer would. Explain that this is how computers work. Get some bread: grabs entire loaf of bread, uses the entire loaf f…

One problem is that programmers accept this stupidity from the machine rather than try to fix it. For example, if the computer had a definition of a good PBJ and some sort of solver, it might just figure out how to construct a PBJ with the given materials. Or maybe it would ask for clarification of some steps. Of course we don't want to treat all problems as general cases to be solved on the fly, but I don't think we should accept complete stupidity from the machine either.
Post reply on HN