Hacker News Reader

IMHO, this is bad advice. It is like saying if you want to teach how to change oil in the car, teach the entire automotive engineering curriculum.

Introducing extreme complexity so early in the process turns off people; they give up easily and (falsely, in many cases) start believing that programming is not for them.

The first introduction should have enough fundamental programming concepts to enable the students to make something useful and tangible, by themselves. As the interests and the objectives grow, they can delve deeper into the domain.

I think with Khan Academy, Udacity and others, we are entering a new paradigm of "Just in time learning". Schools should focus on teaching smart learning techniques, critical thinking etc instead of cramming more and more topics in their curriculums.

I completely agree with this. Nothing is more frustrating as a beginner than getting confused and not even knowing what questions to ask.

When you introduce concepts such as addressing/pointers(which are typically in hexadecimal) and memory management you add many more moving parts to the mix. In my opinion, abstracting a lot of this stuff away helps lower the number of opportunities on which a beginner can get caught up.

Is it true? It's easy to spout platitudes about what learners should and should not have to learn and why, but have they been tested? A lot of people who went to my school would have preferred a curriculum based on Python and writing games, but the ones that graduated seem pretty glad they instead endured a curriculum based on C and culminating in compiler writing.

I'm happy to live in a post-Alan Kay world, but I think maybe it's time to dust off that sculpture of Dijkstra we keep in storage and move it out into the foyer. Programming is hard; glossing over what makes it hard in the name of doing stuff sooner may or may not help, but as long as we debate it without testing it empirically we're sure to get nowhere.

That is indeed a good question. One of the key challenge in reforming education field is the feedback cycle is big. Very time consuming to track experiments. So I have add that what I stated was my hypothesis reinforced with a small dataset of my experience teaching 'Computing & Internet' to middle school kids.

I have to clarify that my comment was targeted towards current Udacity (other MOOC) participants who wants to learn programming as a value added skill or hobby.

If you want to graduate with CS major and/or want to pick CS as a profession; I do believe you need to have a good understanding on the entire stack. There are no shortcuts to being a good professional and achieving mastery in any field requires committed hard work.

> When you're implementing a linked list or a binary search tree for the first time...

You're about 30 levels above an actual beginner. You have to think even lower capability, like this:

> When you're trying to print "Hello World" you have to know all this hard stuff like how to type "python" into PowerShell, or even just install Python on Windows and fix it's broken PATH settings.

That's where you need to be thinking if you're thinking about what a beginner struggles with.

The canonical IT answer applies here: it depends.

Learning C is good if you want to learn most of the canonical CS stuff - linked lists, bla, bla, bla.

