What most young programmers need to learn • Hacker News Board

Re: What most young programmers need to learn

#91

Post by dschiptsov » Mon, Jan 05, 2015, 8:42 PM UTC

mkehrt wrote: post #87

dschiptsov wrote: post #86

Earlier quoted context omitted.

> one can write reasonable code abstracted over it Don't you think that at least in a strict language, this would be rather over-abstraction or abstracting for the sake of abstraction?

Not really. I think you're confusing Haskell's purity, which makes it necessary to write monadic code, with its monad syntax, which makes it easy.

I think I am not. Monads has nothing to do with "purity" - Erlang is a pure-functional language but there are no monads.

Monad make sense only within a language with Normal (instead of Applicative) order of evaluation, to ensure that one computation (or action) "finishes" (being reduced to a value) before another (>>= and >>). return is for the type-checker.

Re: What most young programmers need to learn

#92

Post by mkehrt » Mon, Jan 05, 2015, 9:06 PM UTC

dschiptsov wrote: post #91

mkehrt wrote: post #87

Earlier quoted context omitted.

Not really. I think you're confusing Haskell's purity, which makes it necessary to write monadic code, with its monad syntax, which makes it easy.

I think I am not. Monads has nothing to do with "purity" - Erlang is a pure-functional language but there are no monads. Monad make sense only within a language with Normal (instead of Applicative) order of evaluation, to ensure that one computation (or action) "finishes" (being reduced to a value) before another ( >>= and >> ). return is for the type-checker.

That's a very specific way of thinking about monads. Sure, they enforce ordering in a language where you may want to do that. But they're also any ADT equipped with a generalized map (that we happen to call >>= or bind) that commutes nicely. I don't think about my list operations using bind as about ordering computation; I think about them as transforming data in a way that is a little harder to do with more traditional list operations. Same with set, maybe, etc. The ordering feature of monads is more about IO actions than it is about monads in themselves.

All I'm saying is that monads are a useful abstraction regardless of whether or not they are used to encapsulate effects. I use Traversables, which have a bind operation, all the time in Scala, and it is an effectful language.

Re: What most young programmers need to learn

#93

Post by sophacles » Mon, Jan 05, 2015, 9:10 PM UTC

sanderjd wrote: post #88

sophacles wrote: post #77

Earlier quoted context omitted.

Yes in that case it's a win, but it becomes an anti pattern when you sometimes want to perform_new_feature() and sometimes you don't. I've seen it happen where you end up with many functions like: def a_and_b_and_c() {...} def a_and_b_and_c_error_checked_internally() {...} def a_and_new_and_b_and_c {...} def a_and_new_and_b_and_c_error_checked_internally() {...} def a2_and_b_and_c And so on. Basically you are just pu…

This is a great discussion! I've always thought that after the basic "how do I even do this at all?" concepts of programming, the next most important concept to learn how to wield and to perpetually sharpen is the "don't repeat yourself" principle. Huge swaths of software engineering literature is dedicated (explicitly or implicitly) to when and when not to apply that principle. Your parent's comment addresses by far…

One thing to keep in mind here... some of those "you can't predict" things are utterly predictable in light of experience. That part can't be faked to well, there aren't a good set of rules about it. But experience is a good teacher, and you do eventually learn to be reasonably accurate about when to do C+P vs DRY, even if you can't explain the why of it.

I think it comes down to this - when I first learned to code, it was hard enough to keep track of a couple different functions. As experience came, what I could track and reason about and keep in my mental model grew, so now that I've got some experience I can see more of how the whole system will grow and interact. I'm not really smarter per se, but rather I just have more practice as putting it all together.

Re: What most young programmers need to learn

#94

Post by innguest » Mon, Jan 05, 2015, 9:21 PM UTC

mod wrote: post #67

innguest wrote: post #44

Earlier quoted context omitted.

I agree with everything you said here; I particularly agree with the part where you say that after knowing Scheme and Haskell everything else becomes easy and boring. Does it ever. Makes me question why I got into programming now that I see the bigger picture of what I have been diligently trying to master for over 15 years. To the beginner I'd say: study Scheme and Haskell. Understand them. Once you do, look at othe…

Maybe it's like cheating in video games. Maybe we should all play the normal game instead of turning on god-mode Scheme? I'm not going to lie: I don't want to be bored or burnt out.

I like the metaphor and think it's on point.

It's as if you found a way to make cash appear from nowhere. It would be hard to find a reason to work for money.

Same deal with Scheme. It lets you do anything, easily, but it makes it hard to find a reason to want to do anything.

To be fair I wouldn't blame it on Scheme, more on my own brain, but still, beginners should look at Scheme right away so they can get to the "I can do anything, now what do I want to do, if anything, with this tool" part faster.

Re: What most young programmers need to learn

#95

Post by danieltillett » Mon, Jan 05, 2015, 9:55 PM UTC

jerven wrote: post #43

danieltillett wrote: post #9

Earlier quoted context omitted.

