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

How I became a better programmer (2017)

jlongster.com

Post reply on HN
Print view View original

11–20 of 150 posts

Re: How I became a better programmer (2017)

#11

Post by sanderjd »

MaxBarraclough wrote: post #4
kqr wrote: post #3

The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff. However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now. I think the truth is that we're always missing the forest for all the trees -- only a…

> then languages Perhaps a slight digression, but: I think there are very few people who can really say they can 'see through' the difference between languages. C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say If you learn to program in one language, it'…

They might not mean "easy" in the same way you mean. I sometimes find myself saying "easy" when what I mean is something more like "approachable" or "without many ambiguous roadblocks". I very much believe it is "easy" in that way to learn new programming languages. It is still hard work, requiring lots of reading and trial and error and plenty of failure, but it doesn't have that same experience of complete stuckness as the first time learning to program.

But I wouldn't say it is "easy" after learning one language. It definitely takes two or three, with step-changes each time you learn a language in a different paradigm than you have before.

Re: How I became a better programmer (2017)

#12

Post by tasuki »

MaxBarraclough wrote: post #4
kqr wrote: post #3

The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff. However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now. I think the truth is that we're always missing the forest for all the trees -- only a…

> then languages Perhaps a slight digression, but: I think there are very few people who can really say they can 'see through' the difference between languages. C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say If you learn to program in one language, it'…

I would expand that to "If you learn to program in one language, it's easy to learn another within the same paradigm".

If you know Python, Ruby or PHP will be pretty easy for you to pick up. You might have some difficulties with Haskell and Lisp.

Re: How I became a better programmer (2017)

#13

Post by lymitshn »

yagodragon wrote: post #5

I've heard so many things about Clojure. I am a CS student with some experience in the most used languages (JS, java, python). Can someone explain in simple cs terms why Clojure is sooo hyped? What can I do with this language that would be harder with other languages? From what I've gathered it's used in data wrangling and manipulation in general but most data-oriented tools are written in Python.

Maybe more of the hype comes from the fact that its a Lisp. To get a feeling for the "magic" of lisp, I would suggest either watching SICP video lecs[0] or reading the book. I started learning lisp, almost the same time I've started learning programming with Java (college). Honestly I was thinking why they don't just teach us that, instead of Java at that time.

Also Clojure is created by a fairly respected dude (afaik) Rich Hickey. His talks and Clojure design decision articles on the site are really insightful.

Also this talk[1] also pretty good overview of different paradigms and `Clojure way`, imo.

[0]https://youtu.be/-J_xL4IGhJA?list=PLE18841CABEA24090 [1]https://www.youtube.com/watch?v=vK1DazRK_a0

Re: How I became a better programmer (2017)

#14

Post by sanderjd »

kqr wrote: post #3

The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff. However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now. I think the truth is that we're always missing the forest for all the trees -- only a…

I've been having this experience recently. I used to be a voracious reader of programming books. But for a long time starting, gosh, maybe over 5 years ago, I just couldn't get excited to read them anymore. Just recently I thoroughly enjoyed reading Designing Data Intensive Applications, and I have just started Streaming Systems, which I'm also enjoying a lot. I think this idea of fluff at different levels of abstraction explains it: I used to enjoy reading books about programming languages and frameworks, but at some point it just felt like fluff and I could no longer get through it. But there are books about techniques for solving particular classes of problem (in the case of my recent reading: data processing) which don't feel like fluff to me. But maybe they will eventually, and maybe you're already further on this continuum and would find these books fluffy as well. I'll definitely be thinking about this fluff at different levels of abstraction model and checking my self-education against it as I go now!

Re: How I became a better programmer (2017)

#15

Post by teataster »

yagodragon wrote: post #5

I've heard so many things about Clojure. I am a CS student with some experience in the most used languages (JS, java, python). Can someone explain in simple cs terms why Clojure is sooo hyped? What can I do with this language that would be harder with other languages? From what I've gathered it's used in data wrangling and manipulation in general but most data-oriented tools are written in Python.

I believe it's hyped because is a more practical/modern lisp.

I don't think it provides more fundamental benefits than any other lisp than access to a plethora of standard Java libraries. E.g. I cannot Java, but knowing clojure has allowed me to maintain a large inherited Java codebase. Afaik I could not have done that in common lisp (and not only because I don't know cl).

