Hacker News new | ask | show | jobs
by kitrose 1603 days ago
Aren’t they bad examples? There’s a distinction between an extremely rare occurrence of biological factors like being 7 feet tall in order to succeed, and that of needing a decent education in order to think critically.
1 comments

Some people just cannot wrap their head around pointers. Some just do not get recursion no matter what. I used to teach CS, and tutor in CS. It is as rare as being 7 feet tall, sadly. And without understanding indirection and recursion, the most you'll ever do is ...well..not much...
Sit in a room and point at a spot on the floor.

You are a pointer, pointing at nothing.

Attempt to put shit where you're pointing and you have shite all over the floor.

Malloc creates a bucket. Now when you put shit where you're pointing it lands in a bucket.

When you're done with the bucket you clean it up.

If you try to put too much in the bucket, you end up with shite all over the floor.

If you forget to clean up the bucket, the place will start to stink.

If you change the pointer so nothing is pointing at the bucket of shit, then it will just sit there, forgotten. But the shit is still there.

No one ever forgets this way of teaching it.

> It is as rare as being 7 feet tall, sadly.

Objectively not true? Not even close to true.

I guarantee you there are many orders of magnitude more people in the world who understand recursion and that understand pointers than there are people who are 7 feet tall. Being 7 feet tall is extremely rare, and building a functioning C app is not.

The average height of an NBA player at the highest level of the sport is under 7 feet.

----

I don't understand why we're all commenting under this thread accepting the premise that good programmers are rare. They're not, look at the size of the industry and the output. The only way this argument makes sense is if you redefine "good" to mean something incredibly exclusionary, and even if you do it's impossible to argue that none of the software coming out of the industry is producing any value for users or solving any problems that they have.

> And without understanding indirection and recursion, the most you'll ever do is ...well..not much...

How do you think we have a software industry at all if you're claiming that both:

A) only an extreme minority of the population (<1 in a million) is capable of understanding very basic concepts like pointers, and also

B) it's impossible to build useful tools without them.

One of those two things has to be false, or you have to explain to me why the entire software industry hasn't collapsed by now from lack of talent and lack of output.

This kind of gatekeeping is ... beyond parody.

Have you ever used a no code application?

They never - not even close - mention pointers.

You can create great business apps without ever understanding a pointer.

What's so hard about understanding this?

Not every piece of software is Linux, or an NSA-worthy encryption algorithm, or a bespoke Silcon Valley web forum for that matter.

I don't know how a carburetor works but I can pump my own gas.

I don't have a medical degree but I am still allowed to self-medicate a cold.

I tune out when math PhDs start geeking out, but I can do my taxes.

I am aware of what a pointer is, but my old ship captain-turned-trading desk boss most certainly is not and he wrote several nifty SharePoint workflows to automate invoice approvals and legal reviews.

In their defence.. Most modern languages don't really make use of these.

I mean recursion is almost never better than a while loop (stacks don't love it), and pointers... Yeah everything in JS and Python, Elixir and Ruby is really a pointer (most everything) but the average day to day it's not something devs care all that much about.

As an ex c and c++ dev, and CS grad, I know about them. I think if I pushed myself, I could find perhaps 5 times in the last 10 years where knowing that things are pass by references in ruby was expressed as such.

i've been homeschooling my daughter through middle school. she's very smart, she's been in the highly capable program since maybe 2nd grade. she honestly surprises me with her ability to reason, but i've yet to hit on a way to get her to understand loops. i've been considering learning an array language with her in the hopes that it would allow her the chance to get interested in programming and excited about its potential without facing loops.
Definitely recommend MIT's Scratch, it's the closest thing (in terms of "they don't even know they're coding!") to Hypercard out there, tons of games and community examples, my kids make animated movies with it.

There's a board game Robot Turtles based on the Logo version where you provide instructions via a stack of cards to navigate your turtle through a maze.

The game is scored like golf, fewer cards are better, and it includes looping cards.

Definitely designed more for elementary students but it's visual, intuitive, and you (as parent) can "design" the maze.

There are several similar video games (they are simple and cute enough to paper their very dry subject matter, and they are level/puzzle based so easy to dole out in manageable amounts of enthusiasm )

Lightbot

Human Resource Machine

7 Billion Humans

Also my kids and I whiteboarded out and then coded a few of the games from

https://github.com/coding-horror/basic-computer-games

It was fun acting as the game designer who wanted this feature or that!

Maybe program her?

Maybe something like, place three eggs on the counter in a row. Tell her "Pick up the first egg. Crack it into the frying pan. Put the shell back where the egg was. Pick up the second egg..."

Then, next time, tell her "For each of the three eggs, pick up the egg, crack it into the frying pan, and put the shell back where the egg was."

Would she get something like that?

Loops are easy.. You have 3 chocolates, and for each one you take a bite. If it's spicy filled, you stop eating them.

While there are still crayons in your bowl, the colors in the rainbow grows.

"what time is it mr wolf?" When you reach daddy/mommy you stop.

What languages has she been learning and do they have list comprehensions?
I can count on one hand the number of people I've known in my lifetime who are over 7', but met hundreds of students over four years in college who understood recursion.

And programming is not the NBA, and people who write code are not all-stars. We're plumbers, and the idea that programming is some genius's endeavor that only the smartest people can understand is laughable.

I've done embedded systems for 35 years. I've done quite a bit. Never needed recursion. (Not much use for it in the embedded world...)

Now pointers... yeah. I use those a fair amount.

:-) If you've written a while loop you've used recursion. Not saying you need to understand the inner beauty of a fixed point combinator . . . it's just there, to be noticed, if you choose. You might (meaning if it caught your eye) study some recursion and notice some properties that give you some insight into how your algorithm performs or how induction over your datatypes works. Often when writing some Scheme or Julia, I'll carry a mental model in C at the same time.

What I enjoy about code is that I can understand it on a number of levels.

A while loop is only "recursion with tail-call optimization". It's not equivalent to "recursion without TCO".

But "while (true)" is also equivalent to a goto :-)

While both of those are true, I'm not sure that understanding either of them is relevant to dmitrigr's claim that you have to understand both recursion and pointers in order to amount to anything as a programmer.

You are of course correct and with respect to the claim "you can't be a good programmer without understanding indirection and recursion" I don't believe that holds water. I think different techniques allow for a deeper understanding; whether or not that deeper understanding translates to a "better programmer" is fairly subjective. For me, a good programmer is one who writes readable/understandable code and that's a different category all together.