Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Toward a better programming

chris-granger.com

Post reply on HN
Print view View original

111–120 of 191 posts

Re: Toward a better programming

#111

Post by agentultra »

Visual representations are not terribly hard to come by in this day any age. It's almost trivial to write a little script that can visualize your tree data-structures or relations. Plenty of good environments allow us to mingle all kinds of data.

I'm more interested in programs that understand programs and their run-time characteristics. It'd be nice to query a system that could predict regressions in key performance characteristics based on a proposed change (something like a constraint propagation solver on a data-flow graph of continuous domains); even in the face of ambiguous type information. Something like a nest of intelligent agents that can handle the complexity of implementation issues in concert with a human operator. We have a lot of these tools now but they're still so primitive.

Re: Toward a better programming

#112

Post by k__ »

jowiar wrote: post #65
kens wrote: post #17

I alternate between thinking that programming has improved tremendously in the past 30 years, and thinking that programming has gone nowhere. On the positive side, things that were cutting-edge hard problems in the 80s are now homework assignments or fun side projects. For instance, write a ray tracer, a spreadsheet, Tetris, or an interactive GUI. On the negative side, there seems to be a huge amount of stagnation in…

That's pretty much the thesis of Bret Victor's "The Future of Programming" talk. It's here, for all who have missed it: http://worrydream.com/dbx/

Good talk.

I had all this stuff in the first chapter(the history) of my HCI-course at University. So, luckily, the younger programmers learn about stuff that already has been there, back in the days.

But I was baffled by what bad stuff must have happened to the world, that we ended up where we are now and not where we should have been.

Re: Toward a better programming

#113

Post by jonahx »

ibdknox wrote: post #107
jonahx wrote: post #106

I love seeing the challenges of programming analyzed from this high-level perspective, and I love Chris's vision. I thought the `person.walk()` example, however, was misplaced. The whole point of encapsulation is to avoid thinking about internal details, so if you are criticizing encapsulation for hiding internal details you are saying that encapsulation never has any legitimate use. I was left wondering if that was…

Black boxing is very, very important and necessary if we're ever going to build a complex system, BUT my point is that you should be able to see what it does if you need to. So I don't think we're at odds in our thinking.

Thanks for explaining Chris.

Re: Toward a better programming

#114

Post by seanmcdirmid »

bronxbomber92 wrote: post #110
seanmcdirmid wrote: post #96

Earlier quoted context omitted.

I don't have a problem with this. If you accidentally encode an infinite loop, you just break it on the next code change. You can memoize your token stream in an incremental lexer to use tokens as stable IDs: you use the same symbol for bar as you did for foo because the token/tree start position never changed; only the contents of the existing token happened to changed! This is what I do in YinYang, and it works wel…

I'd enjoy reading.

Ok, I'll make an effort to really write this up sometime, maybe as an SLE paper.

Re: Toward a better programming

#115

Post by RogerL »

dllthomas wrote: post #19
RogerL wrote: post #13

There's a reason the game Pictionary is hard, despite the "a picture is worth a thousand words" saying. And that is that images, while evocative, are not very precise. Try to draw how you feel. If you are using card[0][12] to refer to Card::AceSpades, well, time to learn enums or named constants. If, on the other hand, the array can be sorted, shuffled, and so on, what value is it to show an image of a specific state…

"There's a reason we don't use symbolic representation of equations, and it has nothing to do with ASCII. It's because this is implemented on a processor that simulates a continuous value with a discrete value, which introduces all kinds of trade offs." I think that's wrong. I think the reason we don't use symbolic representations is entirely due to a preference for ASCII. Whether relying on just the symbolic represe…

Okay, how does

   \integral{\integral nasty expresion dx}dy}
get implemented? (excuse the faux LaTex, I never remember the syntax)

Re: Toward a better programming

#116

Post by maccard »

fragmede wrote: post #54
falcolas wrote: post #49

Earlier quoted context omitted.

> Why do you say programming has gone nowhere because there are people who don't use the newer advancements? Speaking for myself, its because Visual Studio and its ilk don't feel like advancements. They feel like bandaids. They do their damnedest to reduce the pain of programming by automatically producing boilerplate, auto completing words, providing documentation, and providing dozens of ways to jump around text fi…

> ...while discussing pointers and garbage collection and optimizing heap allocation People still do that? We still use 'if' and 'then', but higher level languages like Ruby and Python have eliminated pointers and their ilk from day-to-day discussion, relegating heap allocation discussion to the halls of specialized conferences, while many programmers go about their day-to-day activities skipping over the pain of gar…

