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

271–280 of 511 posts

Re: Programming breakthroughs we need

#271

Post by mst »

jaredcwhite wrote: post #115
heurisko wrote: post #105

Earlier quoted context omitted.

> Static typing everywhere. I think the industry has generally recognised that static typing makes more reliable software. I started with PHP and have seen its type system evolve. Similarly Typescript. I since moved to other staticly typed languages. I wouldn't want to go back.

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.

This is a wild-ass guess but ... I don't use IDEs.

In fact I use original Bill Joy vi.

I suspect for most of the people we're talking to 'I' will say Int and 'S' will sat String and that's going to make our experiences very different.

Re: Programming breakthroughs we need

#272

Post by hzhou321 »

hzhou321 wrote: post #204
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…

Yes, I agree! In fact, the break through we needed is to view programming as a human cognitive operation and embrace the text, and treat manipulating text as a main component of coding. For example, I want to code foreach item in list_A do_something(item) This text is the native code in the programmer's mind, and we should allow programmer to just do so. Then, in a second layer, the programmer should code up the tran…

For those who are interested, checkout MyDef - https://github.com/hzhou/MyDef

Re: Programming breakthroughs we need

#273

Post by tacitusarc »

metaltyphoon wrote: post #180
deepakkarki wrote: post #142

Earlier quoted context omitted.

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

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.

My metric for clean code is how quickly a developer unfamiliar with it can understand it

Re: Programming breakthroughs we need

#274

Post by mst »

eternityforest wrote: post #252

Glue code is used to piece together libraries. I think it's a sign you used the right libraries and aren't reinventing. It's boring, but glue code essentially describes why your project is not the same as every other apo using those libraries. Boilerplate is a thing that happens when libraries don't have sane defaults. It's one of the more unpleasant things about Docker et al. I wish we had a dev climate where someth…

What do you have in mind when you talk about LSB for Docker?

Re: Programming breakthroughs we need

#275

Post by guhcampos »

mannykannot wrote: post #67

There's a touch of "let them eat cake" in the author's expectation that these difficult problems could be easily solved, if someone just put a little thought into it. This is perhaps most clearly revealed here: "Changing the program is the most common thing we need to do in our work, it's the reason our job even exist. And yet, most of programmer's time is spent reading or planning how to change the code." Combined w…

This. The author lost me there, I just scrolled past the rest to the conclusion.

This guys seems to believe produtivity equals amount of information produced, and fails to grasp the basics of creative work, which is exactly thinking.

Re: Programming breakthroughs we need

#276

Post by jmull »

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?

Re: Programming breakthroughs we need

#277

Post by Banana699 »

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…

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 they do because they require extensive and invasive (language-design-changing as well as program-changing) cooperation from both the language designer(s)\implementer(s), as well as the language developer(s), without this cooperation you will leave open very wide gaps. Symbolic Execution is another much much more powerful technique but, predictably, also very inefficient in general.

My way of looking at this is just frustration at the misallocation of resources. Dynamic programs already have tons of typing information available, just not in the right time and place. Your brain spends an aweful lot of time "executing" the code of a dynamic language while it's writing the code, just like the language runtime only far more slowly and with a sky high probability of error. So all what I'm saying is, why this immense suffering, when the information that your brain is in dire need of is already right there in the interpreter's data structures, just in opaque and execution-temporary forms ? It strikes me as incredibly obvious to try to bring in those typing information from the runtime into persistent transparent records available at dev-time.

Abstract Interpretation or Symbolic Executation are (fancy) tools in programming language theory's toolbox that can help us, but the simplest possible thing to try first is to make use of the already-available information that are just lying around elsewhere. To make a somewhat forced analogy : if we have a food crisis at hand, we could try fancy solutions like genetic engineering of super crops or hydroponic farming, but the dumbest possible solution to try first would be to simply bring in food from other places where its plentiful. Typing info in dynamic languages is very plentiful, it's just not there when we need it.

Re: Programming breakthroughs we need

#278

Post by agumonkey »

deepakkarki wrote: post #142
danielvaughn wrote: post #53

Earlier quoted context omitted.

I always tell my clients - the difference between writing code and maintaining it, is the difference between raising your hands and keeping them raised indefinitely.

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

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

Re: Programming breakthroughs we need

#279

Post by agumonkey »

tacitusarc wrote: post #273
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.

My metric for clean code is how quickly a developer unfamiliar with it can understand it

It seems that anything successful, for any given era, is the one thing that minimize time to understanding better than others.

Re: Programming breakthroughs we need

#280

Post by agumonkey »

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 sincerely don't know why uni don't make more classes on that only.

  - pick any software
  - try to change something
  - give a precise impact analysis
  - generate a few potential implementation paths
  - measure how fast you did all that and what failed / worked
Post reply on HN