Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

151–160 of 511 posts

Re: Programming breakthroughs we need

#151

Earlier quoted context omitted.

Depends on the context. When you're programming a transactional banking system? Heck yeah I want static types. When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix.

> It's way-ay-ay more effort Just because you tend to ignore the many complexities that are actually involved in a form on a web page. It's exactly this bias that stems from untyped languages and that needs to die. Http is a complex beast and we should either replace it with something more simple and robust or at least acknowledge the complexity in our programming. Generally speaking, if doing something with a proof…

[deleted]

Re: Programming breakthroughs we need

#152

Excellent insights in this article. I've approached building web apps as data models. It works really well for our team. This was how / why we started to develop Lowdefy [0], to express a web application with a data model. We've been experiencing the benefits of this - I really need to start writing about it. Writing this app model in json or yaml might not be ideal start, but once you have that creating a IDE / GUI…

That looks pretty cool, I will look at that. I already had this idea many times (and I think anybody who done some web stuff must have had, too), but it always felt apart when you consider all edge cases you want to handle differently.

Re: Programming breakthroughs we need

#153
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 was agreeing with you, but as I thought about it, I remembered MS Access. It is used, often ships with Office, but still isn't close to as popular as Excel. Either the model is wrong, or the need isn't there.

Access used to be pretty standard for a small business trying to improve their situation, but we in the software development world spent so much time trying to work around limitations of Access and upgrading growing businesses out of Access that we took it personally and shouted to everyone not to use Access.

However, it is still taught in IT classes as a useful tool for small businesses, and it is.

Re: Programming breakthroughs we need

#154
I've often thought about similar idea(s), the program is constructed out of nested components, almost like LEGOs. When we play with LEGOs we don't need a "programming language". Or do we?

But what is a "language"? It is a set of "legos" of different types like 'verbs', 'nouns', 'adjectives' which can be combined in many different ways, but only according to the lego-rules of syntax. Some lego-pieces can not be combined together.

The ways LEGOs can be combined is a "syntax definition" the designers at the LEGO headquarters came up with. LEGOS are a language.

So I don't think it is possible to program computers without a programming language. Even configuration needs some kind of language to give you the flexibility you need.

Re: Programming breakthroughs we need

#155
post #108

Earlier quoted context omitted.

Thanks for your reply! I'm not sure if this is what you're saying, but I think the AST is not meant for "human" consumption (so it'd be outside the scope of this debate, I think), but also, translations that result in alternative and radically different representations between what you see and what I see can be problematic. "I don't understand your program, it's hard to follow." "What do you mean? The yellow and blac…

>I'm not sure if this is what you're saying, but I think the AST is not meant for "human" consumption, but also, translations that result in alternative and radically different representations between what you see and what I see can be problematic. File systems aren't meant for human consumption either, they're a practical solution to the need to store various bits of data on a disk in a coherent manner. We've made t…

Isn't a text file representation -- what you and I see when we open a text editor -- already an abstraction for human consumption? They are not filesystem-level storage.

You can view an AST, but this is never going to supplant a textual representation of code as a lingua franca between you and me. A tool that represents ASTs is always going to be a boundary between you and me (and also, a more complex tool than a simple text editor).

Re: Programming breakthroughs we need

#156

As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs). What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. St…

Have you tried Clojure?

Re: Programming breakthroughs we need

#157

>Also notice how writing the refactoring as a query over the model is actually not that difficult. I can imagine how I would write an SQL query like that in a few lines. On the other hand, writing an automated refactoring system in IntelliJ or VSCode sounds like a lifetime problem, and it's kinda unsolvable. No, it really isn't unsolvable. I saw the demo for DION[1] after following a comment[2] here, and it was close…

> No, it really isn't unsolvable.

I was talking about some specific cases - e.g. rename is unsolvable for some languages with macros (like Rust, in the linked article). Of course, DION solves that by going from opposite direction, which I think is the key (also got a lot inspired about this from their demo)

Re: Programming breakthroughs we need

#158

As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs). What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. St…

unfortunately I don't use it at work but Ruby is still by favorite language, by far; it suffers from a lack of solid math/sci libraries like Python has

Re: Programming breakthroughs we need

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

the problem is that a large amount of code produced is to support the accidental complexity of the software (let's call it infrastructure code) while the value generated by it comes from its essential complexity, that is, the application domain, as cited by the article .

while Domain Driven Design and Clean Architecture are a first step in the right direction, languages and frameworks are still limited in supporting these ideas.

It's almost insane to think that once you have a modeled domain you need to replicate them in resolvers, types, queries, etc (for graphql), resources, responses, endpoints (for rest), etc, etc.

to reinforce the point of the article and the one brought by @SKILNER, I believe that the great transformation that is to come is in maintainability through a focus on the domain

Re: Programming breakthroughs we need

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

Charles Simyoni's Intentional Software attempted systems "capable of understanding the underlying purpose" targeted at both programmers and business people. It was (hidden) parameterization all the way down. They invested several engineer decades and got no where. Microsoft bought them out for their patents.
Post reply on HN