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

291–300 of 511 posts

Re: Programming breakthroughs we need

#291

Post by jrm4 »

wokwokwok wrote: post #24
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'm not going to argue whether the 'world actually needs' that, or if people mostly, actually want that, or if, since excel is already there if you want it, you probably don't have to write, sell or build any more low code tools. ...because, although I could argue about those points, it's fundamentally unrelated to the OP, and issue that programming is hard, and, for a very long time, no one has really had any idea h…

Yeah, I was using Excel as shorthand for "simple enough yet powerful enough tools such that someone who is perhaps an expert in something else can build themselves something useful."

Re: Programming breakthroughs we need

#292

Post by unixbane »

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

Consider that if text had an advantage, it would be that you could cut some string in half as some sort of manipulation that saves time. What do I cut in half? Change >= to = ? There's basically no advantage of text. I don't want half of an if statement, that's what text allows me to do, it's a pointless feature that makes inputting programs harder. The basic element on the screen should be the if statement itself.

There is no advantage to a 1D language. Text is a 1D language. If you have

  if (x) {
    if (y) {
    }
  }
You are just reading it as a 2D language, but it's not. It could be

  if (x) {
    if (y) {
    }}
  }
and mean something else. (Yes I'm sure you can catch this one, but not all in general). The only way to be sure is read it from start until end, which nobody does. This is a security issue too, which I discovered when I was 12 years old reading perl scripts from milworm. By formatting text you are already conceding that 2D is better.

Re: Programming breakthroughs we need

#293

Post by aappleby »

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?

Plaintext is a serialization format for source code.

Re: Programming breakthroughs we need

#295

Post by unmasked_poker »

I solved this for me with a custom visual studio extension. It allows me to quickly specify a pattern that will create new code or change existing. The extension will show a so called Code Lens for each possibility to apply the pattern. This way for all the tasks I find my self doing over and over again I design the pattern as some kind of master and then apply it again and again on hundreds of locations in many projects. (some things I have solved this way: prisma schema, GraphQL resolvers, frontend code matching my backend API including full typings, ...). Saves me tons of work but I still have 100% controll over the code.

Re: Programming breakthroughs we need

#296

Post by int0x80 »

Banana699 wrote: post #277
int0x80 wrote: post #236

Earlier quoted context omitted.

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…

Indeed, Abstract Interpretation is powerful and beautiful as heck. Type Systems can be seen as just a special case of general Abstract Interpretation, where the types are the abstract values computed from each expression. The problem is that it requires ingenuity to devise abstract value systems that don't degrade into useless generality as unknown branches in the code 'execute'. Even types only succeed as much as th…

The problem is what I mentioned at the end of my other comment -- complex programs will get inputs from web APIs, console, database, so it's not possible to have complete runtime coverage for all paths in the interpreter on the general case.

Re: Programming breakthroughs we need

#297

Post by surement »

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.

You can already have "regular" people as software engineers if you follow basic concepts like the SOLID principles. Unfortunately many engineers are incredibly smart and they don't see the difference between writing spaghetti code with cryptic names and writing clear, legible code that normal people can follow. I've worked with people that could figure out a program written in binary if they needed to, but that meant that they never learned to write structured, sensible, readable programs.

Re: Programming breakthroughs we need

#298

Post by pojzon »

agumonkey wrote: post #278
deepakkarki wrote: post #142

Earlier quoted context omitted.

Or the difference between conceiving a child and raising one :)

raising someone else's that is already 4yo and emotionally harmed

This hits home. You win.

Maintaining and cleaning up a mess someone left behind are two different things.

Re: Programming breakthroughs we need

#299

Post by preseinger »

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.

Your tools leave you open to type errors, which you have to de-risk via unit tests. That risk is automatically eliminated by static type systems. Dynamic typing is a reasonable choice for single-developer and/or toy programs but isn't inappropriate for projects maintained by teams over time.

Re: Programming breakthroughs we need

#300

Post by westoncb »

michelledepeil wrote: post #283
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?

I think you misinterpreted that. Their gripe wasn't with a textual representation of code, but the fact that we interact with it as text, not in any form. And that fundamentally limits the power of the tools we use to interact with it, according to the OP. Of course everything can have a textual representation eventually. Your final question, "what will you have instead?", really nails the point of the article, as th…

I propose one solution here ("How to Make View-independent Program Models"): http://westoncb.blogspot.com/2015/06/how-to-make-view-indepe...

—but many people have tackled or are tackling this problem ("structure" or "projectional" editor will lead you there if you're curious).

Post reply on HN