I think almost everything is harder when you are not using lisp. Also lisp tends to bring joy to its users for some reason, so there is that.

Finally there is a huge difference between Python and clojure data wrangling. Pandas and spark are fundamentally table oriented, but if you are using nested dictionaries (clojure maps) you do not have those tools to help you. No matter what I was doing in clojure, it always involved processing nested maps, it's just the natural approach in the language, kinda like using classes in Java.

Hope I managed to clarify something :)

Re: How I became a better programmer (2017)

#16

Post by Twisol »

> Here's a question I like to ask: do you spend most of your time making your code look "nice"? If so, I recommend not focusing on it so much. [...] It's better to focus hard on the core problems you're trying to solve and think hard about your layers of abstractions.

Absolutely. Modeling what you're trying to do in code is a critically important task, and a most surface-level grime is forgivable if you have an understandable foundation.

However, I worry that if you focus on the first half of this block, you might think the abstractions aren't important. To a lot of new programmers, abstractions and models are themselves merely "nice" -- if you can get it done without them, clearly they're non-essential, right?

I believe that most code is read more often than it's written. (You pass through a lot of code while tracing down bugs!) It pays to reduce the brainpower necessary to understand a block of code, and good abstractions and good models are key to this.

Re: How I became a better programmer (2017)

#17

Post by Vinnl »

Twisol wrote: post #16

> Here's a question I like to ask: do you spend most of your time making your code look "nice"? If so, I recommend not focusing on it so much. [...] It's better to focus hard on the core problems you're trying to solve and think hard about your layers of abstractions. Absolutely. Modeling what you're trying to do in code is a critically important task, and a most surface-level grime is forgivable if you have an under…

...and also: bad abstractions can be major impediments to it.

Re: How I became a better programmer (2017)

#18

Post by ozim »

Twisol wrote: post #16

> Here's a question I like to ask: do you spend most of your time making your code look "nice"? If so, I recommend not focusing on it so much. [...] It's better to focus hard on the core problems you're trying to solve and think hard about your layers of abstractions. Absolutely. Modeling what you're trying to do in code is a critically important task, and a most surface-level grime is forgivable if you have an under…

Main point is to be consistent, if it is ugly the same way it is OK. If each time it is ugly different way start thinking about making it consistent.

Most value is from consistency, if you make the same mistakes in the same way it is easier to find them. If you make the same mistake in a different way each time, good luck finding it.

Re: How I became a better programmer (2017)

#19

Post by lymitshn »

MaxBarraclough wrote: post #4
kqr wrote: post #3

The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff. However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now. I think the truth is that we're always missing the forest for all the trees -- only a…

> then languages Perhaps a slight digression, but: I think there are very few people who can really say they can 'see through' the difference between languages. C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say If you learn to program in one language, it'…

I also agree with this. Some people treats languages like forks. It's just a fork why pick another it will do just fine right? Well languages are more like artist tools I think. Of course you can draw a perfect horse with pen/pastel/charcoals as in writing really good i.e Chat Server with Java/Erlang, but each of them has different taste, feeling, community. Picking a language is pretty different than picking a fork. And those all the way Javascript / Java lovers feels like 0.7/0.5 mechanical pencil users that tries draw everything with that. How about trying a brush? (Maybe I shouldn't have pushed this analogy this far)

No offense to, my fork lover friends.

Re: How I became a better programmer (2017)

#20

Post by majormajor »

Twisol wrote: post #16

> Here's a question I like to ask: do you spend most of your time making your code look "nice"? If so, I recommend not focusing on it so much. [...] It's better to focus hard on the core problems you're trying to solve and think hard about your layers of abstractions. Absolutely. Modeling what you're trying to do in code is a critically important task, and a most surface-level grime is forgivable if you have an under…

> I believe that most code is read more often than it's written. (You pass through a lot of code while tracing down bugs!) It pays to reduce the brainpower necessary to understand a block of code, and good abstractions and good models are key to this.

Bad abstractions and models make it much harder to understand code, though. So for junior devs, yeah, it would often be better to be very, very careful, and think very, very hard about your abstractions before creating them.

Everyone wants to turn every problem into some sort of framework loaded with interfaces and different implementations of them vs being ok with "feature X needs to do thing A, B, and D; feature Y needs to do things A, B, C, and E; let's just have them as two separate endpoints with separate biz logical calling those methods sequentially instead of trying to coerce them together."

Post reply on HN