Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

351–360 of 511 posts

Re: Programming breakthroughs we need

#351
The breakthrough is probably going to be a GPT-N model. It needs a few tweaks to be good enough - for example to be able to handle complex projects. The glue code is always going to be an impossible problem from the point of view of language design, can't standardise, every case is different in a different way. Only a human or a language model are flexible enough to adapt to this kind of variance. We're going to love our glue generator and won't be able to understand how we used to write that code by hand.

Re: Programming breakthroughs we need

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

A similar concept is the maintenance of physical world machinery, it's also often overlooked, but a huge industry even compared to manufacturing the machinery it self

Re: Programming breakthroughs we need

#353
I really love this point: https://yoyo-code.com/programming-breakthroughs-we-need/#pro...

In my day-to-day JavaScript programming adventures, I typically encounter issues around paths and how they're imported. There has been so much energy devoted to parsing a string and reading the file it (probably) points to, and we just assume that what we're importing from that file is actually what is in it. Maintaining all of my static imports in JavaScript feels like I'm doing something that a compiler or bundler should be doing, not a human being.

Go has the right idea, it considers every file in the current directory to be part of the same package. This is really useful because you basically don't have to think about file importing anymore. I love being able to compartmentalize my Go programs without having to worry about updating a bunch of path imports all over the place. It lets me just focus on the code and sort out the organization later on when the project gets bigger. Of course, when the project _does_ get bigger, that's when you start having to grok how packages work and how they're built. This isn't a huge problem but it's definitely a learning curve that you don't necessarily need to overcome when you're first starting out, so it's a bit of a skill jump.

I feel like there should be a programming language where the module system is deeply integrated with the package management system, and they are both baked into the language using syntax. This way, you can optimize those systems without disturbing how programs work, and the programs can specify what stuff they need from each package. Rather than deciding on some kind of folder/file convention for what a "module" is in your language, this one would put that responsibility on the programmer.

A package would be defined by specifying its unique name, and the code that can be imported out of it.

    export package "fs" {
      export module File {
        export function read(path: string) {
          // ...
        }
      }
    }
And then the `read()` function can be imported like this in your own app:

    import { File } from "fs"
    
    export package "my-app" {
      export module App
        export function start() {
          File.read("README.md")
        }
      }
    }
You'd run this function on the command line by specifying it as your "entry point" like

    lang --run 'my-app#App.start()'
Or, you can compile it into a program with

    lang --compile 'my-app#App.start()' --output ./app
I don't know if a "registry" is really needed for these packages, as that might unnecessarily centralize the whole thing. Technically, since the language doesn't care at all about file paths, you can store packages however you want in your system. Literally `wget "https://github.com/some/pkg/releases/latest" | gunzip` should be enough to start using the package, but of course having a CLI for managing this stuff will also be table stakes.

Re: Programming breakthroughs we need

#354
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 see this largely as a language failure.

Alot of popular languages make it really easy to write code, but hard to maintain it .

It's one of the reasons I like Rust so much,even for relatively high level code. It has one of the srictest type systems and std/library ecosystems of any language in existence, which tends to make code very robust and easy to refactor.

I often wish for a language that has a similarly strict type type/ecosystem but is higher level. Swift is quite close, but very Mac OS centric. Haskell has exceptions, which are often used for error handling, making code less robust (plus the ecosystem is small). Other languages like Ada/Spark or Idris are way too fringe...

Re: Programming breakthroughs we need

#356
post #342

I believe already some 2 decades ago Bill Gates said that the biggest failure in software is the lack of productivity gains in software development. Just to cherry pick a dramatized example. In the late 90s, one of my first programming experiences was in Delphi. It's a very visual way to program. You drag and drop a UI together from standardized elements. You could data bind things like input fields to a data source.…

"It's a very visual way to program. You drag and drop a UI together from standardized elements. You could data bind things like input fields to a data source. You'd double click a button and it takes you to the already created "onclick" event where you do the actual coding. In a way, this is still similar to how you can "program" Microsoft Access today."

Yes! I remember Delphi as my first language in school, too. And later in university I could not understand, why in all the other advanced languages like Java, C and C++ doing the same was so hard.

