Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

91–100 of 511 posts

Re: Programming breakthroughs we need

#91
post #34

Great post - the one word missing, "maintenance." Most programming work is done maintaining/enhancing existing code. The greenfield work is a piece of cake by comparison. You want to do the hard stuff? Maintain existing code you're not familiar with. The problems around maintaining unfamiliar code are huge, largely unsolved, expensive and risky. There's a little branch of computer science called Program Comprehension…

There have been interesting progress in this space from a different angle of attack. o11y (Akita, honeycomb, ebpf, prodfiler, ...) and "Learning from incidents" are two of these angle that have really built on this idea that "understanding what the system does in prod" matters far more than "writing it right the first time".

It is also the thinking we can see supporting a lot of the early devops movement.

Re: Programming breakthroughs we need

#92
post #78

Everytime someone proposes a non-textual representation of code I cringe. There's a reason no one single alternative has triumphed over text. And many have been proposed! Standards are hard. Proprietary tools lock you in. Text is universal (OK, restricted to plain ASCII, which is a big deal but has already happened). You can open and modify a text file with whatever editor of your choice, the simplest possible editin…

But how do we know which part of our preference for the querty keyboard is it's efficiency and which part is not wanting to learn?

If I think of non textual rep I'm getting a picture of someone trying to strike a pinata with a blind fold on where the someone is me.

Re: Programming breakthroughs we need

#93
For me it is the separation of business logic and data from the programming implementation.

Often the workflow in automating a work process is: - Worker has intuition on how things work - Specialist starts automating and running into exceptions, walls - Worker explains exceptions as they're discovered - Specialist adds spaghetti to the 'clean' business logic model they started with - This keeps going until the end result looks like what the worker expects - The worker then sees a datapoint they think is incorrect, but they can't check it because the business logic is embedded in software, code, database stored procedures, etc. - The specialist is then called back into debug and resolve the issue.

At my workplace we run into this issue constantly, where the ability to modify/adapt the business logic is lost through automation, and it becomes obscured to the point that the intuitive workers can't trust that the logical model is right.

There needs to be better separation of business logic from models so that programmers don't need to 'dig' into business processes and exceptions, and workers don't need to deal with part of their responsibility being shoved into a black box that they're not sure they totally trust or can adapt easily should a need arise.

Re: Programming breakthroughs we need

#94

A lot of the thought process here seems to move into Bret Victor's talk on 'Inventing on Principle'[0] [0] https://youtu.be/EGqwXt90ZqA

mostly just a glimpse of that talk, perhaps better suited is the one about programming he gave at Dropbox. In my opinion quite more in-line with what's being said.

Re: Programming breakthroughs we need

#95
post #78

Everytime someone proposes a non-textual representation of code I cringe. There's a reason no one single alternative has triumphed over text. And many have been proposed! Standards are hard. Proprietary tools lock you in. Text is universal (OK, restricted to plain ASCII, which is a big deal but has already happened). You can open and modify a text file with whatever editor of your choice, the simplest possible editin…

Actually, I think we have already moved away from pure text a long time ago. Think about it this way:

If "text" (so only the sequence of tokens) was the valuable representation, then we would all program without any formating (no additional spaces and linebreaks).

Now, you might say well formating is important for readability. These spaces and line breaks do matter. But, just adding them randomly where they are syntactically allowed is not helpful either. There is some very specific structure to formating: The AST.

So, in other words we usually structure short snippets of text sequences in a graphical layout by ASCII-arting the structure into it. And, even with that, many people would complain about the missing syntax highlighting, another meta property that pure text does not have ...

Anyway, I think you are right about almost all tooling being build for text, so we are kind of stuck with it ("unchangeable fact of life"). However, that does not mean that it is the ultimate representation.

E.g. there is still one industrial nation stuck using the imperial system, and that is certainly not because it is more practical than the metric system. It is just that the infrastructure, tooling and culture has internalized it.

Re: Programming breakthroughs we need

#96
post #34

Great post - the one word missing, "maintenance." Most programming work is done maintaining/enhancing existing code. The greenfield work is a piece of cake by comparison. You want to do the hard stuff? Maintain existing code you're not familiar with. The problems around maintaining unfamiliar code are huge, largely unsolved, expensive and risky. There's a little branch of computer science called Program Comprehension…

Working on old but popular software is where legends are made. You need to be methodical about changes. How do you make changes in a million line+ codebase without breaking anything for millions of existing users? This challenge is reserved for the finest engineers on the planet. These are the people you want your desk near when you start your professional career as a programmer.

Re: Programming breakthroughs we need

#98
> the text is just a tool to manipulate some abstract model of the program.

yup.

> When you think about it this way, it becomes clear that using a textual source code is really inefficient way to manipulate this model.

Hard nope. All the attempts at different approach were a failure so far. Text so far is the best thing we have because text can be analyzed formally and computed with by computers. This is the result of the work that's being going for at least like 200 years in philosophy, logic, and math.

What we really need is to bridge the gap between programming and math as industry standard, not academical exersise somehow. But I highly doubt eliminating text as source code is it.

Re: Programming breakthroughs we need

#99
As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs).

What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. Static typing everywhere. It's utterly baffling to me.

"Why are you using Ruby? You should use…Rust! (Go! Zig! Fill-in-the-blank nerd hype!)"

Lol.

What I actually want is a new programming language/environment which makes Ruby look like programming pointer arithmetic in C by comparison. Something so advanced, so high level, that much of the time you're really just describing patterns and flows and data models and extensions, and then letting the computer determine the most efficient way to develop those code paths and execute them.

Unfortunately, I'm a bit cynical on this front. I believe the reason this doesn't exist is because it's at cross-purposes with programmer nerd culture. Many programmers enjoy the nitty-gritty of low-level coding. They fear abstraction. They fear "magic". They fear things like "implicit imports" or "duck typing" or "many ways to express the same method/function/algorithm" etc. because it's all nebulous and fuzzy compared to the safe confines of deterministic math & logic. "If I declare that this variable MUST BE AN INTEGER, then it MUST BE AN INTEGER. The idea you could pass me a string instead? UNACCEPTABLE !!!#%@!"

In other words, I don't have high hopes that great UX for forward-looking developers will come from present-day programming culture. For a quantum leap in DX, we probably need people who aren't die-hard programmers to engage in blue sky thinking. We need to talk to artists, philosophers, linguists, psychologists, and other experts in social & historical cultural dynamics. They can provide the insight we lack. Because for every "this is an integer, damnit!" type out there, there are probably many, many more who would see 123 and "123" and think THAT'S THE SAME THING. :-D

Re: Programming breakthroughs we need

#100

For me it is the separation of business logic and data from the programming implementation. Often the workflow in automating a work process is: - Worker has intuition on how things work - Specialist starts automating and running into exceptions, walls - Worker explains exceptions as they're discovered - Specialist adds spaghetti to the 'clean' business logic model they started with - This keeps going until the end re…

Wow. I would say the complete opposite. Why are you writing a program for work unless you are helping to solve a problem? The implementation only exists to work with business logic and data.

Excel is an implementation that does not care about business logic and data. Anyone can add their own business logic and data.

Post reply on HN