I am guilty of commenting out code when I am working on a problem, but before committing I remove it unless it is the simple version of some function that I made way too complex in order to improve performance. I find it easier to understand later what the complex code is supposed to be doing if I have the simple implementation in the comments.

I suggest you move the simple version into a unit test case. Making sure the simple version and the complicated one have the same results. Plus I like to add some perf test that shows the complicated version is faster than the simple one that I can rerun after major upgrades to the lower level system e.g. when upgrading from java 1.5 to 1.6 I could remove some complicated code because the simple one was then as fast…

Yes I also think this is what I should do to, unfortunately when I first wrote the code I spend most of my time working on I didn't write unit tests at the function level (all my tests are at the module level). I have been meaning to get around correcting this, but the task is now so huge I fear it would take me more than a year to write all the unit tests :(

Re: What most young programmers need to learn

#96

Post by danieltillett » Mon, Jan 05, 2015, 10:02 PM UTC

gknoy wrote: post #70

UrMomReadsHN wrote: post #46

Earlier quoted context omitted.

No... you are making your code hard to understand to others by doing that. Thats if you check it in like that. Nothing wrong with leaving it there during development.

I disagree. If I see 25-40 lines of something that LOOKS like it should be simple, it's tempting to replace it with the four line version. A comment which says, "You might think this would be better as {{4 lines}}, but it is too slow... because this/that/etc" can be VERY helpful, so that one doesn't reproduce the problems (and the time fixing) that caused the initial un-simplification in the first place.

I do explain in the comments why the simple function was removed and why the complex version is being used. The biggest problem I have found over time is divergence of the simple version from the complex version. I try and avoid this by updating and testing both versions, but whenever you have code duplication there is a risk that they will diverge.

Re: What most young programmers need to learn

#97

Post by vitd » Mon, Jan 05, 2015, 10:36 PM UTC

I agree that these are things programmers need to learn. I think analyzing code (as in debugging it, learning to read what someone else wrote and understand it), are equally important. I learned no debugging while getting my degree. (Or rather, I learned no debugging during school hours. I learned plenty working on my own projects during that time, though.) I see this with junior programmers we hire now, too. They sometimes don't even know what a debugger is!

Re: What most young programmers need to learn

#98

Post by jerven » Mon, Jan 05, 2015, 11:15 PM UTC

danieltillett wrote: post #95

jerven wrote: post #43

Earlier quoted context omitted.

I suggest you move the simple version into a unit test case. Making sure the simple version and the complicated one have the same results. Plus I like to add some perf test that shows the complicated version is faster than the simple one that I can rerun after major upgrades to the lower level system e.g. when upgrading from java 1.5 to 1.6 I could remove some complicated code because the simple one was then as fast…

Yes I also think this is what I should do to, unfortunately when I first wrote the code I spend most of my time working on I didn't write unit tests at the function level (all my tests are at the module level). I have been meaning to get around correcting this, but the task is now so huge I fear it would take me more than a year to write all the unit tests :(

IMHO every automated test helps.

Don't aim for 100% test coverage aim at using unit tests to develop faster and more efficiently and the test coverage stats will come automatically.

I personally need to improve my TDD, but I am quite happy with my test driven bug fixing approach. When working on a bug I first turn it into a JUnit or selenium test, and then fix the bug and make the test pass.

Re: What most young programmers need to learn

#99

Post by sanderjd » Mon, Jan 05, 2015, 11:24 PM UTC

sophacles wrote: post #93

sanderjd wrote: post #88

Earlier quoted context omitted.

This is a great discussion! I've always thought that after the basic "how do I even do this at all?" concepts of programming, the next most important concept to learn how to wield and to perpetually sharpen is the "don't repeat yourself" principle. Huge swaths of software engineering literature is dedicated (explicitly or implicitly) to when and when not to apply that principle. Your parent's comment addresses by far…

One thing to keep in mind here... some of those "you can't predict" things are utterly predictable in light of experience. That part can't be faked to well, there aren't a good set of rules about it. But experience is a good teacher, and you do eventually learn to be reasonably accurate about when to do C+P vs DRY, even if you can't explain the why of it. I think it comes down to this - when I first learned to code,…

Couldn't agree more. It's definitely a function of the extent to which you're guessing, which is a function of your experience solving very similar problems.

I do think we (programmers? people?) have a tendency to avoid inspecting the experience we already have. We thought hard about some pattern a few times and came up with some instincts based on that experience, which is great, but we should make sure to double-check those instincts from time to time.

Re: What most young programmers need to learn

#100

Post by throwaway3301 » Mon, Jan 05, 2015, 11:37 PM UTC

How does one keep these things in practice in the reality of an over-committed software team with shifting priorities, difficulties interfacing with product management, and bad specifications/requirements that eventually result in significant scope creep? I often feel like I want to refactor code, but the cost of doing so is so high that it would slow me down to the point of missing a deadline. "It works" is usually as much as I have time for.

Maybe I'm just not a very good programmer...