Then I discovered Flash and later Flex with Flex Builder. That was a even way more powerful experience. You could draw up anything - and make a button out of it with a click. Or a sophisticated, reusable component.

And then it died, because of Adobes unwillingness to open source the technology (and their focus on performance and flashy features and not security). All the bad flash applets that were flying around existed, not because it was so bad, but because it was so easy even for total beginners to make something working fast.

But today? I am back to hacking scripts.

Re: Programming breakthroughs we need

#357
post #305
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've also wondered if it's time to back off on agile a bit. Or at least "agile" as it is implemented generally, which means we get to make up new requirements every two weeks. In my experience, the hardest maintenance problems occur because we're trying to re-shape code into something that the developers never knew would be coming down the line. Spending lots more time up-front deciding requirements would go a long w…

Maybe I'm just an old curmudgeon, but it seems to me there's way too much emphasis on speed of development in general. Time to market seems to be more important than quality, robustness, security, performance, or any other concern.

Another thing that rubs me wrong is the recurring notion that we need to get rid of the text as a representation of code. I've yet to meet a mathematician who wants to get completely rid of formulas because coming up with a proof is slow and cumbersome.

I understand that the incentives are drastically different between academia and business, but perhaps we've gone too far in this particular direction. Perhaps it's okay to admit that programming isn't as easy as we all want it to be and it's okay to take the time to change things carefully instead of moving fast and breaking stuff.

Re: Programming breakthroughs we need

#358
post #342

I believe already some 2 decades ago Bill Gates said that the biggest failure in software is the lack of productivity gains in software development. Just to cherry pick a dramatized example. In the late 90s, one of my first programming experiences was in Delphi. It's a very visual way to program. You drag and drop a UI together from standardized elements. You could data bind things like input fields to a data source.…

At least from the systems programming perspective I think productivity gains have been significant. Valgrind had _just_ appeared as I was doing my undergrad and it allowed me to focus on the high-level math of data structures -- as an example -- compared to my non-Valgrind using classmates that were struggling with memory bugs (which, of course, I did too, but to a less degree). C++ has noticeably improved since then, if you can hew to the newer bits of the language and keep all the arcane bits in your mind. Rust has arrived on the scene, inspired by Cyclone, C++, SML and is a serious jump in productivity over C++ because the compiler keeps track of all those arcane bits. If you squint, Go's in the mix for web stuff that doesn't mind GC. It's a shame ATS didn't become more of a thing, Ada has made real strides back from the dead, especially if you can stick to SPARK Ada. We're even seeing more formal verification of complex bits of software in systems-land, something that seemed basically impossible when I first read about Coq twenty something years ago.

I do admit, though, that front-end seems like a wild west presently, to my ignorant eyes.

Re: Programming breakthroughs we need

#359
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 sincerely don't know why uni don't make more classes on that only. - pick any software - try to change something - give a precise impact analysis - generate a few potential implementation paths - measure how fast you did all that and what failed / worked

exactly, Just like getting assigned book reports, but for software nerds!

Re: Programming breakthroughs we need

#360
I’m for reinvention, and if thinking radically is what it takes to make the more typical and known processes evolve, so be it. I do have skepticism about a model liberated from the text file - most tools fall back heavily on our use of language as our most powerful tool, the extent that a visual system like a UI replaces that usually represents equal constraints on what you can do.

But constraints are what make programming languages great and easier to work with than machine code. If this boils down to a hierarchy of constraints the question that needs to be asked is “why are there so many different ways of constraining a program’s behavior” (via programming languages)? If there were only one way, much of the innovation wished for here, as abstract as it may be, would have probably already been worked on. Instead the base shifts constantly and the techniques for building changes everywhere.

Sometimes I wonder why all of programming can’t boil down to C code. Python would first be translated to C, Rust would be an analysis engine for C, etc. It is elitist to make programming a meta language and field of study just to understand and use effectively, even if not consciously done. The lack of standardization, compared to what could be, drives this complexity. You’ll know programming has revolutionized again when an order of magnitude more people can do it without dedicating chunks of their life to it.

Post reply on HN