> People still do that? Yeah, we do. Somebody has to manage all that memory that you throw around in your ruby/python scripts.

Re: Toward a better programming

#117

Post by wtetzner »

seanmcdirmid wrote: post #78
jamii wrote: post #61

Earlier quoted context omitted.

The problem with code as text is not the visual representation but the manipulation. From the point of view of tooling for live-coding, it's incredibly painful to deal with an unstructured pile of text that at any given point may be in an invalid state (ie partially edited). Structured editing ( http://en.wikipedia.org/wiki/Structure_editor ) allows the tooling to deal with consistent, structured data whilst still ta…

It's actually not that hard to deal with text, even in partially edited states. It's just most people don't know how to build a decent incremental parser with fairly good error recovery, but some of us do.

Any chance you could point me at some resources on incremental parsing? It's something I've been interested in for a while.

Re: Toward a better programming

#118

Post by freyrs3 »

anaphor wrote: post #108
j2kun wrote: post #98

I'm concerned about Chris's desire to express mathematical formulas directly in an editing environment. Coming from a mathematician with more than enough programming experience under his belt, programming is far more rigorous than mathematics. The reason nobody writes math in code is not because of ASCII, and it's not even because of the low-level hardware as someone else mentioned. It's because math is so jam-packed…

I agree with you, and incidentally so does Gerald Sussman (co-inventor of Scheme). He helped write an entire book on Lagrangian mechanics that uses Scheme because he believes the math notation is too fuzzy and confusing for people. https://mitpress.mit.edu/sites/default/files/titles/content/...

Both this and the subsequent text on differential geometry are very good but they are written against this enormous undocumented scheme library (scmutils) that is in my opinion very difficult to debug or figure out how macros expand out.

Re: Toward a better programming

#119

Post by gridaphobe »

ibdknox wrote: post #107
jonahx wrote: post #106

I love seeing the challenges of programming analyzed from this high-level perspective, and I love Chris's vision. I thought the `person.walk()` example, however, was misplaced. The whole point of encapsulation is to avoid thinking about internal details, so if you are criticizing encapsulation for hiding internal details you are saying that encapsulation never has any legitimate use. I was left wondering if that was…

Black boxing is very, very important and necessary if we're ever going to build a complex system, BUT my point is that you should be able to see what it does if you need to. So I don't think we're at odds in our thinking.

That seems like more of an argument in favor of having all source code available (i.e. not using closed-source libraries) than an argument against OOP. The question of what code executes when you call `person.walk()` is no different than the question of what code executes when you call `(person :walk)`: it depends entirely on the value of `person`! This is the core of dynamic dispatch in OOP and higher-order functions in FP, they enable behavioral abstraction. You can impose restrictions on the behavior through types or contracts, but at the end of the day you can't know the precise behavior except in a specific call. And this is precisely where a live programming environment comes in handy.

Re: Toward a better programming

#120

Post by seanmcdirmid »

wtetzner wrote: post #117
seanmcdirmid wrote: post #78

Earlier quoted context omitted.

It's actually not that hard to deal with text, even in partially edited states. It's just most people don't know how to build a decent incremental parser with fairly good error recovery, but some of us do.

Any chance you could point me at some resources on incremental parsing? It's something I've been interested in for a while.

I wrote a workshop paper last year, but it wasn't very deep. Actually, incremental parsing, at least the way I do, doesn't really involve any special algorithms, here are the three points:

* making your lexer incremental first, memoize tokens between edits so you have something to attach trees to that will still be there after the next edit!

* Match braces (or determine indented blocks) separately before you even bother parsing. This makes incremental parsing more robust, and it is really easy to do without parsing information (unless your language overloads brace lexemes, like Java generics do! Scala didn't have this problem however). Also, autocomplete braces even if your users really hate that, because otherwise you won't have anything nice to reason about 99% of the time (indented languages are really better here for obvious reasons). Tell them to just use emacs if they don't like it.

* The last thing to do is just memoize parse trees (by attaching them to your memoized tokens) and then replay parsing on trees whenever their parses could have changed. So if their is an edit, invalidate the inner most tree, or multiple trees if the edit occurs at a boundary. If a child tree parse changes, invalidate its parents. Log your symbol table additions so you can undo them when they are no longer done on a parse (or the parse tree is deleted); trace your symbol table references if the symbol binding for the name being looked up changes, and don't worry about type checking in a separate pass, because you can just replay the parse multiple times if necessary.

The last point is quite fascinating and something I'm working on right now to turn into a more general programming paradigm. Check out:

http://research.microsoft.com/apps/pubs/default.aspx?id=2112...

Post reply on HN