If you want to recommend it to someone who is learning how to program so that they can get their web startup off the ground (where Python or Ruby would be a better fit), or someone who is trying to parse CSV files for work (C# or Python), then you can, politely, fuck off and die.

> One must understand pointers and bytes and bits and memory management and all that shit that leads to segfaults and many hours of debugging to be a programmer.

No, no really you don't. Perhaps to be some sort of archetypal "Real Programmer", but that's different from learning to program. There are all sorts of other factors at play: motivation, being able to get something working relatively quickly and iterate, being able to show friends/colleagues what you're working on, accessibility of libraries, etc.

Disclosure: I wrote a book on how to program in Python: http://manning.com/briggs/

> No, no really you don't. Perhaps to be some sort of archetypal "Real Programmer",

So, are you saying that if you asked a candidate during a job interview what malloc is or why inserting things in a linked list is faster that inserting things into an array, and he gave you a blank stare, you'd still hire him?

>what malloc is

There is no reason someone who never programmed C would (or should) know what function is used to allocate memory in C.

Fair enough, but don't you think they should at least know that memory is a resource that needs to be allocated and deallocated and how come that they never have to deallocate memory themselves when writing in python?

That is not the same thing as asking about malloc.

Not all languages are (or should be) like C, and not all languages require manual memory management.

If they are going to be programming in Python, there's probably no need for them to be familiar with memory management, or the underlying details of the language implementation - the language is there to insulate you (to a greater or lesser extent) from the machine. Later if it becomes useful to learn about memory management in other languages, they could do so if they are moderately intelligent, it's not rocket science or something that you must learn first or not at all.

I don't think understanding memory mapping has anything to do with data structures. I have no solid understanding of malloc or how it might be implemented, but RedBlackTrees, TernarySearchTress, LinkedLists, Hashtables, etc are all pretty easy to grasp.

Even the nature of a Struct, and how it might be more efficient than an Object, and the difference between a Stack and a Heap... All that's pretty accessible without sitting through a course on the finer workings of malloc.

The memory is there. It provides my byte buckets. I don't need to care much beyond that to be a good web-developer.

Asking most developers about malloc is probably about as relevant as asking about video frame-buffers. For some spaces it's make or break, but for most it's just useless trivia.

I think understanding roughly how Malloc works can be very helpful in pretty much any area where performance becomes important. Without knowing a bit about Malloc it's hard to understand the benefits of SLAB allocators and similar (which are used everywhere from game engines to OS kernels to DBMS etc).

In it's most basic form Malloc basically is a linked list.

Those questions would be stupid to ask for a Python position, unless there was some need for working with C APIs. Why waste your time and the developer's time?

Much better to asking about relevant things; some common Python library, or why they'd use lists vs. dictionaries vs. sets, or what a generator expression is.

Allow me do disagree. Tomorrow you're going to have a project that uses a different technology, what are you going to do then? Fire everyone and start hiring again? Of course you need at least a few people on your team who know your current technology in depth, but you probably want to make sure they're they understand the basics.

And please note that those questions are not some intricate C specific questions. Memory management is a basic thing (I'm not talking about actual memory allocation algorithms, just things like how to make sure your program doesn't leak). Linked lists are also basic data structures. It's not asking what "volatile" keyword means and when to use it.

So tomorrow we're all going to go back and start programming our web apps in C? Give me a break. Ask the right questions for the position.

Python also does not have memory management or allocation, linked lists or "volatile". Memory management is basic for C and C++, but that's about it.

How about you need your people to make an iOS 4.x compatible app. Oops, suddenly they need Objective C including all its memory management nasties. This is going to be so much harder if you have never seen pure C.

Well then obviously you'd want someone who can deal with C. "DeepDuh" indeed.

But you're talking hypotheticals - I can do that too: if you suddenly need big data then "Oops", you're going to want someone who knows Hadoop or Erlang. If you need to launch a rocket then "Oops" you're going to want an aerospace engineer. But if you're looking for a web dev, then C/Hadoop/Erlang/Aerospace questions are largely a waste of time, and might disqualify candidates who are otherwise fine or who could figure out C given a couple of days.

Bear in mind that the original topic is talking about languages for learning how to program, not languages for iOS development. If iOS apps float the beginner's boat then by all means learn Objective C; their enthusiasm for the field will probably overcome their frustration with C. But I suspect they'd be better off learning Python or similar first, then starting on C.

Hence my original response: it depends. Python is a pretty good choice because it can do well in lots of different fields and is easy to pick up.

There are legitimate reasons for people to learn to program that don't involve being interviewed by you for a job, just as there are legitimate reasons for learning to write that don't involve writing sonnets.

Similarly, there are different ways to come to the knowledge of what malloc is, or why inserting things into a linked list is faster than inserting things into an array.

> Similarly, there are different ways to come to the knowledge of what malloc is, or why inserting things into a linked list is faster than inserting things into an array.

I completely agree with that. It doesn't matter, as long as the knowledge is acquired somehow. I was just pointing out one of such ways.

Who says inserting into a linked list is faster than inserting things into an array? If the array is pre-allocated, or even crazier a c++ vector or c# list<> with an amortizing growth function that only needs to be invoked once or twice, it'll be much faster than inserting a new node in a linked list.

The array/list can be pre-allocated to the size you need and have good cache locality and minimal container overhead -- the linked list will have the overhead of the pointer to the next node (2x for a doubly-linked list) + the type descriptor (if you're using a language like c#, java, python, etc.) per node and data located all over the heap with cache misses everywhere.

<sameCondescendingToneAsParent> If I was asked during an interview why inserting things in a linked list is faster that [sic] inserting things into an array, and I provided an answer that made him blankly stare back at me, would I want to take the job? </sameCondescendingToneAsParent>

Perhaps you're getting a guy switching careers or fields of expertise (web -> system or accounting -> embedded), or someone that just has that gap in their knowledge, or someone that's just having a plain ol' brainfart at that point in time. No need to be as rude as I responded in my third paragraph.

> Who says inserting into a linked list is faster than inserting things into an array? If the array is pre-allocated, or even crazier a c++ vector or c# list<> with an amortizing growth function that only needs to be invoked once or twice, it'll be much faster than inserting a new node in a linked list.

I said insert, not append. What made you assume the question was about inserting at the end? Even if you have a big pre-allocated array, inserting an element somewhere in the middle will still cost you the price of shifting the "tail" of the array to make space for the new element, while the list will not have that cost.

Now you're just being an ass.

What makes you think insert is important anyway? The typical use cases for an array/list are pop, append and indexing. Python's list implementation uses arrays, not linked lists, internally for exactly this reason: indexing being O[1] is more important for most purposes than fast inserts. (http://docs.python.org/faq/design.html#how-are-lists-impleme...)

The purpose of asking this question is to find whether the person who answers understands the subject matter well enough to reason about it and arrive at the correct answer. It doesn't even matter if insert is a typical use case or not; if the candidate knows data structures he won't even think about it.

And what's with the name-calling? Aren't you capable of having a normal, polite discussion?

I know lots of really good programmers who wouldn't necessarily be able to describe the details of linked list algorithms or malloc. They're doing high level stuff with numpy/scipy, or working on web frameworks, and whether they know malloc or not is irrelevant.

You keep talking about "the subject matter" and "programming" like it's one topic. It's not, hence the "you're an ass" comment - you're just repeating your argument ad nauseam and ignoring everything everyone else has to say.

It's possible to be a good programmer without knowing how linked lists work in excruciating detail - get over it.

> * It's possible to be a good programmer without knowing how linked lists work in excruciating detail - get over it.*

It looks like our definitions of "good" and "programmer" are somewhat different.

People used to make similar arguments in favour of assembly language, ie. you can't be a programmer unless you can drill down to the bare metal and make it do backflips/squeeze every last bit of performance out. Now computers are faster, compilers are smarter at optimising and it's only really the case if you're doing hardcore kernel programming or writing a game engine. C, pointers and linked lists are going the same way as computers get faster still: they're not very relevant unless you're coding something in a specific niche.

And I've seen people who were the opposite of what you're saying - people who knew lots about low level C/Assembly stuff, but who couldn't write clean, maintainable high level code to save their life.

But to get back on the original topic - none of that is relevant to learning how to program. Loops, variables, data structures, managing state, functions and classes are more what you want to teach to start with, and are far more relevant to most programmers than malloc or linked lists.

Not because he couldn't answer these things, but because he'd only done the one intro Python course.

Or the one intro C course, for that matter.

Jobs where those things matter depend on much more than having got your feet wet with C and malloc learned in one intro course. You probably wouldn't have this guy to the phone screen in the first place. Right?

Depends entirely on what the job was. If I'm hiring a programmer who is expected to write C for an embedded platform, then I probably wouldn't hire them. If I'm hiring a 3D artist whom is expected to write mel scripts, then I wouldn't care about those things and wouldn't even be asking those questions.

True, but we're talking about hiring a software engineer here.

No, you're talking about hiring a software engineer. The rest of us are talking about: "Learning to program: Why Python?"

Why not just start with some embedded development then?

8-bit PIC and AVR microcontrollers have very simple instruction sets and can be connected to simple I/O devices like switches and LEDs, but they both use Harvard architectures, so you have different address spaces for code and data. The newer 32-bit PIC micros use a MIPS core, but the development tools aren't very open, despite being based on GCC.

The 16-bit MSP430 is fairly simple, has good open-source development tools, cheap development hardware (check out the Launchpad), and a more conventional von-Neumann architecture. Check out some of Michael Kohn's sample code for the msp430 assembler he wrote:

http://www.mikekohn.net/micro/naken430asm_msp430_assembler.p...

this is great, thanks

I disagree completely. I would say everyone should start with Smalltalk. Start with something beautiful and clean and then learn the messy stuff that makes it possible later.

I learned C++ by accident: A friend of my moms had an old programming book laying around and gave it to me. Next thing i know, i'm "wasting" my vacation reading the book from cover to cover. I never actually used C++ though. Not once in my admittedly very short time as a hobby and/or employed web dev have i ever actually needed to know C++ or even memory management. So i don't think it's as important to know as you claim it to be.

I'm still very glad i learned C++, though. I think it best equates to learning latin in school: You're probably never going to need it, but it gives you great insight into how languages work on a lower level and where they come from. While this won't help with your vocabulary necessarily, it will help with autodidactic learning. For example, if i didn't know about pointers, it's likely i would never have wondered about how the parameters get passed to a function: By reference or by value.

I would even go as far as to say that one should start with an assembler and not C, but given the immense complexity of contemporary hardware, I understand that such approach is infeasible.

Someone could make a similar argument about starting in C. And make similar arguments that you made for the benefits.

You have to start teaching somewhere in the stack. I actually disagree that it's infeasible to start with assembly. I don't think it's wise, but it's certainly feasible. I think people tend to have a bias that beginners should start at the same level of abstraction that they did. But I think that in online discussions, we place too much emphasis on where to start. I doubt it matters as much as the other factors, such as motivation of the student and the patience and care of the instructor.

Well, I think some kids care about the abstract and fundamental workings of computers, but a lot are initially interested in learning programming because they see cool stuff and want to make it themselves. Teaching them the "just in time" simple concepts that lead to concrete results without making them struggle with syntax to start out is a good way to keep them motivated initially. Then after you hook them, you can start teaching them the fundamental concepts of how stuff works.