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

131–140 of 191 posts

Re: Toward a better programming

#131

Post by pjmlp »

doktrin wrote: post #99
pjmlp wrote: post #91

Earlier quoted context omitted.

The main problem is that Bell Labs had more success making their research mainstream than Xerox PARC did. So here we are in 2014, with all that nice GUI live development environments (Interlisp, Smalltalk, Mesa/Cedar) lost to people that prefer a UNIX System V clone.

That doesn't sound convincing. The Xerox PARC GUI is everywhere . The results of their work are about as mainstream as they could possibly be. Likewise, Smalltalk and Mesa were both hugely influential in everything from C, C++, Java and beyond. Given that, it seems more likely that graphical development hasn't taken off because it isn't good enough yet. All developers have prejudices, but they typically have to yield…

> The Xerox PARC GUI is everywhere

Quoting Alan Kay

Now, the abortion that happened after PARC was the misunderstanding of the user interface that we did for children, which was the overlapping window interface which we made as naive as absolutely we possibly could to the point of not having any workflow ideas in it, and that was taken over uncritically out into the outside world.

> Given that, it seems more likely that graphical development hasn't taken off because it isn't good enough yet. All developers have prejudices, but they typically have to yield to superior methodologies.

The only existing mainstream environment that can replicate some of the live coding experience of the said systems is Mathematica.

That is why for old guys like myself it is so interesting to see all the live coding discussions that happen on HN, from people that never used those systems or at least saw them being used.

Re: Toward a better programming

#132

Post by Too »

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…

The card example is a bit contrived. Imagine instead being able to to write linearizationtable = [insert interactive graph here]. Instead of linearizationtable[20][2] = {{0,5}, {4, 20}, .... }

And even if you have a graph it can still be stored in text format for version control reasons.

Re: Toward a better programming

#133

Post by pjmlp »

k__ wrote: post #112
jowiar wrote: post #65

Earlier quoted context omitted.

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.

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

UNIX spread into the enterprise world.

Re: Toward a better programming

#134

Post by Too »

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…

The mathematical notation also lacks a lot of type information. Looking at his example formula, First of all, both x and N are magic variable names, where did they come from? Second, what happens if x is a string and + is considered string concatenation. Mathematical notation has all the problems of duck typing and even more. In a way that's also the beauty of math, you can multiply matrices with same rules you learned scalar multiplication in 2nd grade. For quick problems where you can keep all variables in your head this is nice to save on typing, but for larger applications you need clearly defined interfaces and a way to encode them.

Re: Toward a better programming

#135

Post by flyrain »

misuba wrote: post #83
jimmaswell wrote: post #63

Earlier quoted context omitted.

>The main source of the pain is, to me, is that we're still working strictly with textual representations of non-textual concepts and logic, no matter how those concepts might better be rendered. I can't see any issue with representing logic abstractly with symbols. It's the same for calculus. Of course the ideas we're representing aren't actually the things we use to represent them, the same as written communication…

> I can't see any issue with representing logic abstractly with symbols. That's the problem: text isn't abstract enough. So we put some of the text into little blobs that have names (other methods), and use those names instead, and we call that "abstraction," but black-box abstraction doesn't help us see. The symbols in calculus, by contrast, are symbols that help you see. The OA is calling for abstractions over oper…

Agree. There is must be more abstract way to present ideas than text. In this way, programs are easier to understand and modification, and have less errors and bugs.

Re: Toward a better programming

#136

Post by DanielRibeiro »

ibdknox wrote: post #81
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.

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 agree that the problem is not error recovery, but is more generaly described by Peter Naur's "Programming as Theory Building"[1]. With that, programming is hard because creating a theory, collectively, and teaching other people about it, is hard. Making it easier is therefore solving the problem Douglas Engelbart envisioned solving: Augmenting the Human Intellect

[1] http://catenary.wordpress.com/2011/04/19/naurs-programming-a...

Re: Toward a better programming

#137

Post by TeMPOraL »

RogerL wrote: post #115
dllthomas wrote: post #19

Earlier quoted context omitted.

"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)

Something like that (typing from memory):

  (defun do-integrate (tree var)
      ;; -- do some crazy symbolic manipulation on the source tree
  )

  (defmacro integral (expr var)
     ,(do-integrate expr ,var))

Re: Toward a better programming

#138

Post by mercurial »

pjmlp wrote: post #131
doktrin wrote: post #99

Earlier quoted context omitted.

That doesn't sound convincing. The Xerox PARC GUI is everywhere . The results of their work are about as mainstream as they could possibly be. Likewise, Smalltalk and Mesa were both hugely influential in everything from C, C++, Java and beyond. Given that, it seems more likely that graphical development hasn't taken off because it isn't good enough yet. All developers have prejudices, but they typically have to yield…

> The Xerox PARC GUI is everywhere Quoting Alan Kay Now, the abortion that happened after PARC was the misunderstanding of the user interface that we did for children, which was the overlapping window interface which we made as naive as absolutely we possibly could to the point of not having any workflow ideas in it, and that was taken over uncritically out into the outside world. > Given that, it seems more likely t…

> Now, the abortion that happened after PARC was the misunderstanding of the user interface that we did for children, which was the overlapping window interface which we made as naive as absolutely we possibly could to the point of not having any workflow ideas in it, and that was taken over uncritically out into the outside world.

And then tiling window managers were invented, and users rejoiced.

Re: Toward a better programming

#139

Post by mercurial »

vorg wrote: post #125
ibdknox wrote: post #31

Earlier quoted context omitted.

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

Just use Unicode, and a programming language that uses the full power of Unicode symbology in its syntax. E.g. ♠♣♥♦ × A23456789TJQK

Please don't. People are already terrible at naming things, I for one am not going to try the entire Unicode table to find out which symbol you chose for "MetadataService". Plain text is fine, it's searchable, readable, and somewhat portable (minus the line ending debacle).

If you need something more, vim has the "conceal" feature which can be used to replace (on the lines the cursor is not on) a given text with another (eg show ⟹ instead of =>). Would you be better off if there was an option to do this for variable/class/method names? I'm not sure.

Re: Toward a better programming

#140

Post by deckiedan »

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…

What I was meaning was 'very different from was done 20/30 years ago, but is actually practical, as powerful as languages from 20/30 years ago, and not just a tech demo...'.

Yes, IDEs help a lot with some of those tasks. But we're really still improving programming in a very evolutionary way - which isn't bad. For sure c# is more powerful and interesting than 1990 era c++. But ultimately, it's not that different, really.

To me, that's the interesting thing about lightroom, and all that stuff. We're able to explore some of the concepts of programming from the old smalltalk systems in a modern way. And maybe, we'll find ways of programming which do actually look different from the old ways. Maybe not.

Visualising functions as things which we can glue together, transform, pass data through, etc. I'm very interested to see where it all goes.

Post reply on HN