Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

401–410 of 511 posts

Re: Programming breakthroughs we need

#402

Software reuse-in-the-small is a solved problem, but reuse-in-the-large seems unsolvable. That’s been the state of things for decades. Testing is hard because the requirement for correctness is often absolute and inflexible. When software is allowed to be a little incorrect, then yeah testing gets much easier.

Yep. And your "reuse-in-the-large" I'd argue is also a side effect of reality itself. Take any market sector or industry, not just software - I suspect the "easyness" of directly reusing and copying any complex system is vanishingly small. If that were not the case, we would have infinite choices and brands of any complex product ever made!

Re: Programming breakthroughs we need

#403
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.…

The web, and much of programming really, feels so far behind the curve of what's possible as a programmer. Take a dive into shader design in something like unreal engine 5, it sounds exactly like what you're describing in Delphi, mind you, I say this as someone who has never programmed in that language. The ability to drag and drop functions, compose higher levels of abstractions, and really all of the fun programming stuff we do can be accomplished in these engines. I've found it very enlightening, and even somewhat frustrating, to go from drag/dropping some graph nodes that generate a playable world for fun, and then back into the world of javascript for work where I am slinging 100s of lines of text-based code just to get a form button to operate correctly.

Re: Programming breakthroughs we need

#404
post #72

Earlier quoted context omitted.

>Is the future dynamic languages / high level specifications that are AI-transformed into typed verbose languages like C/Rust/whatever and then compiled? How is that different from the present? Why are these "AI-transformations" different from what a compiler can do?

A compiler cannot take arbitrary high level descriptions and generate code. You’ve seen copilot right? ( https://github.com/features/copilot ) It’s fundamentally more sophisticated. This is like asking what is the difference between modern ML translation and the previous 20 years of research on language translation; the former actually works. The latter basically doesn’t except in very specific circumstances. Compile…

We need more interesting tools, as you said. As long as the horizon of innovation remains on "something that generates good old code" I'm not very excited about the future. Copilot is an amazing tool, sometimes gimmicky, but a tool of the present nonetheless. As a compiler, it takes instructions and generates instructions. We need a future where AI is involved in debugging, and program comprehension, and correctness. More interesting tools than a better RAD.

Re: Programming breakthroughs we need

#405

Earlier quoted context omitted.

> Static typing everywhere. I think the industry has generally recognised that static typing makes more reliable software. I started with PHP and have seen its type system evolve. Similarly Typescript. I since moved to other staticly typed languages. I wouldn't want to go back.

Yeah, I think this is what a lot of people miss. When I only used dynamic languages, I told everyone that they were the greatest thing ever and they were idiots for using static languages. Then I started using static languages and would never go back to dynamic languages. (OK, I still write Emacs Lisp.) All the things I thought were great about dynamic languages were actually a huge waste of my time, but I didn't kno…

In Ruby, `foo.method(:bar).source_location` works like 98% of the time. There are also LSPs like Solargraph now that work pretty well in VSCode, etc.

I will admit there are certain gems which metaprogram the heck out of everything and that can get annoying, but the flipside is usually those are the gems which are hugely flexible because they're so popular and widely used (I'm looking at you Devise)—and if so there's plenty of documentation and community support out there. I'm also glad `binding.irb` is a thing now for immediately jumping into a console in the midst of your running app, and the new debug.rb gem shipping with Ruby 3.1+ is awesome as well (also with a VSCode integration).

Re: Programming breakthroughs we need

#406

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…

Excellent. Asimov's "decay of empire" scenario approaches! (every living human eventually forgets how to repeat, or even interperet how the complex systems undergirding our entire society works, eventually rendering maintenance impossible)

Re: Programming breakthroughs we need

#407

Good luck trying to create something more powerful and versatile than text to create programs. Text is a seemingly basic, simple and even crude format. Ancient, outdated even? My opinion is that our perception about the simplicity of text is related to Moravec's Paradox, and is an illusion. Reading and writing text is something we take for granted, but this is a skill we all have to painfully learn at a young age, an…

This is true. Especially for programming where you can be asked to do anything at all that is computable. If you massively limit the scope then Excel is a fine interface. Try making blogging software in Excel though.

Do lawyers have want to move away from text and to something better? No. But for simple rules you can do no wordy things, like a no smoking sign or a locked door to indicate a rule.

Formatting issues can be resolved by using an autoformatter. Tools can be made to visualise the code too.

Re: Programming breakthroughs we need

#408
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.…

Ironically, I know everything from ASM to...well many languages, including C, C++, PHP, Python, Ruby, Javascript, etc.

The most productive tools I used prior to learning all of that? HyperCard on the Mac, Visual Basic on Windows. Why? Tooling. Even when you had to get down and dirty, it seemed the tooling helped you out in some way. Shoot, I wrote an application back in the 90s in VB6 that still is functional TODAY not just in Windows, but in Linux and MacOS (thanks to translation layers such as Wine)

The same can NOT be said for the game I made in C++/OpenGL later...

Re: Programming breakthroughs we need

#409
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.…

I agree with the general sentiment of your post. Regarding Java and C#, I am stunned by how good are IDEs now. To be clear, when I say IDE, I am specifically talking about a tool that enhances the edit-compile-debug cycle. Compared to 20 years ago when I wrote C, C++, and Perl, the IDEs were mostly terrible, except Visual Studio for Windows. The majority of my development cycle was all terminal-based: vim to edit, ma…

>And this doesn't require expensive, licensed software, like Delphi 30 years ago.

Delphi wasn't expensive for most of it's life, until they got greedy, and lost the market.

Lazarus is the modern open source replacement, it's mostly compatible with Delphi, and $1400 cheaper. ;-)

Re: Programming breakthroughs we need

#410

Earlier quoted context omitted.

Yeah, I think this is what a lot of people miss. When I only used dynamic languages, I told everyone that they were the greatest thing ever and they were idiots for using static languages. Then I started using static languages and would never go back to dynamic languages. (OK, I still write Emacs Lisp.) All the things I thought were great about dynamic languages were actually a huge waste of my time, but I didn't kno…

In Ruby, `foo.method(:bar).source_location` works like 98% of the time. There are also LSPs like Solargraph now that work pretty well in VSCode, etc. I will admit there are certain gems which metaprogram the heck out of everything and that can get annoying, but the flipside is usually those are the gems which are hugely flexible because they're so popular and widely used (I'm looking at you Devise)—and if so there's…

Oh, also I just got a hot tip from a buddy to look into Ruby Jard, a visual (but still terminal-based) debugger with a whole slew of features. Haven't tried it yet but it looks really neat-o.
Post reply on HN