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

101–110 of 191 posts

Re: Toward a better programming

#101

Post by _random_ »

jimmaswell wrote: post #66
deckiedan wrote: post #45

Earlier quoted context omitted.

That's kind of the thing... that there are other ways of programming (IDE instead of text editor), but for interesting languages, there's no clear cut proof that IDEs are actually better. For languages specifically such as Java, which have very verbose syntax, and huge amounts of boilerplate for large projects, then sure, an IDE is an improvement. But even IDEs, really, haven't much changed. And the fact that we even…

How are you defining an "interesting" language? Just your opinion? I'd say C# is a pretty interesting and powerful language that's extremely well-complemented by VS. There's a lot more to an IDE than code generation and autocomplete (even if those are very useful and save me a ton of time). Finding all references to a variable or function (simple text searching does not do this nearly as well - the IDE actually analy…

Furthermore Visual Studio let's you define custom debug visualisation quite easily:

http://www.codeproject.com/Articles/13127/Create-a-Debugger-...

http://visualstudiogallery.msdn.microsoft.com/eedc48e7-5169-...

(but of course one has to think outside of the "evil MS" box)

Re: Toward a better programming

#102

Post by jamii »

zwieback wrote: post #6

Interesting work and I really liked the LightTable video but I think there's a reason these types of environments haven't taken off. To understand why programming remains hard it just takes a few minutes of working on a lower-level system, something that does a little I/O or has a couple of concurrent events, maybe an interrupt or two. I cannot envision a live system that would allow me to debug those systems very we…

It depends entirely on how much state they need to capture. Ocaml has long had a time travelling debugger (http://caml.inria.fr/pub/docs/manual-ocaml-400/manual030.htm...) which is very useful in the small. Data-centric languages like Bloom (http://www.bloom-lang.net/) can cheaply reconstruct past states using the transaction log. Frameworks like Opis (https://web.archive.org/web/20120304212940/http://perso.elev...) allow not only moving forward and backwards but can exhaustively explore all possible branches using finite state model-checking. The key in each case is to distinguish between essential state and derived state. http://shaffner.us/cs/papers/tarpit.pdf‎ has more to say on that front.

Re: Toward a better programming

#104

Post by jerf »

ibdknox wrote: post #14
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…

It's not about choosing one or the other, it's about allowing both. I can use symbols (though not sentences or other usefully descriptive language), but do I have an opportunity to represent those symbols at all? no. I'm not saying we should forsake language, if you look at the now very out of date Aurora demo, all the operations have sentence descriptions. This certainly isn't an all or nothing thing. If it makes se…

I would be interested in seeing you take a larger chunk of code and convert it to a more symbol-rich representation. Showing a single card, especially a very large one, isn't a good representation of the idea. I would also appreciate a description of how exactly I inserted these symbols into the editor.

I will spot you that I won't natively know the language in question. In turn, I warn you that the most likely criticism I will make is that you've greatly increased the cognitive load of what I have to understand to understand your code without a corresponding payoff, even accounting for fluency in the vocabulary. (I say this not to be a jerk, but precisely to issue fair warning so you can head it off at the pass.) I will also spot fluency in your paradigm of choice... while I hope that the result is not a superficial syntax gloss on top of fold & map, I am happy to accept that I would need to know what those things are.

(I've come to start issuing the same challenge to anyone who thinks a visual programming language is the answer to our programming complexity problems, for instance. Don't draw me three boxes and two lines showing a simple map transform. Draw me something not huge, but nontrivial, say, the A-star algorithm. Then tell me it's better. Maybe it is, if you work on it enough, but don't scribble out the equivalent of "map (+1) [1, 2, 3]" and tell me you've "fixed" programming. Trivial's trivial in any representation.)

Re: Toward a better programming

#105

Post by jonathanedwards »

jamii wrote: post #89
jonathanedwards wrote: post #68

Earlier quoted context omitted.

Here's some meat. So how does FP fall down?

Explicitly managing hierarchical data structures leads to a lot of code that isn't directly related to the problem at hand. A lot of attention is dedicated to finding the correct place to put your data. Compared to eg relational or graph data models, where that kind of denormalisation is understood to be an optimisation made at the expense of program clarity / flexibility. The pervasive use of ordering in functional…

OK, you don't need to convince me! I've been saying for years that the central problem is coordinating state updates, and have been proposing that languages should automatically manage time for us like the way they automatically manage memory. Sean McDirmid and I have submitted a paper on it to Onward.

But as to graphs vs trees I don't think it is so clear-cut. Good arguments on both sides of that issue.

Re: Toward a better programming

#106

Post by jonahx »

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 Chris's position, but convinced it couldn't be.

Re: Toward a better programming

#107

Post by ibdknox »

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.

Re: Toward a better programming

#108

Post by anaphor »

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/...

Re: Toward a better programming

#109

Post by anaphor »

Just a few quotes from Alan Perlis:

There will always be things we wish to say in our programs that in all known languages can only be said poorly.

Re graphics: A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.

Make no mistake about it: Computers process numbers - not symbols. We measure our understanding (and control) by the extent to which we can arithmetize an activity.

Re: Toward a better programming

#110

Post by bronxbomber92 »

seanmcdirmid wrote: post #96
ibdknox wrote: post #81

Earlier quoted context omitted.

But the hard part isn't dealing with invalid parses and error recovery. The hard part is dealing with completely valid bits of code that aren't yet finished: (doseq [x (range|cursor|)] ) You can wait until the end of time, but that won't finish ;) Whereas I probably wanted to get out (range 10) before it went off and looped forever. Text also doesn't provide you with stable IDs. If I previously had function "foo" in…

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.
Post reply on HN