Programming breakthroughs we need • Hacker News Board

Re: Programming breakthroughs we need

#311

Post by preseinger » Wed, Aug 17, 2022, 9:35 PM UTC

ablob wrote: post #198

preseinger wrote: post #174

> Program is not a text, [it is] a model I don't think so. In fact, I think this perspective is actively harmful. A program is whatever the human beings who maintain that program operate against. I mean there are many possible representations of a program, and there are different ways to evaluate those models, but the model that most precisely expresses the AST of the logic of the program, or the call sequence of the…

How is it harmful? > A program is whatever the human beings who maintain that program operate against This does neither invalidate the statement that "Program is not a text", nor that "[it is] a model". > And for the moment that's source code. How is wanting to change that harmful? Source code can have flaws like ambiguity (see C++'s need for typename). Deeming a call for improvement on the existing representation of…

> I think what matters is what the computer actually does. Whatever I, as a human, read and interpret has no meaning at all if the computer decides to "read and interpret" it differently. And the only limit with representing what the computer actually does should be your imagination.

Well, I understand this perspective, but I judge it to be backwards. The computer should be understood as secondary to the human. Mechanical sympathy is necessary for useful software but the goal of software must not be mechanical.

Re: Programming breakthroughs we need

#312

Post by jhomedall » Wed, Aug 17, 2022, 9:36 PM UTC

bcrosby95 wrote: post #170

choeger wrote: post #140

Earlier quoted context omitted.

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

Why would static types require you to create additional classes?

Re: Programming breakthroughs we need

#313

Post by marcosdumay » Wed, Aug 17, 2022, 9:38 PM UTC

082349872349872 wrote: post #33

> usually the biggest problem is an enormous amount of CRUD boilerplate that looks very similar in each project, but it's nevertheless different in important details. Once upon a time, a lot of microprocessor code was written in assembly. Then C came along, and many of the assembly people said: "whoah, hold on, I use different calling conventions in different places for good reason; what do you mean every C function…

The interesting part is that no, function calls do not all use an entire stack frame, unless you compile your code for debugging. Compilers are smart enough to reencode the calling into just registry shifting, or even inline the entire thing.

Re: Programming breakthroughs we need

#314

Post by BurningFrog » Wed, Aug 17, 2022, 9:42 PM UTC

vlunkr wrote: post #305

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've also wondered if it's time to back off on agile a bit. Or at least "agile" as it is implemented generally, which means we get to make up new requirements every two weeks. In my experience, the hardest maintenance problems occur because we're trying to re-shape code into something that the developers never knew would be coming down the line. Spending lots more time up-front deciding requirements would go a long w…

The part of Agile a lot of people ignore is the phase when, after your code works, you spend as much time as it takes to make it well structured and readable to others.

Re: Programming breakthroughs we need

#315

Post by chowells » Wed, Aug 17, 2022, 9:44 PM UTC

Banana699 wrote: post #88

bsedlm wrote: post #63

Earlier quoted context omitted.

yes. I wish I could somehow get to work on a blend between: a decompiler, debugger, emulator, static analyzer, memory profiler, and so on. The idea being some kind of a runtime for assembly code which does not actually execute the program but allows one to understand it in different sematinc levels, or dunno.. this is a very raw idea. needs a lot of work (and a lot more knowldedge) to set down. too bad none of the pr…

I think dynamic analysis is incredibly powerful and criminally underused in IDEs and other dev tools. I have thought of an idea about 6 months ago that has been fermenting in my mind since then : what if (e.g.) a Python VM had a mode where it records all type info of all identifiers as it executed the code and persisted this info into a standard format, later when you open a .py file in an IDE, all type info of the o…

I think if you have to run a whole program to understand a small part of it, you've already lost. The most valuable tools are a REPL that can execute units of your code, and a language that enforces purity and immutability so that local reasoning is more likely to be sufficient.

Re: Programming breakthroughs we need

#316

Post by thrown_22 » Wed, Aug 17, 2022, 9:44 PM UTC

unixbane wrote: post #292

preseinger wrote: post #174

> Program is not a text, [it is] a model I don't think so. In fact, I think this perspective is actively harmful. A program is whatever the human beings who maintain that program operate against. I mean there are many possible representations of a program, and there are different ways to evaluate those models, but the model that most precisely expresses the AST of the logic of the program, or the call sequence of the…

