Why Learning to Code Is So Damn Hard • Hacker News Board

Re: Why Learning to Code Is So Damn Hard

#221

Post by dragonwriter » Thu, Feb 05, 2015, 4:47 AM UTC

pdonis wrote: post #218

brianwawok wrote: post #167

Earlier quoted context omitted.

There is a difference from RELY on compile to catch 100% of bugs, vs having an awesome type system that can take whole CLASSES of bugs and make them impossible to get past a compile. Is a statically typed language more likely than a dynamic language to work correctly in production, if both have 0 tests? Yes. Is either ideal? No. Can both be improved by adding a few tests? Yes.

> Is a statically typed language more likely than a dynamic language to work correctly in production, if both have 0 tests? Yes. I'm not sure I agree. "Work correctly" does not just mean "compile correctly". I would want to see a lot of evidence to back up any assertion that programs written in statically typed languages are less likely to contain logic errors that compile and run just fine but don't do what the prog…

> I would want to see a lot of evidence to back up any assertion that programs written in statically typed languages are less likely to contain logic errors that compile and run just fine but don't do what the programmer (or his client) actually wanted.

As certain assertions related to logic can be encoded into static types (especially in a language with a type system more like Haskell's than, say, Go's), while static typing can't eliminate all logic errors, it can reduce the probability of logic errors escaping detection in the absence of testing, since compiling a statically typed program is, in effect, a form of testing (limited to those assertions about behavior which can be encoded into the type system.)

Re: Why Learning to Code Is So Damn Hard

#222

Post by paulannesley » Thu, Feb 05, 2015, 5:07 AM UTC

tokenrove wrote: post #199

bad_user wrote: post #95

Here's where I disagree with other people - software development is special in that it requires focus, relentlessness, intelligence, creativity and I also find it interesting that many software developers tend to suffer conditions from the autistic spectrum. To me that's a clear sign that software development requires the mind to be hardwired in a certain way. And the thing is - I never needed handholding, which is w…

I disagree, and I disagree because I used to think this way (having lived and breathed programming since age five), until I started to meet people who had started to program in university (which I considered _way_ too late) and who had become excellent programmers. Not adequate-for-a-job programmers, but best-of-breed programmers. In fact, often better programmers than "naturals" because along the way they had learne…

In the “born programmer” theory, surely the trait begins latent and could manifest at any age depending on exposure / triggers / mentors etc? And university seems a likely time for that to happen; not everybody had access or was given that first nudge into computers earlier in life.

Re: Why Learning to Code Is So Damn Hard

#223

Post by pdonis » Thu, Feb 05, 2015, 5:33 AM UTC

dragonwriter wrote: post #221

pdonis wrote: post #218

Earlier quoted context omitted.

> Is a statically typed language more likely than a dynamic language to work correctly in production, if both have 0 tests? Yes. I'm not sure I agree. "Work correctly" does not just mean "compile correctly". I would want to see a lot of evidence to back up any assertion that programs written in statically typed languages are less likely to contain logic errors that compile and run just fine but don't do what the prog…

> I would want to see a lot of evidence to back up any assertion that programs written in statically typed languages are less likely to contain logic errors that compile and run just fine but don't do what the programmer (or his client) actually wanted. As certain assertions related to logic can be encoded into static types (especially in a language with a type system more like Haskell's than, say, Go's), while stati…

> compiling a statically typed program is, in effect, a form of testing (limited to those assertions about behavior which can be encoded into the type system.)

