Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

31–40 of 511 posts

Re: Programming breakthroughs we need

#31

> Maybe you could write tests as queries that would test a whole set of possible programs, not only the current version of your program at the moment. I think that the future of programming is more sophisticated static analysis. Programmers will write statements like, "every code path that writes to the Payments database must have called validate_user()." Then, the tooling will confirm that rule with every commit. We…

To set up an example, Azure has some API management stuff that could let you do this before you even got to your code. Writing a tool to make sure that API management rule exists would be different than static analysis.

I'd agree with you, but not all of the business logic like that is going to live in code in the future.

Re: Programming breakthroughs we need

#32
post #11

Maybe future programming systems can use an assertive pattern, where software developers only define what the software is supposed to do. And the programming systems generates a program that fulfills all assertions. Then when the software designer finds that the software does something wrong, he can simply add assertions. Its a little like TDD but without coding. For GUI applications it would be cool to define assert…

This kinda sounds like Prolog. Add a bunch of assertions and write a query to validate if it's true/get the missing vars.

Re: Programming breakthroughs we need

#33
> usually the biggest problem is an enormous amount of CRUD boilerplate that looks very similar in each project, but it's nevertheless different in important details.

Once upon a time, a lot of microprocessor code was written in assembly. Then C came along, and many of the assembly people said: "whoah, hold on, I use different calling conventions in different places for good reason; what do you mean every C function is going to use a whole stack frame even if it's never re-entered?" But now 99+% of programmers don't care about sub-kb stack frames, and probably most of them even consider C too low-level[0] to touch.

I've said elsewhere[1] that much of the ceremony of cloud sw dev reminds me of 1960's mainframes — so what is the equivalent of a "structured programming" toolchain for the cloud, that takes some higher level description of inputs, outputs, and logic[2], and then generates not-entirely-ludicrous boilerplate to mash it all together?

[0] in hindsight, C's big advantage back in the day was that it mixed much better with assembly than purer HLLs.

[1] https://news.ycombinator.com/item?id=32467919

[2] compare the "environment division" of COBOL with Terraform, and the "data division" with Swagger. I mean, we've definitely progressed on many fronts since then, but certainly not on the axis of "lack of verbosity"[3].

[3] OTOH, Conway's law suggests that multiple-team projects will always wind up with multiple configuration in multiple places.

Re: Programming breakthroughs we need

#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 and no one pays any attention. Though most programming money is spent on maintenance.

Re: Programming breakthroughs we need

#35

If an AI can now draw a rembrandt, then it's not far off that an AI can read this: Regular users are allowed to edit their own books. Editors are allowed to edit any books with the same account id. The public can read about any book that is not in draft status. I need a domain model where users can write books with the following properties: userId, accountId, title, author, status. status is an enum supporting draft,…

Assuming you mean that to be a rough draft for the spec of a book management app, you wouldn't need an AI to parse that and generate code. A simple DSL is enough and indeed the "spec" you wrote could be implemented in about ten minutes with Rails, devise and pundit. (I imagine most other popular backend webdev languages have similar libraries available)

Re: Programming breakthroughs we need

#37

I’ve been programming for over 30 years, and never been as productive as before. Need to load and decode a jpeg/png, I grab stb_image.h. Need to decode an ogg file, libogg. Need to decompress, libz. Need to decode video, libavformat. Need physics, libbullet. Need truetype fonts, freetype. Need a GUI, Qt. Need SSL, libssl. My day becomes selecting libraries, integrating them, and testing integration. My business code…

That’s funny because I feel like my day became cleaning up those kinds of projects as their countless dependencies rot.

It feels anything but productive.

Re: Programming breakthroughs we need

#38
There is a lot of interesting work on program as non-text/model at Unison:

https://www.unison-lang.org/learn/the-big-idea/#richer-codeb...

Until these ideas go into mainstream, treesitter has resulted in some interesting improvements to e.g Neovim. I use it extensively for AST based selection/navigation and along with conceal I can hide/transform a lot of noise characters in text source code.

Re: Programming breakthroughs we need

#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 to create a general-purpose solution for things like glue code. The subtle differences that are there and that require us to do this work over and over again with small variations are precisely why programming requires intelligence.

Re: Programming breakthroughs we need

#40
A paradigm that Dave Farley has mentioned could be on the same level as OOP or structured programming is a completely asynchronous programming language. Every operation would have no garunteee of executing immediately. Such a thing may unlock more performance for cheaper on modern multicore cpus.
Post reply on HN