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

51–60 of 147 posts

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

#51

Post by layer8 »

bityard wrote: post #50
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!

Maybe I'm dimmer than the average techie, but I need both. Much of my current job is frustrating because it's a big company and every new task I encounter is presented with only an example of how the previous person did it. Instead of, "This is what we're trying to achieve, this is how the thing works, this is how we do it," all that ever gets exposed to ICs is the "this is how we do it" part. This makes it impossibl…

The thing is that you can derive the “this is how to do it” from the first two, but not the other way around. While it’s very helpful to have all three, the first two are essential while the last one is not.

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

#52

Post by animal531 »

jerf wrote: post #40
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…

"Why do I need to worry about small language specifics like brackets, terminators and so on when tools should be able to auto-complete them for me?" Actually, if you are using an IDE, there's probably a flag you can flip for that. It's a very common feature, to the point that I often find it in places I'm not expecting, like the web-based security training code platform my employer periodically pushes us through. I'm…

Some good feedback here and in the thread overall.

I also use a 3-way horizontal split these days for editing, I've found that the wider our screens get the less I use the edges. So now often I'll keep the left focused on the headers to variable definition, the middle for the main editor and the right for methods where the middle is calling or being called by something.

In Visual Studio you don't have to dock windows, but the current generation of floating window doesn't really conform to what I want. Someone else mentioned Haystack which I haven't seen before: https://haystackeditor.com/

I quite like the layout of Haystack, although I don't think one wants to take it too far such that it begins to resemble visual scripting. I think a block based approach where you have different blocks for the different types such as classes, variables and code might be worth exploring.

I'll definitely post back sometime with feedback on whether I've come up with anything interesting.

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

#53

Post by animal531 »

AnimalMuppet wrote: post #19
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…

About the first item on your wishlist: If by "brackets" you mean {} (in C-like languages), there are IDEs that can be configured to create pairs of them every time you hit return after an expression that can take them. The downside (if you care) is that, if you wanted to write an if, while, or for with only one line, and therefore no scope delimiters, it will force you to create the scope anyway. You may not care. If…

Yeah some of my points are really space dependent. For example I'm working on a solo game project, so my comment on the public/private etc. modifiers is really aimed at that where nothing will ever be exposed and the modifiers are pretty much irrelevant.

>So, that's my whiny personal take on some things on your list. Maybe I've adapted myself to the existing tools. But I personally think that many of your items, if you implement them, you will find that you don't really like how they work out.

You could very well be 100% correct there. As developers we really become used to our tools and its quite hard to adapt to new ways of doing things. But I figure its worth a shot, at the worst I'll have learned a few things along the way.

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

#54

Post by animal531 »

1718627440 wrote: post #22
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…

> You're editing a file (or parts of different files) and are focusing on say 5 methods that are interacting. I want to see all of them on the screen at the same time, without having to struggle to open and manage many windows with for example VS horizontal/vertical sliders. I think that is, why editors like emacs and vi are really popular. - Data conversion. So I created a HashSet for something but realize I need to…

>How different would that be from changing the type and editing all the places the compiler complains about?

Currently in VS if let's say I change the Set to a Dictionary it will compile in the background and then complain about all the errors from where I can click on them to be taken there, and/or I would search on the variable name and find all the references and just scan through all of them to make changes as necessary.

Some ideas there could be: a) We can use multiple windows (or lines in 1 window) to just quickly display all of the required changes directly on screen without me having to manually go from one to the next.

b) Let's say we were doing a standard List.Add but now its a Weird.Blob (ie. a non-standard class with no built in conversion support). I can perform a replace all .Add with .Blob which text editors can already do, but what if we only applied it to this current set of windows that have opened up, so as to not break other things? Again you could have done that with a narrower replace, but this way might be easier or faster.

c) In text editing you might have to replace a few lines several times, so you'd copy the new line or a segment of it, then replace all the parts of the old instances. What if we sorted all those opened windows so that the ones that are most similar are located next to each other, then if we change one we just drag it (or parts of it) to the other windows to make replacements. If they are exactly the same then provisionally change them automatically, the user just accepts the whole block of changes (as if they had done a search/replace for a specific line, or part of a line).

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

#55

Post by jerf »

animal531 wrote: post #52
jerf wrote: post #40

Earlier quoted context omitted.

"Why do I need to worry about small language specifics like brackets, terminators and so on when tools should be able to auto-complete them for me?" Actually, if you are using an IDE, there's probably a flag you can flip for that. It's a very common feature, to the point that I often find it in places I'm not expecting, like the web-based security training code platform my employer periodically pushes us through. I'm…

