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

It's hard to write code for computers, but it's harder to write code for humans

erikbern.com

Post reply on HN
Print view View original

141–147 of 147 posts

Re: It's hard to write code for computers, but it's harder to write code for humans

#141

Post by directevolve »

powersnail wrote: post #69

People learn things differently. I really need the "core concept" first, before diving into examples, (unless the core concept is extremely simple). Many tutorials are like hand-holding Lego building. Here's your Lego pieces, watch me and follow me in building this toy project, and you'll know how to Lego at the end of the day. I just don't function very well in this model. I want to know how and why decisions are ma…

Yeah, I don't know why this post is so either/or. Why not both? I like projects that have docs with core concepts in one section, examples in another. Or where the core concepts give working examples as code snippets.

Re: It's hard to write code for computers, but it's harder to write code for humans

#142

Post by namaria »

bigstrat2003 wrote: post #65
photonthug wrote: post #44

> “Humans learn from examples, not from “core concepts” Nitpicking maybe but I disagree with tfa on this point; not all humans work this way. Those of us who might actually prefer the general -> specific direction are already largely ignored in k12 and may only begin to thrive in higher education. Since we’re already kind of underserved, there’s no need to also deny that we exist!

This also stood out to me as obviously wrong in the article. Since time immemorial, we have taught math by teaching the core concepts and building on them incrementally. Since people do successfully learn how to do math, this directly disproves the author's claim that people don't learn that way.

> Since time immemorial, we have taught math by teaching the core concepts and building on them incrementally.

This is just false. Some of the earliest examples we have of what appears to be writing used in teaching contexts, it's heavily focused on repetition of examples.

Re: It's hard to write code for computers, but it's harder to write code for humans

#143

Post by michaelcampbell »

TeMPOraL wrote: post #133
pmg101 wrote: post #92

Earlier quoted context omitted.

"Programs are meant to be read by humans and only incidentally for computers to execute." From the preface to the first edition of Structure and Interpretation of Computer Programs by Abelson & Sussman (which predated Code Complete by a decade). It's a maxim I live by although my employers always seem to insist on the computers executing part for some reason.

The computer executing part is the one that's both necessary and sufficient. The human reading part is neither. It's nice, important, and long-term indispensable - exactly the kind of thing economic pressures fight against.

The point (or at least as I read it) is that the human readability is more about the language being used.

The "necessary and sufficient" part is binary, and we're not doing that by hand any more.

Re: It's hard to write code for computers, but it's harder to write code for humans

#144

Post by igouy »

fhd2 wrote: post #35
animal531 wrote: post #8

Bit of a side issue for me: I was working on my Unity game the other day and thought to myself, have IDE's really not progressed all that much in the last 10-20 years? Default intellisense has definitely gotten a lot better, but apart from that and a few other minor things the whole concept of coding feels pretty much the same today as back then. The biggest positive change for me is outside of the editor, it has bec…

I think one of the main improvements we've - interestingly - been unable to widely adopt is an actual live programming environment. Smalltalk was this. Nowadays I mainly use Common Lisp for something reasonably close. We're still mostly stuck in an edit->compile->test cycle. Stuff like TDD and debuggers help here, but considering the untapped potential for what programming environments could be, it seems to me like w…

> Reproducibility becomes something you need to actively worry about

Back in the '90s ENVY/Developer

https://books.google.com/books?id=ld6E19QIMo4C&printsec=fron...

Re: It's hard to write code for computers, but it's harder to write code for humans

#145

Post by valval »

powersnail wrote: post #69

People learn things differently. I really need the "core concept" first, before diving into examples, (unless the core concept is extremely simple). Many tutorials are like hand-holding Lego building. Here's your Lego pieces, watch me and follow me in building this toy project, and you'll know how to Lego at the end of the day. I just don't function very well in this model. I want to know how and why decisions are ma…

All coding tutorials I’ve come across struggle with this. I couldn’t care less about some scripted video building a trivial piece of software, even if it’s pretty close to what I was going to build. The optimal coding tutorial in my eyes would just be a day in the life of a software engineer building something new and thinking out loud. Of course that wouldn’t do well in video format.

I think this is just the tech equivalent of teach a man to fish instead of yada yada.

Re: It's hard to write code for computers, but it's harder to write code for humans

#146

Post by neuronet »

At the end the author wrote something without explanation that I found cryptic. It is something I am curious about as I am starting to work on a software package:

  Avoid “scaffolding” (code generation)
I wasn't sure what this meant, so wanted to highlight it.

I chatted with ChatGPT the following is an edited transcript of what we came up with. Note it is not a direct quote from GPT but highly edited cyborg quote from long conversation we had:

  The term "scaffolding" in software development refers to frameworks that automatically generate boilerplate code to quickly set up the structure of a project (think Django). This can include things like generating project directories, files, and initial code to get started with minimal manual setup. 

  In the context of that article, the rule "Avoid scaffolding (code generation)" likely is implying that while scaffolding tools can be useful for quickly getting a project off the ground, they can generate generic or bloated code that can make the project harder to maintain and understand/read in the long run, with a steep learning curve. And *readability* is the point of the article. 
   
  If your guiding values in writing a software package is producing easy-to-read, easy-to-learn, and easy-to-use code *for humans*, then avoid scaffolding.
That last sentence is all me sorry.

I have no idea if the author would agree with the above sentiment, but it seems pretty reasonable. Like most coding rules, there are reasonable exceptions.

Opinionated is sometimes good, and the justification for it may scale with the complexity of the subject matter and the intended users and use case. E.g., how many different ways are there to achieve the goal(s) of your software, and do you want to enforce one particular way, given your intended user? If so, then depending on the specifics of the problem you are solving, you may need scaffolding.

For instance, DeepLabCut (https://github.com/DeepLabCut/DeepLabCut) is great software with tons of scaffolding. It is a machine vision framework written for experimentalists to track animal behavior, so boilerplate is great for them. The developers have put a ton of thought into how individual projects should be structured so the users who don't know anything about machine learning don't mess things up.

Anyway, this is useful for me to think right now as I am building a new project so I'm curious what others think.

Post reply on HN