Programming breakthroughs we need • Hacker News Board

Re: Programming breakthroughs we need

#161

Post by picsao » Wed, Aug 17, 2022, 5:38 PM UTC

dlojudice wrote: post #159

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…

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…

No post body was provided.

Re: Programming breakthroughs we need

#162

Post by AnimalMuppet » Wed, Aug 17, 2022, 5:38 PM UTC

julius wrote: 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…

Here's a phrase for you: "malicious compliance".

When I say "what" but not "how", I am trusting the system to be reasonable in the "how" it generates. But "reasonable" depends on my situation. Unless the system knows and understands that, it may easily do what I said, but do something that is anywhere from non-optimal to disastrous.

And if I have to say enough to prevent that - to prevent all the ways that could happen - is that more efficient, or less, compared to just writing the code myself?

Re: Programming breakthroughs we need

#163

Post by cannabis_sam » Wed, Aug 17, 2022, 5:39 PM UTC

jaredcwhite wrote: post #99

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…

>Static typing everywhere. It's utterly baffling to me.

I find it far more baffling that people don’t want to offload the trivial parts of the mental work of ensuring the programs they write makes the minimum of sense.

I also jumped on the dynamically typed bandwagon after using low value type systems like java’s, but after using haskell, ocaml, typescript, purescript, rust, and especially elm, I realized that they let me focus on the business value over the incidental complexity from having any value potentially being anything…

(Even Agda and Idris have been amazing revelations in this context, but at that point the type theory does start to consume more time than necessary for ordinary development)

Re: Programming breakthroughs we need

#164

Post by gervwyk » Wed, Aug 17, 2022, 5:41 PM UTC

panstromek wrote: post #152

gervwyk wrote: post #101

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.

Thanks. Yeah, we’ve been building all kinds of things. Anything form dashboards, crud, public forms, ver advanced forms with complex validation and logic and even full MRP and CRMs. Of course there is an egde, for now it’s stuff like pub/sub, server oauth etc. But mostly seems like these edge cases can be supported as features later.

It seems like the abstraction is working really well thus far, separating the business logic, into operator functions, from the app and backend stuff is really key to this.

Really looking forward to the next phase where we get to create all nice programs tools in front of the program model to provide a superior dev ex :)

Re: Programming breakthroughs we need

#165

Post by zestyping » Wed, Aug 17, 2022, 5:41 PM UTC

jaredcwhite wrote: post #99

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…

Oh really? Suppose x = 123 and x = "123" were "THE SAME THING".

What's x + "42"?

What's x + "042"?

What's x + "a"?

What's x + "e2"?

What's x + "e2" + 12345?

What's x + "1,500"?

What's 1 / x?

Re: Programming breakthroughs we need

#166

Post by galaxyLogic » Wed, Aug 17, 2022, 5:41 PM UTC

w10-1 wrote: post #147

Programming is encoding: some reduction of reality into a model suited to algorithms doing what we need. The reduction to model and scope to algorithms are necessary and unavoidable. All of the criticisms made are objections to the selected model or limited set of algorithms. That includes text as the standard "model". By contrast, IBM VisualAge in the 1990's had a true AST-based model of the code, and showed text as…

One of the brilliant things about Smalltalk was its change-management. You didn't just store programs, you stored "changes" to existing programs which assumes a context of existing 'classes" into which such changes can be applied.

Contrast that with current CVSes like git where you don't store changes to the objects you create or have created earlier, but just changes to which files exist in your (git-based virtual) file-system.

Git only knows about things like "files" and "folders", not about objects the user creates. Therefore you can not view a git-repo as a set of changes to your "program", it is only a set of changes to files and folders.

Re: Programming breakthroughs we need

#167

Post by riskable » Wed, Aug 17, 2022, 5:42 PM UTC

swatcoder wrote: post #71

mynegation wrote: post #50

Earlier quoted context omitted.

What is your alternative then? Vendored-in dependencies with their ossified security vulnerabilities? Or figuring out homegrown code of dubious quality for the functionality that is not core business of the company/product?

Nothing so dramatic. The alternative is judicious inclusion of dependencies rooted in thoughtful, experienced engineering. Robust, comprehensive libraries from reliable vendors can provide a lot of value and are slow to rot. These can be anticipated and added early so that they’re made good use of and can become the first tool to reach for before adding other dependencies. Think React, lodash, QT, boost, etc. Meanwhi…

> Robust, comprehensive libraries from reliable vendors

Hah! In all my years the biggest, most difficult vulnerabilities/problems to remediate all came from vendor-made (90% of the time closed source) software. With the free, open source stuff the problems are usually very minor but even if they're BIG we'll pretty much always get fixes and deploy them faster than if we had to wait on a vendor.

The more popular the OSS the safer it is but even niche OSS tools/libraries are easier to work with by definition because we can look at and modify the source to correct the problem even if the original maintainer hasn't gotten around to it yet. This is actually a big reason why Python is preferred where I work: The code is inherently visible and fixable.

Re: Programming breakthroughs we need

#168

Post by mst » Wed, Aug 17, 2022, 5:45 PM UTC

> If the text is just a view, it doesn't matter how it's written. Let everybody customize it the way they want. I don't care if you put opening brace on a new line, I don't even want to care.

Interlisp did this.

Re: Programming breakthroughs we need

#169

Post by [deleted] » Wed, Aug 17, 2022, 5:46 PM UTC

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…

[deleted]

Re: Programming breakthroughs we need

#170

Post by bcrosby95 » Wed, Aug 17, 2022, 5:50 PM UTC

choeger wrote: post #140

jaredcwhite wrote: post #115

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…

It's not complexity. It's pointless bookkeeping.

If you don't cut corners on your static typing, you're looking at 2-4 single use classes per API endpoint: 1-2 for the web layer, and 1-2 when going into the domain logic layer.

Many people skimp and just re-use the core domain class for everything, which is the worst of both worlds.

I'll take a map, spec, and select-keys over this all day long.