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

141–150 of 511 posts

Re: Programming breakthroughs we need

#141

Post by RyanCavanaugh »

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…

This is how JavaScript intellisense in Visual Studio used to work, except that the program was executed "behind the scenes" using a trimmed-down VM that could execute without side effects or infinite loops. It was eventually abandoned due to poor performance, predictability, and stability.

The problem is this dilemma: If you have to wait for a "real" execution of a program, then very reasonable expectations like "I can see a local variable I just declared" doesn't work. If you try to fake-execute a program, you have problems like trying to figure out what to do with side-effecting calls, loops, and other control flow problems.

Trying to reconcile a previous type snapshot with an arbitrary set of program edits was tried by an early version of TypeScript and wholly abandoned because it's extremely difficult to get right, and any wrongness quickly propagates and corrupts the entire state. The flow team is still trying this approach and is having a very hard time with it, from what I can tell.

Re: Programming breakthroughs we need

#142

Post by deepakkarki »

danielvaughn wrote: post #53
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 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 :)

Re: Programming breakthroughs we need

#143

Post by [deleted] »

danielvaughn wrote: post #53
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 always tell my clients - the difference between writing code and maintaining it, is the difference between raising your hands and keeping them raised indefinitely.

[deleted]

Re: Programming breakthroughs we need

#144

Post by duped »

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.

It's actually less effort since you save time writing unit tests.

Show me an untyped program and I'll show you a program missing tests and containing bugs. Static typing saves time and money.

Re: Programming breakthroughs we need

#145

Post by [deleted] »

simplify wrote: post #124
jaredcwhite wrote: post #115

Earlier quoted context omitted.

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.

I would LOVE static typing when programming a form on a web page. However, it's the fault of HTML that this is bad, not static typing itself. Although, in theory, one could write a parser to inject what form elements are available into the type system... :)

[deleted]

Re: Programming breakthroughs we need

#146

Post by shpongled »

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 personally find strong static typing (a la Rust, Haskell, Standard ML) to be much more expressive and with better UX/DX by miles.

Re: Programming breakthroughs we need

#147

Post by w10-1 »

Programming is encoding: some reduction of reality into a model suited to algorithms doing what we need.

The reduction to model and scope to algorithms are necessary and unavoidable. All of the criticisms made are objections to the selected model or limited set of algorithms.

That includes text as the standard "model". By contrast, IBM VisualAge in the 1990's had a true AST-based model of the code, and showed text as views. It did (some) amazing things, but people hated it because there was no way to make it do other things they wanted.

I would add the disparity between the granularity of commits and comments. Clearly, I should be able to describe specific changes in a file and provide high-level account of a long-running task without collapsing everything into one history.

Proposal: A single AST model, configurable for multiple languages, with JVM & LLVM back-ends, and automagic support for IDE's via LSP and program transforms like language conversion, slicing, and aspects.

The killer app there would be transforms for parallelism to the processor-specific vector instructions. That would capture more of the value of the oncoming onslaught of processor architectures.

Re: Programming breakthroughs we need

#148

Post by throaway2323221 »

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…

Ex-RoR dev here. I'm not seeing any evidence of Ruby being valuable outside of rails. If I wanted magic I can just use a lisp such as clojure.

Re: Programming breakthroughs we need

#149

Post by sankha93 »

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…

There has been attempts as you describe before. I can specifically point to work done in Ruby by my PhD advisor using the exact profiling approach, and then static typing from that: http://www.cs.tufts.edu/~jfoster/papers/cs-tr-4935.pdf

> you're already executing the code for free anyway

Based on my experience of working on similar domain of type systems for Ruby (though not the exact approach you describe), this turns out to be the ultimate bottleneck. If you are instrumenting everything, the code execution is very slow. A practical approach here is to abstract values in the interpreter (like represent all whole numbers are Int). However, this would eliminate the specific cases where you can track "Dict[String->int] WHERE 'foo' in Dict and Dict['bar'] == 42". You could get some mileage out of singleton types, but there are still limitations on running arbitrary queries: how do you record a profile and run queries on open file or network handles later? How do you reconcile side effects between two program execution profiles? It is a tradeoff between how much information can you record in a profile vs cost of recording.

There is definitely some scope here that can be undertaken with longer term studies that I have not seen yet. Does recording type information (or other facts from profiling) over the longer term enough to cover all paths through the program? If so, as this discussion is about maintaining code long term, does it help developers refactor and maintain code as a code base undergoes bitrot and then gets minor updates? There is a gap between industry who faces this problem but usually doesn't invest in such studies and academia who usually invests in such studies but doesn't have the same changing requirements as an industrial codebase.

Re: Programming breakthroughs we need

#150

Post by panstromek »

yaccz wrote: post #98

> the text is just a tool to manipulate some abstract model of the program. yup. > When you think about it this way, it becomes clear that using a textual source code is really inefficient way to manipulate this model. Hard nope. All the attempts at different approach were a failure so far. Text so far is the best thing we have because text can be analyzed formally and computed with by computers. This is the result o…

To be clear, I don't think we should get rid of text completely, or use some drag&drop UI or some visual model. It's just the program should be defined by the semantic model first and then viewed/edited however it is practical (often by text again).

And we already do this in many places - many common code changes we do are already automated by IDE (which maintains the model in memory), so we don't edit the text directly and we don't even think about it that way, we think about how we want to transform the model (ie. extract a function), not about how the text moves between files.

> Text so far is the best thing we have because text can be analyzed formally and computed with by computers.

This doesn't make too much sense to me. Using the approach I talk about would actually make that much easier, because tools wouldn't need to parse the text and work directly on the semantic representation (i.e. it's much easier to query a database than extract the information from textual sources)

Post reply on HN