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

71–80 of 191 posts

Re: Toward a better programming

#71

Post by sparkie »

sold wrote: post #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

I think it was a poor choice of example anyway - the code solution is superior because it is far more descriptive of what is happening. The math notation requires existing knowledge which without it, you're basically screwed in attempting to understanding what the hell it does. With code you can search for terms and see what they do, or even better, have an intelligent editor provide hyperlinks to definitions.

My personal opinion is that rather than trying to make programming more like math, we should make math more like programming - such that we stop assuming the reader has some magical knowledge needed to understand it.

Re: Toward a better programming

#72

Post by taliesinb »

bsilvereagle wrote: post #36
SlyShy wrote: 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.

With debugging, we'll get there. I have some prototypes, but it's a long way from a research prototype to production, and we're still quite busy on getting actual products out the door.

And even at the moment, the fact that so much of a typical program in the Wolfram Language is referentially transparent means its easy to pick something up out of your codebase and mess around with it, then put it back. That's a huge win over procedural languages.

But in terms of the language, many of the ideas Chris is talking about are already possible (and common) in the Wolfram Language:

It's functional and symbolic, so programs are all about applying transformations to data. In fact, the entire language is 'data', with the interesting side effect that some 'data' evaluates and rewrites itself (e.g. If).

The mathematical sum notation is unsurprisingly straightforward in WL.

And StandardForm downvalues allow for arbitrary visual display of objects in the frontend.

For example, the card would have a symbolic representation like PlayingCard["Spade", 1], but you could write

  StandardForm[PlayCard[suit_, n_]] := ImageCompose[$cardImages[suit], $cardNumbers[n]];
to actually render the card whenever it shows up in the FrontEnd.

Graphics display as graphics, Datasets display as browseable hierarchical representations of their contents along with schema, etc...

Re: Toward a better programming

#73

Post by ilaksh »

I have been saying stuff like this for years, although not as eloquently or detailed. But now Chris Granger is saying it, and no one can say he's not a "real" programmer, so you have to listen.

I think it boils down to a cultural failure, like the article mentions at the end. For example, I am a programmer myself. Which means that I generate and work with lots of static, cryptic colorful ASCII text program sources. If I stop doing that, I'm not a programmer anymore. By definition. I really think that is the definition of programming, and that is the big issue.

I wonder if the current version of Aurora derives any inspiration from "intentional programming"?

Also wonder when we can see a demo of the new version.

Re: Toward a better programming

#74

Post by Detrus »

JoelOtter wrote: post #50

Forgive me if my understanding is totally out of whack, but it seems here that the writer is calling for an additional layer of abstraction in programming - type systems being an example. While in some cases that would be great, I'm not entirely sure more abstraction is what I want. Having a decent understanding of the different layers involved, from logic gates right up to high-level languages, has helped me tremend…

I think this improved programming vision starts at a higher level language like Clojure/JS/Haskell and builds on that.

To allow the everyday Joe to use simplified programming all the way down to machine code is a harder task. Languages like Haskell try to do it with an advanced compiler that can make enough sense of the high level language to generate efficient machine code.

Of course you'll still lose performance on some things compared to manual assembler but with larger programs advanced compilers often beat writing C/manual assembly.

Honestly the bigger performance problem is not wether you can make a high level language that generates perfect machine code but wether you can get through the politics/economics of JS/Obj-C/Java to distribute it.

Re: Toward a better programming

#75

Post by gbhn »

ibdknox wrote: post #31
RogerL wrote: post #26

Earlier quoted context omitted.

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 representatio…

I enjoyed watching the demo and reading the post. I hope you continue to think about this and innovate.

Something that I feel like is missing is the abstraction quality of programming. That is, the idea that I typically have very little use for a particular graphic when writing a program. I'm trying to express "whenever the user hits this button, flip over the top card in this set, move it over here, and then make the next card the top card" or whatever.

Some of Bret's demos look to me like he's thinking directly about this, and trying to discover where the abstraction fits in, and how direct manipulation can help to basically "see" that the abstraction is working. Perhaps that's a good guide to where direct manipulation could really help -- for anything relative complex, it's a big pain to see that code works. A direct manipulation system to basically flip through possibilities, especially into edge cases, and make sure they work as intended would definitely help out. I don't know whether that's the final way you want to express the system -- language is really powerful, even a million years later! -- but a way to see what the language does would be really awesome.

Re: Toward a better programming

#76

Post by krapp »

jamii wrote: post #61
krapp wrote: post #48

Earlier quoted context omitted.

Text as code, for instance, is just an extension of a concept which has been around in one form or another since the scribes of ancient Babylon, or thereabouts. I can imagine more complex ways of representing code but I can't really imagine anything more efficient for translating human concepts into machine language. Except maybe direct, augmented telepathy, but even then people would probably think to the computer i…

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…

Fair enough.

Re: Toward a better programming

#77

Post by seanmcdirmid »

analyst74 wrote: post #12

I am optimistic about our field. Things have not stayed stale for the past 20~30 years, in fact, state of programming have not stayed stale even in the recent 10 years. We've been progressively solving problems we face, inventing tools, languages, frameworks to make our lives easier. Which further allows us to solve more complicated problems, or similar problems faster. Problems we face now, like concurrency, big dat…

I'm optimistic about our field and hope the machine/deep learning crowd don't crack AI so quickly (allowing computers to program themselves obviously puts us out of business).

Re: Toward a better programming

#78

Post by seanmcdirmid »

jamii wrote: post #61
krapp wrote: post #48

Earlier quoted context omitted.

Text as code, for instance, is just an extension of a concept which has been around in one form or another since the scribes of ancient Babylon, or thereabouts. I can imagine more complex ways of representing code but I can't really imagine anything more efficient for translating human concepts into machine language. Except maybe direct, augmented telepathy, but even then people would probably think to the computer i…

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.

Re: Toward a better programming

#79

Post by sanderjd »

Detrus wrote: post #69
sanderjd wrote: post #30

Earlier quoted context omitted.

Yeah it's interesting, every time I hear "software has been stagnant for decades!", I think to myself that my god, it's hard enough to keep up with the stagnant state of things, I can't imagine trying to keep up with actual progress!

Keeping up with actual progress should be easier. The current "stagnant" state could be called that because your attention is wasted on miracle cures that promise the moon, but mostly deliver a minor improvement or make things worse.

I don't see a bunch of miracle cures that promise the moon, I see a bunch of things that promise, and sometimes deliver, hard-won incremental improvement. The OP seems a lot more like a moon-promising miracle-cure than all the stagnant stuff I'm wasting my attention on.

Re: Toward a better programming

#80

Post by clavalle »

I'm intrigued.

This is a problem that many, many very smart people have spent careers on. Putting out a teaser post is brave and I have to believe you know what you are doing.

I am looking forward to the first taste. Do you have an ETA ?

Post reply on HN