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

261–270 of 511 posts

Re: Programming breakthroughs we need

#261

Post by amadeuspagel »

commandlinefan wrote: post #218
BlargMcLarg wrote: post #104

Earlier quoted context omitted.

Pretty sure I speak for a majority of experienced devs when I say: we don't fear abstractions. We fear abstractions made by others, including our former selves, in the all to often occurring context of "business wants it done by yesterday and we have zero idea what the requirements actually are". All the while we're still figuring things out and having 30 minute discussions on the most miniscule things.

I think you're all being too charitable to OP: "Programming would be easy if it weren't for stuck-up snobby programmers gatekeeping it" is up there with "math would be easy if it didn't have all this notation stuff" or "music would be simple if they didn't insist on writing it on those staves with those circles".

> "music would be simple if they didn't insist on writing it on those staves with those circles"

Yeah. Staves with circles are something optimized for pens, and almost every modern music software uses simpler notation. Does that make music simple? Not quite, but it certainly makes it more accessible.

Re: Programming breakthroughs we need

#262

Post by samatman »

Banana699 wrote: post #217
mtVessel wrote: post #190

Earlier quoted context omitted.

This is only feasible if the program takes no input, or a very limited set. Once you open it up to arbitrary input, no single run (or even a large set of runs) can capture everything the program might be expected to handle. How does the type profiler know that the variable that only contained values like "123" or "456" was handling identifiers , not numbers?

>This is only feasible if the program takes no input, or a very limited set. One of the insights that people making tools for dynamic languages discover over and over again is that most uses of dynamic features is highly static and constrained. In general, yes, a python program can just do eval(input("enter some python code to execute :) \n>>")), but people mostly don't do this. People use extremly dynamic and extrem…

> No current type system, static or otherwise, attempts to say "'123' is a numeric, would you like to make it an int ?"

SQLite's column type affinity will in fact do this, if you tell SQLite that a column is an INTEGER it will turn '123' into 123 but will happily take a string like "widget" and just store it.

I also wanted to add that your thoughts on this subject are well-stated and align with some work I've been patiently chipping away at, in the intersection of gradual typing and unit testing. I'll have more to say on that subject someday...

Re: Programming breakthroughs we need

#263

Post by kanzenryu2 »

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…

Also possibly including: install very old OS version, get libs and dependencies to some old version, and maybe update to a slightly newer compatible version, but not the latest. Create mock services of complex back end systems for test cases. Convert https connections to http for testing, or use unsupported TLS versions and protocols for some connections. Then you can get started!

Re: Programming breakthroughs we need

#264

Post by Myrmornis »

I think that a programming breakthrough that we need is better (graphical) formalisms for describing how software systems are intended to work. We can do better than drawing boxes and arrows with no clearly defined semantics. I don't mean formal models of how a program actually does work (i.e. I'm not talking about Petri Nets or CSP, although I'm not a computer scientist and couldn't tell you much about those things): what I'm talking about is a better language, or collection of visual formalisms, for referring to the components that we really _mean_ when we draw software designs using boxes and arrows. So something like UML, but that actually helps describe application/system function, rather than mind-numbingly documenting an OO codebase. There wouldn't necessarily be any connection between this and code (although you could perhaps imagine generating high-level automated tests from a description of how the system should work) -- the aim would simply be to have a more sophisticated way of communicating about how we intend or hope that our designs will work.

Re: Programming breakthroughs we need

#265

Post by mst »

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…

> The traditional achilles's heel of static analysis and type systems is Turing Completeness, traditional answers range from trying and giving up (Java's Object or Kotlin's Any?), not bothering to try in the first place (Ruby, Python, etc...), very cleverly restricting what you can say so that you never or rarely run into the embarrassing problems (Haskell, Rust,...), and whatever the fuck C++'s type system is.

This stanza was maybe not your primary point but it was beatifully written and multiple programmer friends of every variety mentioned have been cackling at it.

Re: Programming breakthroughs we need

#267

Post by galdosdi »

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…

Something like ruby is great for WRITING greenfield code. But without static typing, diving into and maintaining an existing codebase that you just got hired on to deal with becomes a lot more stressful.

And that's why there's still plenty of legacy Java code, but legacy ruby code over the last decade has been much quicker to get thrown away and rewritten.

I once took over a Java codebase that was clearly created entirely by people who barely knew Java and I was still able to fully understand (and, in the process, refactor it to cut it in half, because half of the code was dead code by the time I encountered it, lol) in about a week. This was not a very large codebase to be honest, but it would have been impractical without static typing and a good IDE that leverages the same.

Dude, the reason programmers fear abstraction is because they've had to maintain legacy codebases. It sounds like you've been lucky enough to mostly be able to do greenfield stuff or maintaining codebases that aren't very old. I am sure you would understand their views more if you had more experience with maintenance.

Re: Programming breakthroughs we need

#268

Post by mst »

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…

Shit. Also. This has actually been attempted.

Urbit "infers" types from functions by executing them with type objects so the relevant bindings themselves return type objects.

If you can skip over both the syntax and the creator, there are some intesting things to be found in there.

Re: Programming breakthroughs we need

#269

Post by JoeAltmaier »

So much right in that.

In the old days we had compilers linkers and loaders. They all did the wrong thing. Compilers did text translation to semantics and generated code. The linker combined code from several sources and produced a loadable image. The loader checked for compatibility and relocated an instance to an address.

Instead, the compiler should have stopped at semantics. The linker should combine semantic modules into an abstract execution model. The loader should generate code for the target machine at the target offset.

We have some of that in different paradigms today. But still we transmit far too much of lame abstraction in large wads, with all the important semantics erased.

Sigh.

Re: Programming breakthroughs we need

#270

Post by mayank »

Myrmornis wrote: post #264

I think that a programming breakthrough that we need is better (graphical) formalisms for describing how software systems are intended to work. We can do better than drawing boxes and arrows with no clearly defined semantics. I don't mean formal models of how a program actually does work (i.e. I'm not talking about Petri Nets or CSP, although I'm not a computer scientist and couldn't tell you much about those things)…

There's a hierarchical modeling paradigm/tools called C4 that (while being boxes and lines) helps with the zoom-in/zoom-out nature of understanding systems: https://c4model.com/
Post reply on HN