Live data from Hacker News

Toward a better programming

chris-granger.com

31–40 of 191 posts

Re: Toward a better programming

#31
post #26
post #14

Earlier quoted context omitted.

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…

Sure, there are plenty of cases where visualization is helpful. But I see so many blog posts about it, and not much in the way of actual progress. Take the card again. It's your example, after all. I cannot think of any way to use that to, say, write a small AI to play poker. I suppose I could see a use in a debugging situation for my 'hand' variable to display a little 5@ symbol (where @ is the suit symbol). But oka…

> So I need a graphics designer to make a symbol for a card.

I think this is the crux of the debate. The point isn't high quality visualizations, it's about bringing the simple little pictures you'd draw to solve your problem directly into the environment. Can you draw a box and put some text in it? Tada! Your own little representation of a card.

I'm not suggesting that you hire people out to build your representations :) This is about providing tools for understanding. Maybe you don't see value in that, and there's no reason you can't just keep seeing things as plain raw text (that's just a representation itself).

> Anyway, scale things up in a way that I don't have to write so many matplotlib calls and you will have my attention.

Give us a bit and I think we can provide a whole lot more than just that. But we'll see!

Re: Toward a better programming

#32
post #23

I liked this article. I particularly liked the way the author attacked the problem by clearing his notions of what programming is and attempting to come at it from a new angle. I'll be interested to see what his group comes up with. That said, I think that fundamentally the problem isn't with programming, it's with US. :) Human beings are imprecise, easily confused by complexity, unable to keep more than a couple of…

I agree. I beleive that most of the incidental complexity has to do with the fact that in end, every single thing greater than a single bit in the digital realm is a convention.

A byte is a convention over bits. An instruction is a convention over bytes. A programming language is a convention over instructions.

It turns out that every time someone sets out to solve a problem with programming, they create their own convention.

It just so happens that either there is no convetion over how to create covnentions, or it is just not followed and thus creates a paralel convention.

We cannot get our arbitrary conventions in line with each other, unless we plan in advance.

Considering, its amazing how far we have come in the middle of this chaos of unrestrained creation.

Re: Toward a better programming

#33
The standard deviation is a poor example IMO, in many languages you can get much closer to mathematical notation.

    def stddev(x):
        avg = sum(x)/len(x)
        return sqrt(sum((xi-avg)**2 for xi in x) / len(x))

    stddev xs = let avg = sum xs / length xs
                in sqrt $ sum [(x-avg)**2 | x 

Re: Toward a better programming

#34
post #18

Earlier quoted context omitted.

In your example you used an ace of spades. Your picture took up half my screen. I can't imagine trying to actually manipulate logic when each element is taking up half my screen - can you? Instead, I can just create a variable called AceSpades. It's not as... philosophical? but it's a million times more practical. Instead of needing an artist to come and draw up a new symbol for a concept I've created, I can just wri…

"[Graphical languages] work extremely well as limited languages for very constrained problems" Even that might need a citation...

[I'm curious why I got downvoted above - did I miss something?]

I don't think that needs a citation though. Any GUI is a graphical language for a constrained problem. I could use a generic text language to post this comment to HN, or I can use a specialized graphical language that provides me with this resizable text input box and reply button. It's extremely constrained in this case. If it had GUI elements for doing formatting, or the ability to post comments to other websites, it would be a less constrained graphical language. As you reduce constraints the graphical language would either need the ability to create new concepts or have many additional concepts predefined. So to answer your question about a citation: this very comment box is my citation. It works better than a purely text based input for submitting this comment.

Obviously for a general language you can't predefine all the required concepts which means they need to be user defined. User defining concepts in a graphical language is a difficult task as it requires creating uniquely human recognizable symbols for the new concepts.

You have two ways to get those new human recognizable symbols - you can generate them with an AI, or a human must generate them. AI is nowhere near able to generate symbols for concepts it doesn't understand as it would need to be a true AI with the ability to learn and understand new concepts. Having your graphical language's users define new concepts in effect makes those users into language designers. This is a bigger problem than it sounds as language design is an extremely difficult problem, and I personally don't want to be designing a language when I'm trying to solve a problem as I'll no doubt get the language design wrong if I'm focused more on the problem than the language design.

Re: Toward a better programming

#35
Programming is taking the patterns which make up a thought and approximate them in the patterns which can be expressed in a programming language. Sometimes the thoughts we have are not easily expressed in the patterns of the computer language which we write in. What is needed is a computer language which pulls the patterns from our thoughts and allows them to be used within the computer language. In other words we need to automatically determine the correct language in which to express the particular problem a user is trying to solve. This is AI, we need compression - modularisation of phase space through time. The only way to bring about the paradigm shift he is describing in any real sense is to apply machine learning to programming.

Re: Toward a better programming

#36
post #10

Wolfram Language addresses a lot of these points. Equations and images both get treated symbolically, so we can manipulate them the same way we manipulate the rest of the "code" (data).

It doesn't handle the "true" debugging discussed in the article. One of the goals of the author is to move away from stepping through breakpoints and print statements to watch data "flow" through a program.

Re: Toward a better programming

#37
post #26
post #14

Earlier quoted context omitted.

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…

Sure, there are plenty of cases where visualization is helpful. But I see so many blog posts about it, and not much in the way of actual progress. Take the card again. It's your example, after all. I cannot think of any way to use that to, say, write a small AI to play poker. I suppose I could see a use in a debugging situation for my 'hand' variable to display a little 5@ symbol (where @ is the suit symbol). But oka…

I think the problem is the card example is a bad one. 5H is already acceptable for nearly every case, since there is so little data in the image.

Also it is probably good to remember that most of the good examples of doing this have probably already been done, debug visualizations in physics engines are a great example, a perfect way of showing incredibly complex data.

The only way to expand on that would be to add time and ease isolating a piece of data.

Re: Toward a better programming

#38
Chris, have you read Prof. David Harel's[1] essay Can Programming be Liberated, Period?[2]

The sentiments expressed in the conclusion of Harel's article Statecharts in the Making: A Personal Account[3] really jumped out at me last year. When I read your blog post, I got the impression you are reaching related conclusions:

"If asked about the lessons to be learned from the statecharts story, I would definitely put tool support for executability and experience in real-world use at the top of the list. Too much computer science research on languages, methodologies, and semantics never finds its way into the real world, even in the long term, because these two issues do not get sufficient priority.

One of the most interesting aspects of this story is the fact that the work was not done in an academic tower, inventing something and trying to push it down the throats of real-world engineers. It was done by going into the lion's den, working with the people in industry. This is something I would not hesitate to recommend to young researchers; in order to affect the real world, one must go there and roll up one's sleeves. One secret is to try to get a handle on the thought processes of the engineers doing the real work and who will ultimately use these ideas and tools. In my case, they were the avionics engineers, and when I do biological modeling, they are biologists. If what you come up with does not jibe with how they think, they will not use it. It's that simple."

[1] http://www.wisdom.weizmann.ac.il/~harel/papers.html

[2] http://www.wisdom.weizmann.ac.il/~harel/papers/LiberatingPro...

[3] http://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.H...

Re: Toward a better programming

#39
I've been lucky to write at least one small application per year, although most of my work is now on the creative side: books, videos, web pages, and such.

So I find myself getting "cold" and then coming back into it. The thing about taking a week to set up a dev environment is spot on. It's completely insane that it should take a week of work just to sit down and write a for-next loop or change a button's text somewhere.

The problem with programming is simple: it's full of programmers. So every damn little thing they do, they generalize and then make into a library. Software providers keep making languages do more -- and become correspondingly more complex.

When I switched to Ocaml and F# a few years ago, I was astounded at how little I use most of the crap clogging up my programming system. I also found that while writing an app, I'd create a couple dozen functions. I'd use a couple dozen more from the stock libraries. And that was it. 30-40 symbols in my head and I was solving real-world problems making people happy.

Compare that to the mess you can get into just getting started in an environment like C++. Crazy stuff.

There's also a serious structural problem with OOP itself. Instead of hiding complexity and providing black-box components to clients, we're creating semi-opaque non-intuitive messes of "wires". A lot of what I'm seeing people upset about in the industry, from TDD to stuff like this post, has its roots in OOP.

Having said all that and agreeing with the author, I'm a bit lost as to just what the heck he is ranting on about. I look forward to seeing more real tangible stuff -- I understand he's working on it. Best of luck.

Re: Toward a better programming

#40

Chris, have you read Prof. David Harel's[1] essay Can Programming be Liberated, Period? [2] The sentiments expressed in the conclusion of Harel's article Statecharts in the Making: A Personal Account [3] really jumped out at me last year. When I read your blog post, I got the impression you are reaching related conclusions: "If asked about the lessons to be learned from the statecharts story, I would definitely put t…

I haven't seen that, thanks so much for the pointer!

> in order to affect the real world, one must go there and roll up one's sleeves

This has always been our strategy :) Whatever we do come up with, it will be entirely shaped by working with real people on coming up with something that actually solves the problem.

Post reply on HN