Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

51–60 of 511 posts

Re: Programming breakthroughs we need

#51
post #9

Eh, unfortunately the one programming breakthrough the world actually needs is one that would drastically change, and perhaps harm, most of the people around here. We need more "Excels." More and better tools that let "regular" people program.

I'm a firm believer in empowering end user automation. The atrocities that folks cobble together with the Excels of the world are a marvel, and more power to them.

But in the end, we all talk about leaky abstractions, and the stark horror is that the fact that all of these wonders run on a computer, the worlds leakiest abstraction, the worlds most stubborn, pig headed, cantankerous contraption out there.

And all the lipstick in the world can't hide it.

Re: Programming breakthroughs we need

#52
post #10
post #9

Eh, unfortunately the one programming breakthrough the world actually needs is one that would drastically change, and perhaps harm, most of the people around here. We need more "Excels." More and better tools that let "regular" people program.

Or more realistically the rapid application development tools need to be better so we're not bogged down dealing with latest fad or resume driven development

What more do you want beyond Wix and VB.NET? People just don’t use RAD stuff anymore because…well I don’t know why.

Re: Programming breakthroughs we need

#53
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…

I always tell my clients - the difference between writing code and maintaining it, is the difference between raising your hands and keeping them raised indefinitely.

Re: Programming breakthroughs we need

#54
post #6

There’s a lot of complaining and not a lot of suggesting going on in this article so I don’t take it for very much. I feel like the author got a job and realized that it almost exclusively involves writing glue code and tests and looking at text diffs, so how convenient to imagine a world where they didn’t have to do the boring parts of their job.

very much agreed. i don’t like the term glue code. when people say glue what they usually mean is their applications specific business logic

Re: Programming breakthroughs we need

#55
I think we need two breakthroughs (maybe three):

1. Less code. Operating systems have become obscenely bloated and restrictive. There is an enormous amount of power in the hardware we run our stuff on these days but you can't even touch it as a programmer anymore.

2. Powerful proof assistants and code synthesis. I love low-level programming but even the most hardcore, brilliant people I've met can easily introduce show-stopping security flaws into software without realizing it. It turns out that programming is hard and without rigorous models and proofs humans are really poor at understanding programs. We naturally hand-wave away details which get us most of the way there but these are discrete systems and details matter a lot.

As for testing... I agree, unit tests are often insufficient but probably the lowest bar you could convince typical industry software developers to hurdle to prove the correctness of their programs. Even then, as the author notes, they will come kicking and screaming with their opinions. There are far better options and strategies but as soon as you mention property testing or formalization you'll lose about 90% of the room so you have to pick your battles.

The trouble is that most startups are motivated to accidentally stumble upon a market niche and in this day and age that often means, "something with computers." They're not in it to write reliable, robust software that is efficient and performs well on a target platform. They're writing code that they can cash out on and never see again. Very different world.

The final breakthrough we need is to fund research labs again. Technology isn't inevitable and civilizations in the past have lost the ability to build and maintain it. We shouldn't let that happen again if we can help it.

Re: Programming breakthroughs we need

#56
post #39

I've thought about this issue so very many times, and I feel that until someone creates a system capable of understanding the underlying purpose of the code, we will not be able to automate this stuff away. I think the issue is that all of the things the author wants a breakthrough for is exactly what makes programming hard. We don't have systems intelligent enough to reason about a contract between two systems so as…

Part of the "structured programming" revolution was that the compilers said "any color you want, as long as it's black": they were general-purpose glue code generators by declaring everything to use the standard contract.

(later, optimizing, compilers would spend a lot of effort to reason about different contracts, and in recent times, "undefined behavior" would come to surprise people who were used to the rather laxer approach to contracts in earlier days, but these are epicycles.)

There will always be work doing things over and over again with small variations, but I for one am glad to no longer be making variations on decisions like "will this parameter be coming in a register (which?) or on the stack (and if so, with what alignment)?"

Re: Programming breakthroughs we need

#58
I have some beefs:

> To be more specific - for most web projects I work on, I have a very similar yaml file for CI, Dockerfile,

Very similar, but not actually the same - of course there's always a tradeoff between control and convenience. Maybe you don't like where kubernetes, $CI_TOOL_OF_CHOICE, etc puts that tradeoff, but that's why there's a zillion tools and languages out there, because someone wanted a slightly different tradeoff

> Changing the program is the most common thing we need to do in our work, it's the reason our job even exist. And yet, most of programmer's time is spent reading or planning how to change the code.

I think I fundamentally disagree with the idea that "reading or planning" are second-class activities here. I think that one of the highest purposes of a programming language is is to communicate to other humans, unambiguously, what the program is intended to do.

I think most languages have a sweet spot for "good at communicating for $TYPE_OF_PROBLEM" - it'd be a nightmare to read the assembly code for say a AAA videogame and try to figure out if it's a FPS or RPG game, but if the intent of a program is to do a small thing in a super-architecture-specific way, probably assembly is a great choice - exactly because some other human will see _exactly_ what you mean.

If I have to work in a big complex codebase, it's great to use a very structured language like java/rust/etc where all the many, many pieces are (or at least can be) clearly named. I'll have no idea which CPU registers are twiddled when, but I don't care, and neither did the author of that code (presumably why they chose a high-level language).

On the extreme end - a tool like excel which is AWESOME for getting computations done and presenting the results, but is (IMO) not the best for communicating _how_ to do those computations. Do every single one of the cells in this column have the same formula? If not why? Is that intentional?

I thing programming languages are awesome exactly because of the extreme, explicit precision and repeatability that they allow us to communicate with, but certainly not all problems [that are currently solved with programming languages] require that kind of rigor.

Re: Programming breakthroughs we need

#59

My 2 cents: There are thousands of projects trapped into formatting hell because nobody wants to touch git history. We need a standard to fix formatting programming without messing up history.

convert code to sexprs, diff the tree, track those changes not the text on a 2d grid

Re: Programming breakthroughs we need

#60
post #4

What we need before all this is a better way of specifying program behavior, both at a high and a low level. In mobile there are multiple tools that you can use to prototype UI behavior. They allow you to specify navigation, transitions, clickable areas, behaviors when clicked, swipe actions, etc. They're this way so that the UI behaviors can be seen before coded (to an extent - not every prototyping tool does everyt…

There was a lot of money poured into doing this in the 80s and 90s without much success. Maybe it is time to try again?

https://en.wikipedia.org/wiki/Fifth-generation_programming_l...

Post reply on HN