Programming is an exercise in manipulating semantic objects which is why stuff like blueprints in unreal engine are so easy to use. It will just get better and text will become an obsolete vestige, regardless of whatever idea you have of this being "harmful". I really don't think a character encoding with 30 ways to control the terminal (and now extended to encode emojis) is the be all end all way of writing and edit…

So what happens when you have a 10 deep nested if tree?

Your answer would be to not do it because it doesn't fit nicely in a 2d page. My answer would be to put it in a 1d line and not bake semantics into presentation.

But you can't pretend that the space of programs isn't infinite dimensional when the space we work in is only 3d. Regardless of how clever you are using a medium with a dimensionality higher than 1 for semantics will always result in expressions you can't express.

This is why we've stuck with text.

It's 1d, but we can make it 2d to help understand what is going on visually in the simple cases humans can understand intuitively. Yet it is complex enough to represent any possible object.

Re: Programming breakthroughs we need

#317

Post by preseinger » Wed, Aug 17, 2022, 9:45 PM UTC

unixbane wrote: post #292

preseinger wrote: post #174

> Program is not a text, [it is] a model I don't think so. In fact, I think this perspective is actively harmful. A program is whatever the human beings who maintain that program operate against. I mean there are many possible representations of a program, and there are different ways to evaluate those models, but the model that most precisely expresses the AST of the logic of the program, or the call sequence of the…

Programming is an exercise in manipulating semantic objects which is why stuff like blueprints in unreal engine are so easy to use. It will just get better and text will become an obsolete vestige, regardless of whatever idea you have of this being "harmful". I really don't think a character encoding with 30 ways to control the terminal (and now extended to encode emojis) is the be all end all way of writing and edit…

Semantic objects are non-dimensional. In fact they are probably best understood as simply ideas. Humans have been effectively incepting ideas in each other since the birth of language and writing. Text is, demonstrably, the best way to convey semantic ideas among human beings.

Re: Programming breakthroughs we need

#318

Post by bsedlm » Wed, Aug 17, 2022, 9:46 PM UTC

int0x80 wrote: post #236

Banana699 wrote: post #88

Earlier quoted context omitted.

I think dynamic analysis is incredibly powerful and criminally underused in IDEs and other dev tools. I have thought of an idea about 6 months ago that has been fermenting in my mind since then : what if (e.g.) a Python VM had a mode where it records all type info of all identifiers as it executed the code and persisted this info into a standard format, later when you open a .py file in an IDE, all type info of the o…

Something very close to this can be done and it's in fact done already by static analysis. Static analysis doesn't have any Turing complete problem. Static analysis has a limitation of providing complete answers because of the halting problem, but it can provide instead sound answers. That is, static analysis can provide all possible runtime types for any given (e.g. python) expression. This can be accomplished by do…

do you know any textbooks on abstract interpretation?

Re: Programming breakthroughs we need

#319

Post by preseinger » Wed, Aug 17, 2022, 9:47 PM UTC

david927 wrote: post #234

preseinger wrote: post #174

> Program is not a text, [it is] a model I don't think so. In fact, I think this perspective is actively harmful. A program is whatever the human beings who maintain that program operate against. I mean there are many possible representations of a program, and there are different ways to evaluate those models, but the model that most precisely expresses the AST of the logic of the program, or the call sequence of the…

I couldn't disagree more. You don't buy a drill, you buy a way to get a hole in, say, wood. That's the core product. The core product of 'programming' is a software solution. So far, the best way to approach it is text. But... text is an incredibly poor model! It's almost literally an accounting system of "Jake spent fifty dollars." It's text which is "actively harmful," and we see it all around us in the absence of…

Programs are ideas that need to be understood, modeled, and manipulated by humans. Text is the best available way to incept ideas into the minds of humans.

Re: Programming breakthroughs we need

#320

Post by pendar747 » Wed, Aug 17, 2022, 9:48 PM UTC

galdosdi wrote: post #247

dlojudice wrote: post #159

Earlier quoted context omitted.

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 "inf…

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

Wow I couldn't agree more with this point. You put it perfectly. I worked alone and later with one other developer on a project and it felt way more productive than my current team of 5 developers!