Programming breakthroughs we need • Hacker News Board

Re: Programming breakthroughs we need

#241

Post by ElectricalUnion » Wed, Aug 17, 2022, 7:35 PM UTC

dehrmann wrote: post #82

jrm4 wrote: 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.

In my experience, the main problem is that while Excel "distributed code versioning" with a whole bunch of copies around is awful, Access databases are not only much more prone to corruption and data loss in general (even in single user, non-simultaneous ideal use cases, never mind people attempting to multiplayer edit it over network shares...), it's often very hard for non-programmers to get any insights on any data you threw on it without using Excel in the first place.

So if the data is coming from Excel, and being extracted back to Excel, why use anything besides Excel?

Re: Programming breakthroughs we need

#242

Post by wvenable » Wed, Aug 17, 2022, 7:37 PM UTC

preordained wrote: post #216

wvenable wrote: post #172

Earlier quoted context omitted.

> It's way-ay-ay more effort No, it's not. Initially it's not any more effort and in the long term it's significantly less effort. Having spent equal amounts of decades in static and dynamic typing (and strong/weak) I would absolutely take the former any day for both ease of development and correctness.

> Having spent equal amounts of decades in static and dynamic typing I hear this, as well as "eliminates whole classes of run time errors" (as if Ruby and other such codebases are just ablaze everywhere on account of this...), but I wonder if people dabbled in this and think they have it all figured out, or if they've used a modern dynamic language like Clojure that has default immutability or been in a modern Ruby c…

Some of this is just personal taste -- programmers are not all cookie-cutter intellectuals that approach all problems the same way. We're also not all working on the same problems.

For me, the idea of dynamically modifying code at runtime is like the first circle of hell. But I've programmed in enough languages to understand the appeal even if it doesn't fit with the way I like to work.

But I will take issue with blanket statements that static typing is more effort than dynamic typing with all things being equal. In my own personal experience, that is just not the case. But I wonder if many people have been so damaged by Java that anything seems better by comparison.

Re: Programming breakthroughs we need

#243

Post by Mikeb85 » Wed, Aug 17, 2022, 7:38 PM UTC

OkayPhysicist wrote: post #130

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…

I agree with you that "Re-write your Ruby project in Rust" is a terrible suggestion. Pretty much only "Re-write your C++ project in Rust" makes any sense. But it's not all bad. Elixir is pretty widely considered to be the Ruby successor. Types are replaced almost everywhere by pattern matching, the widely accepted unexpected behavior response is to just not handle it, crash the "process" (green thread) and continue o…

> Elixir is pretty widely considered to be the Ruby successor

Ummm what? Elixir is just a friendlier Erlang. It in no way replaces anything Ruby does...

Re: Programming breakthroughs we need

#244

Post by Jensson » Wed, Aug 17, 2022, 7:39 PM UTC

tasuki wrote: post #193

metaltyphoon wrote: post #180

Earlier quoted context omitted.

I always smile when a green field project starts and then they claim its “Clean Code”. No, you won’t known if it was clean code until years down and the system will need updates. Then and only then you can reflect and see how hard it was to changes things in it.

Fully agreed. No matter how "clean code", the next person or team is immediately going to label it "legacy" and complain endlessly about all the choices made by the original author(s).

Many dependencies? Updating them is hell, remove dependencies and just write the utilities we need so we can update to latest easily!

Few dependencies? Too much reinventing the wheel, delete all that code and add dependencies!

There is no perfect code, can always make different trade-offs and move things around.

Re: Programming breakthroughs we need

#245

Post by MarkSweep » Wed, Aug 17, 2022, 7:39 PM UTC

RE: Program is a model

There are some more advanced refactoring tools now available. These tools enable you to write code to detect bad code patterns and even automatically fix them. You can use them to write one-off transformations of code too. Rust has Dylint [1] and C# has Roslyn Analyzers [2]. Facebook has tooling [3] that helps writing CodeMods, enabling authors to generate changes for thousands of files at a time.

The thing I really would like to see is a smarter CI system. Caching of build outputs, so you don't have to rebuild the world from scratch every time. Distributed execution of tests and compilation, so you are not bottle-necked by one machine. Something that keeps track of which tests are flaky and which are broken on master, so you don't have to diagnose spurious build failures. Something that only runs the test that transitively depend on the code you change. Automatic bisecting of errors to the offending commit.

