Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

Post reply on HN
Print view View original

481–490 of 511 posts

Re: Programming breakthroughs we need

#481

Post by johncessna »

agumonkey wrote: post #280
SKILNER wrote: 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

At the University I'm associated with, there was a discussion about why more 'practical' classes weren't taught. The answer was 'We're not a trade school.'

Re: Programming breakthroughs we need

#482

Post by jmull »

panstromek wrote: post #457
jmull wrote: post #276

The author wants to do away with the program as text source code but doesn't suggest another way to represent a program. You're going to have to perceive and manipulate your program in some way. Maybe it will be great to get rid of code, but then what will you have instead?

> The author wants to do away with the program as text source code but doesn't suggest another way to represent a program. Quoting the article: > I imagine this model as a relational database - you have tables like `structs`, `fields`, `functions`, `arguments` and relationships between them. I really want something like that pretty specifically. We still use text to edit data in SQL database, but you can also use que…

Well, SQL queries are still written in code as text.

But I think you must be referring to the visualizers that many db tools have that, e.g., provide a grid view of a table or view, perhaps with QBE headers (or other means of filtering), etc?

Those kinds of things are nice. They make certain tasks easy to do or certain kinds of questions easy to answer. But they are all limited too -- each is a simplification of the overall problem space (which is why you still need SQL or if not that, some other equally complex query language variant, not to mention a more full-featured language on top of that to do the things SQL doesn't do).

For programming, IDEs are full of this stuff already. Code completion, all kinds of refactoring tools, symbolic searching/browsing. So I'm still not sure what the vision is... I can see that more sophisticated refactoring tools is part of it, but there seems to be a broader idea, but I can't tell what it is.

Programming is more complicated than it needs to be, but it and its tools cannot get simpler than the underlying problems they exist to solve. If we all were working on the same kinds of problems with a bounded, known set of variables, that could all use the same runtime, be hosted in the same kinds of environments, operate on the same kind of hardware, etc., then we could have simple, powerful tools for that (though probably in that case someone would simply solve the general problem, and there wouldn't be any more programmers needed, just sales people).

Re: Programming breakthroughs we need

#483

Post by kinjba11 »

thrown_22 wrote: post #393
the_duke wrote: post #354

Earlier quoted context omitted.

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 stric…

>Alot of popular languages make it really easy to write code, but hard to maintain it . The language you're writing in has next to no meaningful impact on long term maintenance. When you're trying to do software archeology on why a function even exists the types it has will not help you figure out it's there because between 1996 and 2002 there was a tax rebate on capex for rocket development. You need human understan…

I disagree. Language does matter for long term maintenance. For instance with a tax rebate.

Static typing - a fancy language feature - can immediately tell you the function deals with money. +1 for maintenance. Static typing with a solid IDE will immediately reveal everywhere the function is used. +1.

Languages shepherd you into certain designs or mistakes by making some things easier than others, such as when class inheritance can be easily abused in OO languages, cryptic one liners are easy in Perl, point-free cleverness in Haskell, monkey patching in dynamic languages, etc. +/-1 depending.

Per documentation, languages come with tools and best practices: Javadoc, Godoc, Rustdoc; C# even has a dedicated comment syntax for documentation - a fancy language feature. +1. No one does documentation, until the language tooling forces them to.

That said, BG (Before Git) and widespread use of source control, as in '96 to '02, was a dark age. We know more now.

Re: Programming breakthroughs we need

#484

Post by bshanks »

This paper might be of interest: David Harel, Guy Katz, Rami Marelly, Assaf Marron. Wise Computing: Towards Endowing System Development with True Wisdom https://arxiv.org/abs/1501.05924

It describes an idea called "wise computing" or "behavioral programming" which i'm not sure that i fully understand, but it sounds like the idea is to allow IDEs to help more, via additional formal reasoning about code in the manner of an expert system AI.

Re: Programming breakthroughs we need

#485

Post by Sohcahtoa82 »

thrown_22 wrote: post #393
the_duke wrote: post #354

Earlier quoted context omitted.

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 stric…

>Alot of popular languages make it really easy to write code, but hard to maintain it . The language you're writing in has next to no meaningful impact on long term maintenance. When you're trying to do software archeology on why a function even exists the types it has will not help you figure out it's there because between 1996 and 2002 there was a tax rebate on capex for rocket development. You need human understan…

> The language you're writing in has next to no meaningful impact on long term maintenance.

I disagree.

If you abandon a large block of code for a year, then come back to it, depending on the language, it may be difficult to grok what the code was doing and how it worked.

If it's Java, the tendency to create 100 levels of abstraction make it hard to reason about. If it's Python without type annotations, then your IDE may not be able to determine the types of variables, so it's difficult to determine what can be done with an object.

If it's Perl, then God help you. May He have mercy on your soul.

Re: Programming breakthroughs we need

#486

Post by mst »

eternityforest wrote: post #437
mst wrote: post #274

Earlier quoted context omitted.

What do you have in mind when you talk about LSB for Docker?

A lot of why we have containers is to stop dependency hell, but having a stable platform to built on is another way to achieve that without containers at all. Of course it seems like the other reason we use them is to bundle multiple services together, but I'm not exactly a microservice fan to begin with. In any case, I don't see why we couldn't have an OS that makes debian packages into containers, sharing things th…

Feels a bit like lxc plus distroless.

(need to think more about what you said, mind, that's just a random first thought, no warranty express or implied)

Re: Programming breakthroughs we need

#487

Post by zcw100 »

andsoitis wrote: post #416
mikewarot wrote: post #409

Earlier quoted context omitted.

>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. ;-)

I programmed in Delphi for years and have done some toy things with Lazarus, so I'm painfully aware of the quality and reliability difference. It is quite bizarre how us programmers, who make hundreds of thousands of dollars per year, are unwilling to pay $1,400 that will make us more productive.

How about, it is quite bizarre how people who employ programmers, who make billions of dollars per years, are unwilling to pay $1,400 that will make us more productive.

Re: Programming breakthroughs we need

#488

Post by panstromek »

jmull wrote: post #482
panstromek wrote: post #457

Earlier quoted context omitted.

> The author wants to do away with the program as text source code but doesn't suggest another way to represent a program. Quoting the article: > I imagine this model as a relational database - you have tables like `structs`, `fields`, `functions`, `arguments` and relationships between them. I really want something like that pretty specifically. We still use text to edit data in SQL database, but you can also use que…

Well, SQL queries are still written in code as text. But I think you must be referring to the visualizers that many db tools have that, e.g., provide a grid view of a table or view, perhaps with QBE headers (or other means of filtering), etc? Those kinds of things are nice. They make certain tasks easy to do or certain kinds of questions easy to answer. But they are all limited too -- each is a simplification of the…

> Well, SQL queries are still written in code as text. > But I think you must be referring to the visualizers that many db tools have

No no, I really mean SQL text, writing SQL is fine and writing source code, too - I don't have problem with using text to manipulate the program. The problem is when the program is defined by source text.

Let's say a program would just be a single file SQLite database and I'd use text editor and some query console to edit it - that's a rough idea. I can write a function by hand like I do now, but the function is not saved as the literal text, it's saved as few rows in the database. Refactoring is then just running some SQL against that.

IDEs already maintain such a database in memory but they are limited by the textual sources quite a lot (especially when metaprogramming is involved). If you drop textual sources and define the program by the database directly, many IDE features become much simpler to do and accessible to the programmer directly.

I think a really good idea of the direction is the Dion demo somebody posted here. They don't have any scriptability built in, but the idea is very similar. https://media.handmade-seattle.com/dion-systems/

Re: Programming breakthroughs we need

#489

Post by feoren »

panstromek wrote: post #450
feoren wrote: post #257

Earlier quoted context omitted.

Look, of course there's lots of unexplored territory in software engineering, and we absolutely should continue to strive for better programming languages and abstractions. And we are! From reading this article, this author is looking in entirely the wrong direction for such improvements. It's not going to be some magic visual model that One thing we should not expect is that new developments will be easy for us to l…

> It's not going to be some magic visual model I wasn't talking about visual model at all. In fact, the word `visual` doesn't even appear in the article once.

A fair point, and I can't remember what my point was going to be (perhaps I meant to delete this sentence). But on the other hand, you never talk about the alternative to plain text, and I think every alternative I've ever heard of has been "visual" in some sense. In fact I'm not sure what other options there are other than "visual" and "plain text".

Perhaps what you were saying is that each developer should be able to choose whether they're working visually or in plain-text, with the underlying model being neither (binary? XML?). If you chose to work in LISP for the day, the computer would transpile the underlying model to LISP, and then transpile it back when you're done? I think this is the "magic" part, where some, what, AI does this for you? We're so far away from that being effective, and the benefits are just not there when you're truly fluent in the programming language. Every single instance I've ever seen of "Each developer can pick how it appears on their machine!" has made communication and synchronization between developers worse, not better.

Re: Programming breakthroughs we need

#490

Post by thaumasiotes »

chii wrote: post #396
thaumasiotes wrote: post #383

Earlier quoted context omitted.

That's hard to argue with, though Java isn't known for convenient UI development either.

well it depends on what you mean by convenient - java's got a UI toolkit that works out of the box for all supported environments (awt), and ontop of that is built a fair number of UI frameworks like swing (which is also part of the java standard library).

> java's got a UI toolkit that works out of the box for all supported environments

That's not a useful observation; JavaScript has that too.

> and ontop of that is built a fair number of UI frameworks like swing

Swing is what I was thinking of; I've never gotten the impression that anyone liked it.

Post reply on HN