Fair point. (Especially if, as you say, you are using a language with a type system like Haskell's, which to me is more like a program analysis engine than just a type system.)

Re: Why Learning to Code Is So Damn Hard

#224

Post by chrismcb » Thu, Feb 05, 2015, 5:50 AM UTC

pm90 wrote: post #132

bad_user wrote: post #95

Here's where I disagree with other people - software development is special in that it requires focus, relentlessness, intelligence, creativity and I also find it interesting that many software developers tend to suffer conditions from the autistic spectrum. To me that's a clear sign that software development requires the mind to be hardwired in a certain way. And the thing is - I never needed handholding, which is w…

I don't really agree with the notion that software development is something that others cannot learn if they try to do it; that seems like a very harsh perspective which, from my anecdotal experience, is far from the truth. Any skill can be learned if you have the discipline to put in regular effort: that's just the way the human mind works. I do agree that for a lot of people, Software Engineering is easier because…

I think you are right, anyone can learn to code. But for many people the learning curve is just to steep and they give up before they can learn it. And that is ok, not everyone needs to be a programmer.

Re: Why Learning to Code Is So Damn Hard

#225

Post by ivanhoe » Thu, Feb 05, 2015, 6:42 AM UTC

For me it was never hard because I started as a kid, on my own, so I was exploring this new world at my own pace and terms, and it was amazing and fun. That's how kids learn. Learning the grown up way is on the other hand harder and takes time. For coding you actually need to master 2 separate, non-trivial skills: first to learn how to think/solve problems in a certain way, and second to learn the particular language. I think the main problem is that people don't give themselves enough time for the first, and concentrate only on the second.

Re: Why Learning to Code Is So Damn Hard

#226

Post by rebootthesystem » Thu, Feb 05, 2015, 6:50 AM UTC

Learning to code isn't hard at all. Learning to solve problems computationally is a different matter. There are tomes of knowledge one must acquire that is usually application specific and in potentially narrow fields. For example, if you want to write a RTOS you need to study and learn OS theory. Want to work on GPS code? Well, there's some math you need to understand along with a pile of other stuff. Want to work on search? Better have a very good handle of a range of algorithms and know how to implement them efficiently. Automation? Hmmm, you can't set an output and expect the machine to respond when there's physics involved. Aircraft control systems? ....

The point is that coding is easy just like understanding the basics of running a milling machine is easy. Being a machinist is far more complex than knowing how to turn the wheels. And machining highly accurate objects in exotic metals is multiple levels above that. Learning "machining" is easy. Learning to be a machinist is hard. Same for coding. Learning to code: easy. Becoming a software engineer: Harder.

Re: Why Learning to Code Is So Damn Hard

#227

Post by ivanhoe » Thu, Feb 05, 2015, 7:02 AM UTC

bad_user wrote: post #159

pm90 wrote: post #132

Earlier quoted context omitted.

I don't really agree with the notion that software development is something that others cannot learn if they try to do it; that seems like a very harsh perspective which, from my anecdotal experience, is far from the truth. Any skill can be learned if you have the discipline to put in regular effort: that's just the way the human mind works. I do agree that for a lot of people, Software Engineering is easier because…

What you're saying is true and I used to be optimistic about it like you, however I stopped believing that it is feasible for most adults after failing to teach family members the basics or junior colleagues to become better. Maybe I've been a bad teacher, however the thing I noticed is this - yes, if you put enough effort, Ok, we can probably do anything, like learning to play the violin or do programming, except th…

Actually you can't ever learn to play a violin properly unless you have an ear for music. There is a threshold of minimal talent that you can't jump over just by practicing, you either can hear it or not. While there is no such obvious threshold for e.g. math or programming (for a person with an average IQ), I think we could talk about a kind of a threshold defined by the concentration and willingness to invest time and effort into the learning process. Theoretically anyone should be able to do it, but in reality not everyone is mentally capable of that, simple as that. Just like running a marathon or something, most of us will never be able to do it, although in theory it's simple: you just need to follow the proper training for long enough. Losing weight is also dead simple, just as quitting smoking or getting off drugs, but many can't do it. Learning is no different, it takes certain minimal level of power of will to be able to make it.

Re: Why Learning to Code Is So Damn Hard

#228

Post by hwhelchel » Thu, Feb 05, 2015, 7:09 AM UTC

troels wrote: post #183

epochwolf wrote: post #111

Earlier quoted context omitted.

The routing system and associated view helpers can really get confusing. For example: link_to @story.title, @story You have to know that rails has some automatic routing based on the class of an object. If @story is a Story class, rails basically does this underneath: link_to @story.title, send("#{@story.class.name.downcase}_path".to_sym, @story.to_param) There's implicit conversion of class names going on under the…

I have to agree - The path helpers are very opaque. It would probably do Rails well to generate a app/helpers/path_helper.rb file with the actual implementations in them.

`rake routes` will output the routes and paths. Appending _path or _url to the path will generate appropriate methods.

Re: Why Learning to Code Is So Damn Hard

#229

Post by chii » Thu, Feb 05, 2015, 7:21 AM UTC

bhaumik wrote: post #80

rcthompson wrote: post #43

When I was in college, one CS professor explained the difficulty of coding to me in terms of discreteness vs continuity. In the real world, things are continuous. If you accidentally build your structure with 9 supports instead of 10, then you only lose 10% of the strength of the structure, more or less. The strength varies continuously with the amount of support. But if you're writing a 10-line program and you forge…

Wahoowa! This also explains the popularity of interactive platforms like Codecademy/CodeSchool/Treehouse, etc. Ton of handholding and pre-filled syntax. We describe them to our students as "coding on training wheels." Cathy, a new frontend student, experienced similar struggles when starting her first real project - a simple HTML/CSS resume. She spent countless hours fixing minor typos and almost quit. It wasn't unti…

> She spent countless hours fixing minor typos and almost quit.

it's interesting anecdote!

When i was at uni, i noticed that a large number of "beginners" tend to fall into this category too - frustrated at minor typos/language idiosyncrasies. Those who had the mental strength to endure it end up passing the class, while those that just gave up will almost inevitably change their major (and thus, stop programming i guess?).

But i think this is a result of poor educational methods, not because of an inherent property in programming.

Re: Why Learning to Code Is So Damn Hard

#230

Post by chii » Thu, Feb 05, 2015, 7:24 AM UTC

rcthompson wrote: post #187

SiVal wrote: post #179

Earlier quoted context omitted.

With respect to your CS prof at one of my favorite places (Go Cavaliers!), this is not an issue of discrete vs. continuous. If your structure can have either 9 or 10, but not 9.001, supports, it is discrete, not continuous, regardless of failure mode. And remove one of the 3 legs of your stool, and you probably wouldn't have 2/3rds of its support remaining, but whether you did or didn't would be an issue of proportio…

I agree that "discrete vs continuous" is not the perfect way of expressing the difference; it's just an analogy. (But the structural support example is continuous. You could have 9.5 supports by adding a 10th support with half the strength, etc. "Amount of support" is the continuous measure.) But it's not just an issue of graceful degradation. The fact that tiny changes in a program can have very large effects is a f…

there are continuous programming languages out there - DNA is one such one i guess. But i don't think the discrete vs continuous nature of a programming language is what makes it difficult. It's more that a person's mind may not conceptualize tasks algorithmically, and to switch to this frame of mind is difficult for someone who isn't already in this frame of mind.