[1] https://github.com/trailofbits/dylint

[2] https://docs.microsoft.com/visualstudio/code-quality/roslyn-...

[3] one example: https://github.com/facebook/jscodeshift

Re: Programming breakthroughs we need

#246

Post by samsquire » Wed, Aug 17, 2022, 7:41 PM UTC

I work on this problem everyday, I am at 450+ journal entries of thoughts from concurrency, parallelism, desktop environment behaviour and programmatic expression. (see my profile)

I am working on the expression problem at this time.

Re: Programming breakthroughs we need

#247

Post by galdosdi » Wed, Aug 17, 2022, 7:41 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…

I think, as OP alludes, ultimately explorability is the heart of the problem that stops people from writing code this way.

If you don't care about other people being able to read and explore your code without a lot of preperation, you can go full hog creating layers of DSLs and metaprogramming, and with enough dedication you can end up with all your real domain level business rules in one place separate from the "infrastructure"

But if you do this, you end up with a codebase that is hard for a newcomer to ask simple maintenance questions about like "What are all the places XYZ is called from?" or "What are all the places to write to ABC" etc

So an experienced developer learns to limit their metaprogramming so their code retains easy explorability at the expense of long term sustainability. Golang is kind of an epitome of this kind of thinking. Lisps are kind of the epitome of the opposite I guess.

This is what's behind the paradox where a good dev working alone or maybe with one very like minded person can produce a level of productivity you can't match again as you add developers, till you have way more developers. The dip represents the loss due to having to communicate a common understanding of the codebase, that doesn't get adequately compensated for till you've added a lot more people.

Re: Programming breakthroughs we need

#248

Post by [deleted] » Wed, Aug 17, 2022, 7:42 PM UTC

wizofaus wrote: post #232

bcrosby95 wrote: post #170

Earlier quoted context omitted.

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.

2-4 single use type definitions per endpoint sounds pretty atypical to me, but I agree choice of language helps here, e.g. TypeScript has pretty powerful typing facilities (Pick/Partial etc) that make type reuse far more practical. It's bookkeeping yes, but definitely not pointless.

[deleted]

Re: Programming breakthroughs we need

#249

Post by feoren » Wed, Aug 17, 2022, 7:42 PM UTC

So, so much is misguided about this article. Yet, the opinions expressed are actually quite common, and I think represent some widespread and fundamental misconceptions about software development, so they're worth addressing. Apparently this comment was too long for HN, so I'll address the points individually in child comments to this one.

Re: Programming breakthroughs we need

#250

Post by feoren » Wed, Aug 17, 2022, 7:42 PM UTC

feoren wrote: post #249

So, so much is misguided about this article. Yet, the opinions expressed are actually quite common, and I think represent some widespread and fundamental misconceptions about software development, so they're worth addressing. Apparently this comment was too long for HN, so I'll address the points individually in child comments to this one.

> Most code I write doesn't do anything interesting, it's either some boilerplate or glue for connecting subsystems together.

That's your fault. There's not some line where "interesting code" lives on one side and "boring glue code" lives on the other. I agree that you don't want boring glue code, but you also don't want highly interesting code either! Every block of code should be "mildly interesting": doing about one interesting thing. Your job is to evenly spread the intrinsic complexity of the problem over code blocks to make this happen. If you're writing boring glue code that doesn't solve part of the problem interspersed with highly interesting code that handles 15 different cases, your code is lumpy!

So many people talk about spending too long on boilerplate glue code, but you're stitching this part and that part of the code together for a reason -- for a reason that can be expressed in domain logic and user stories -- right? (If not, you truly are wasting your time, but that's only because that whole code block doesn't deserve to exist.) So express the reason for stitching that code together in the glue code, and now it's mildly interesting, just like all of your code should be.

It blows my mind that the same people who complain about over-abstraction also complain about spending too long in the weeds of boilerplate code. You're so used to bad abstractions that you've given up, and then you whine "why can't I do this at a higher level!?" Because you've stopped trying, that's why! Learn to write better abstractions, and keep tweaking them when they become awkward. Finding a good abstraction is really hard, but absolutely worth it when it happens. And there are meta strategies you can learn to make it easier.