Live data from Hacker News

How I became a better programmer (2017)

jlongster.com

81–90 of 150 posts

Re: How I became a better programmer (2017)

#81
post #21

Earlier quoted context omitted.

> 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'…

> If you learn to program in one language, it's easy to learn another, I assume that person doesn't know much about programming. This is flat out wrong. If you know Python, it'll be easier to learn Rust than having to learn Rust from zero. Engineering is about problem solving and formulating solutions with algorithms and data structures. If you don't know what those are yet, it'll take much longer to learn. Learning…

It’s also worth noting that projects are rarely contained within the bounds of a programming language.

If you’re building a web app, what’re language you use will still come down to HTML/css. You’ll also probably be using SQL, which is also unlikely to change.

But there’s the other side to that. If you’re graphics programming, OpenGL provides the same features regardless of language. The OS APIs are broadly the same - the steps to set up a TCP listener don’t change with the language.

The APIs for all these may be subtlety different between languages, but not significantly. It’s a case of translation rather than relearning, and although I can’t speak for anyone else I find that translation quite painless.

Re: How I became a better programmer (2017)

#82

Earlier quoted context omitted.

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…

> I don't think it provides more fundamental benefits than any other lisp Concurrency primitives and immutable data structures are part of the core language. This is probably more interesting than the lisp part itself, which is kind of a bonus. Rich Hickey's talks stress the former aspects a lot more than the later.

Well, those are so ingrained in clojure that I forgot about them :). I think you made a great point.

Re: How I became a better programmer (2017)

#83

About a decade ago when OOP was just booming in the PHP world, I wrote my own database abstraction layer because I was a bit tired of the ORM's that existed at the time (Doctrine, Propel, ZF). Taught me what makes a beautiful fluent interface and the difficulties of achieving them. Helped me to think about UX experience at a code level, trying to achieve an interface for developers that fits all ages. That was an eye…

I initially followed the same path... then I just ditched completely PHP and its ecosystem and then never felt the need to write my own ORM/Router/libs again.

Re: How I became a better programmer (2017)

#84
post #51

Earlier quoted context omitted.

> anyone writing a UI in 2020 to have a damn good reason to not use react and redux. Avoiding JavaScript is all the reason anyone needs. UI =\= website

The most charitable interpretation of their point is any UI where you were going to use Javascript heavily anyways which is what Redux+Redux competes with. To take your point to absurdity, you could also just say "nope, write a native client instead."

I thought the point to absurdity was what they mean by UI =\= website?

on edit: =\= is the prolog version of !=, I guess they didn't want to use != in case anyone thought they used JavaScript in real life.

Re: How I became a better programmer (2017)

#85

My comment is a little tongue in cheek but Here is "How I became a more productive by becoming a worse programmer" - I stopped worrying about best practices and just do it. - I hardly refactor my code unless I'm using the same thing for the fifth time. I just copy-paste it instead. - I never think about optimizing code until I really really need to. - I write what gets the shit done quickly. I don't care if writing a…

+1. Add: - Use long expressive variable/function/class names that tell me exactly what this variable/function/class does I have to constantly fight the urge to have code fit in the littlest amount of space possible.

Variable names sound be succinct . They don't need to be short, but they also shouldn't be essays. I had one coworker who would essentially write everything the function did. Variable names would be 100+ chars. It was impossible. Variable names should be as long as needed , but no longer.

Re: How I became a better programmer (2017)

#86

> Understand continuations - Continuations are a low-level control flow mechanism. Excellent advice right there! > Scheme is the only language to implement them, and while you will never use them in production, they will change how you think about control flow. I wrote a blog post trying to explain them. Hmm, well, many languages compile to a continuation passing style (CPS) intermediate. And in many languages it is…

"... you will never use them in production ..."

I'm a Haskell programmer. Continuations are part of my everyday toolbox.

Re: How I became a better programmer (2017)

#87
post #68

About a decade ago when OOP was just booming in the PHP world, I wrote my own database abstraction layer because I was a bit tired of the ORM's that existed at the time (Doctrine, Propel, ZF). Taught me what makes a beautiful fluent interface and the difficulties of achieving them. Helped me to think about UX experience at a code level, trying to achieve an interface for developers that fits all ages. That was an eye…

> I think what makes a great programmer is that they are able to think at a macro-level, thinking about how 'others' will use and apply the code, and making it look deceptively simple. I don't fully agree. Yes, some programming needs to be done at a meta level, but far from all of it. Sometimes a software engineer is just there to solve a business problem, and in that case what makes them great is efficiently solving…

How you solve that particular business problem should be really easy to deduce from the code that you wrote to solve it. 2000 line functions that are one big switch / case statement don't fall into that category for example.

So it's still thinking about how others (that could even be yourself two years down the road) use the code is very important for such applications.

The definition for code to me is a language used to explain other programmers what you are trying to do that can be parsed by a computer.

Re: How I became a better programmer (2017)

#88
Your reasoning for learning C is biased (perhaps you don't know it well as you suggested the others to know the basics)! At the end, hardware understands only values. C is a minimal, efficient and readable language which survived for decades although there are hundreds of other programming languages. It remains an active programming language as long as there is a good compiler support.

Re: How I became a better programmer (2017)

#89
post #83

About a decade ago when OOP was just booming in the PHP world, I wrote my own database abstraction layer because I was a bit tired of the ORM's that existed at the time (Doctrine, Propel, ZF). Taught me what makes a beautiful fluent interface and the difficulties of achieving them. Helped me to think about UX experience at a code level, trying to achieve an interface for developers that fits all ages. That was an eye…

I initially followed the same path... then I just ditched completely PHP and its ecosystem and then never felt the need to write my own ORM/Router/libs again.

Haha me too. I think PHP was a great rite-of-passage as a developer back then: inconsistent standard API, all the session and cookie access built in, with all the security gotchyas, evolution from major versions 4 to 5, obsession with Frameworks, growth and development of ZF and Symfony etc. Great experience.

As I left the ecosystem, I realised I approached writing code in a very defensive, overly structured way and have written less than half as many libraries ever since. The jury is out on whether that's a good thing or not.

As a sometimes-front-end dev, part of me quietly yearns to go back to the days of serving full html pages, especially since data transfer speeds are higher than they've ever been.

Edit: that's not a rejection of React et al. more an acknowledgement that everyone wants to do server-side rendering "because performance" which was... what we used to do. If we serverside render most of the page, we only need to enhance _some_ of the UI clientside? Yup. Exactly what we used to do.

Re: How I became a better programmer (2017)

#90

About a decade ago when OOP was just booming in the PHP world, I wrote my own database abstraction layer because I was a bit tired of the ORM's that existed at the time (Doctrine, Propel, ZF). Taught me what makes a beautiful fluent interface and the difficulties of achieving them. Helped me to think about UX experience at a code level, trying to achieve an interface for developers that fits all ages. That was an eye…

As a recent convert to redux who ended up recreating it from first principals but in a much much clunkier way, I highly recommend anyone writing a UI in 2020 to have a damn good reason to not use react and redux. It's so well designed today. Well worth the time to learn.

From my experience a few years ago, Redux adds a lot of indirection to your application without adding much value. My last project was 'pure' React, and we didn't miss Redux because React now supported contexts to share state throughout the application.

Mind you for my current application I may still go for Redux, it's going to be very large with possibly a lot of interdependent components and form fields. We'll see.

Post reply on HN