Some good feedback here and in the thread overall. I also use a 3-way horizontal split these days for editing, I've found that the wider our screens get the less I use the edges. So now often I'll keep the left focused on the headers to variable definition, the middle for the main editor and the right for methods where the middle is calling or being called by something. In Visual Studio you don't have to dock windows…

I hope you do. I know it's easy to just crap on someone's ideas, but I'm really trying not to do that. I think it's a great idea to learn from what came before, because if anything's going to succeed it is almost certainly going to be at least a little different than what someone else tried. Sometimes it can be the smallest difference that decides the matter. I wish you the best of luck in your explorations.

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

#56

Post by animal531 »

ants_everywhere wrote: post #27
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 may not be understanding you correctly, so please let me know if I've gotten it wrong. Some of the stuff you're talking about -- like brackets and terminators -- make explicit the syntax and greatly improve tooling. Usually editors have features that can add these in or you. But in some cases something is obvious to you, but is really one valid choice among many and the tooling can't read your mind without somethin…

Yeah I've also been playing with ChatGPT etc. and sometimes they can produce great code, or at least get you up to speed a lot faster. As long as you ask them questions about well known problems they're great, but break down after that. But they're definitely going to play more and more of a role going forward.

What I really want to explore (and where I think there might be some big room for improvement) are around how we represent and visualize both code and data, as well as how we interact with it. Full visual programming has often been tried before and while it works fine for a while it begins to break down once projects become more complicated.

I instead want to explore some alternate text based options where we use the visual aspect as an assistant, whether by grouping or collating blocks that we're working on, changes that needs to be made and so forth.

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

#57

Post by dbalatero »

CharlieDigital wrote: post #45

From Code Complete: “The smaller part of the job of programming is writing a program so that the computer can read it; the larger part is writing it so that other humans can read it.” (P.733) Has stayed with me for ~20 years.

I wish that wasn't buried on page 733!

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

#58

Post by ants_everywhere »

animal531 wrote: post #56
ants_everywhere wrote: post #27

Earlier quoted context omitted.

I may not be understanding you correctly, so please let me know if I've gotten it wrong. Some of the stuff you're talking about -- like brackets and terminators -- make explicit the syntax and greatly improve tooling. Usually editors have features that can add these in or you. But in some cases something is obvious to you, but is really one valid choice among many and the tooling can't read your mind without somethin…

Yeah I've also been playing with ChatGPT etc. and sometimes they can produce great code, or at least get you up to speed a lot faster. As long as you ask them questions about well known problems they're great, but break down after that. But they're definitely going to play more and more of a role going forward. What I really want to explore (and where I think there might be some big room for improvement) are around h…

I'm mildly skeptical of visual programming because code generally won't be a planar graph and it's rarely useful to visualize a complicated enough graph. You can try to embed the graph in hyperbolic space, but I'm not sure how much you get out of it. For example of visualizing a graph where it's not clear what's going on: https://cambridge-intelligence.com/wp-content/uploads/2021/0...

Coding is a logic/language type activity that uses the language parts of your brain. Visualization can help see that certain relationships are true (e.g. visualizing the graph of a function), but I think the fundamental bottleneck we're dealing with here the inadequacies of the visual regions of the brain to do logic, not a lack of AI tooling.

I'd be happy to have my mind changed though.

EDIT: Although, an AI version of something like Chernoff Faces for visualizing data would be cool.

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

#59

Post by kalaksi »

auggierose wrote: post #30
kalaksi wrote: post #13

Earlier quoted context omitted.

I didn't find it contradictory. The first one is about how to start learning about something more easily and the second one about how to organize it all so that it's easier to use and understand as a whole. That may also help with getting started too. I personally agree that examples are a very efficient way to get started and you can learn the details incrementally in a top-down fashion. Some text books during my st…

There is even a headline saying "Getting started is the product". No, it is not. If your product doesn't have nice core concepts, then I don't even want to get started with it. Top-down is fine, as long as there is an actual bottom of core concepts.

Sure, it isn't really the whole product, but I interpreted it as an exaggeration, meaning that easy onboarding would be very essential part of the product and which is the first thing users experience.

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

#60

Post by masto »

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!

I'm with you on this. My learning style is to read the reference manual cover to cover (metaphorically now). I can recall numerous instances of wanting to get into a new thing and finding the vast majority of recommended introductions to be the polar opposite of what I was looking for.

I'm going through this now as I decided to spend some time today learning the Drizzle ORM. The first things I found were all "here are half a dozen examples of queries", and I started getting frustrated: why are you using that syntax and not something else? What are the other options? I closed those and I'm much happier doing it my way: reading every page of the documentation before doing anything else.

Post reply on HN