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

The Future of Programming (2013)

worrydream.com

Post reply on HN
Print view View original

51–60 of 67 posts

Re: The Future of Programming (2013)

#51

Post by acuozzo »

zvrba wrote: post #22
fhood wrote: post #18

Earlier quoted context omitted.

This was one of my professors favorite gripes. He loved to tell stories about how companies would reinvent algorithms (usually multiple times) that had been published in the 70's and 80's

The problem here is search. The problem may have been solved, but finding the relevant paper is like looking for a needle in the haystack. It doesn't help that terminology has changed during the years...

> The problem here is search.

And training.

I've had to reinvent algorithms I know already exist for my hobby work because they were invented to solve another unrelated problem I'm not familiar with and phrased using domain language I don't know.

Re: The Future of Programming (2013)

#52

Post by muxator »

shalabhc wrote: post #23
kareemamin wrote: post #19

Earlier quoted context omitted.

Yeah it's definitely crazy! A few people are working on this from different angles. There is research https://harc.ycr.org/project/realtalk/ , side projects that explore Jupyter notebook like programming environments: https://www.maria.cloud/intro , or https://www.runkit.com ; my team and I are working on https://www.clay.run : making it easier to prototype by allowing developers to write code that is instantly runni…

Maria, clay and runkit look interesting - I like the quick iterations and incremental programming they allow. But you're still writing 'text' to manipulate 'data'. An example of something fundamentally different would be if you can make programs without text. I intentionally said make not write to avoid framing the discussion. For instance why write `(circle 10)` when you can instead just draw a circle and then perha…

Maybe I am old school, but the fact that text is easily version able and comparable means a lot to me. I use to code with two side-by-side windows, comparing the old and the new version of my program.

It's a sort of fluid evolution where I can always be in control.

It would be a hard time doing that via visual programming.

Re: The Future of Programming (2013)

#53

Post by kareemamin »

muxator wrote: post #52
shalabhc wrote: post #23

Earlier quoted context omitted.

Maria, clay and runkit look interesting - I like the quick iterations and incremental programming they allow. But you're still writing 'text' to manipulate 'data'. An example of something fundamentally different would be if you can make programs without text. I intentionally said make not write to avoid framing the discussion. For instance why write `(circle 10)` when you can instead just draw a circle and then perha…

Maybe I am old school, but the fact that text is easily version able and comparable means a lot to me. I use to code with two side-by-side windows, comparing the old and the new version of my program. It's a sort of fluid evolution where I can always be in control. It would be a hard time doing that via visual programming.

I think you are right. It's much easier to compare old and new versions of a program if they are text. But we also should remember that we developed tools like diff to work with programming in text. If instead we were using a different paradigm we could explore the equivalent of diff in that model. Merge conflicts in text are often not real logic conflicts but just re-ordering things in a text file, or formatting changes. If we used a projectional editor, one that treats code as an AST instead of just flat text like lamdu - https://github.com/lamdu/lamdu we would need to create a new way to look at the evolution of changes in the code but it could be more meaningful than just looking at text.

Also you could have a timeline that shows you what got changed instead of comparing two text files. There can be lots of ways to achieve the same goal, understanding what changed and how, than just diffing two text files.

Re: The Future of Programming (2013)

#54

Post by dragandj »

shalabhc wrote: post #23
kareemamin wrote: post #19

Earlier quoted context omitted.

Yeah it's definitely crazy! A few people are working on this from different angles. There is research https://harc.ycr.org/project/realtalk/ , side projects that explore Jupyter notebook like programming environments: https://www.maria.cloud/intro , or https://www.runkit.com ; my team and I are working on https://www.clay.run : making it easier to prototype by allowing developers to write code that is instantly runni…

Maria, clay and runkit look interesting - I like the quick iterations and incremental programming they allow. But you're still writing 'text' to manipulate 'data'. An example of something fundamentally different would be if you can make programs without text. I intentionally said make not write to avoid framing the discussion. For instance why write `(circle 10)` when you can instead just draw a circle and then perha…

It is probably the same reason as why books (text) are still the main medium. Movies may be more popular entertainment, and comics might be preferred by some demographics, but everybody write something, and everybody read something, being it a facebook post, a tweet, a novel or a 10-tome encyclopaedia.

Nobody says that books kinda suck and should be replaced by pictographs on papyri, but somehow many programmers at least have a phase when they think that having to program by drawing shapes could somehow be easier than writing textual code...

Re: The Future of Programming (2013)

#55

Post by shalabhc »

muxator wrote: post #52
shalabhc wrote: post #23

Earlier quoted context omitted.

Maria, clay and runkit look interesting - I like the quick iterations and incremental programming they allow. But you're still writing 'text' to manipulate 'data'. An example of something fundamentally different would be if you can make programs without text. I intentionally said make not write to avoid framing the discussion. For instance why write `(circle 10)` when you can instead just draw a circle and then perha…

Maybe I am old school, but the fact that text is easily version able and comparable means a lot to me. I use to code with two side-by-side windows, comparing the old and the new version of my program. It's a sort of fluid evolution where I can always be in control. It would be a hard time doing that via visual programming.

> text is easily version able and comparable means a lot to me.

Don't you really want to do more meaningful comparisons though? I think text is a poor form for versioning and comparison because you always have to mentally extrapolate the textual diff (lines added/deleted) to the syntactic diff (functions added/deleted/modified) to the diff in effect (which logic in which systems is modified). There is no reason other forms of programs cannot also do diffs, that could be more useful.

Visual does't have to mean flowchart boxes. Even a tree structure might be incrementally better than plain text.

Re: The Future of Programming (2013)

#56

Post by dragonwriter »

shalabhc wrote: post #23
kareemamin wrote: post #19

Earlier quoted context omitted.

Yeah it's definitely crazy! A few people are working on this from different angles. There is research https://harc.ycr.org/project/realtalk/ , side projects that explore Jupyter notebook like programming environments: https://www.maria.cloud/intro , or https://www.runkit.com ; my team and I are working on https://www.clay.run : making it easier to prototype by allowing developers to write code that is instantly runni…

Maria, clay and runkit look interesting - I like the quick iterations and incremental programming they allow. But you're still writing 'text' to manipulate 'data'. An example of something fundamentally different would be if you can make programs without text. I intentionally said make not write to avoid framing the discussion. For instance why write `(circle 10)` when you can instead just draw a circle and then perha…

> why even have text as the canonical form that describes computation processes?

Because before you get to machine code, you’ll want to transform to an expression tree, and text is an excellent accessible way to represent that. The text form might be an IR with various graphical or other non-text (and possibly some text) source languages, though.

Re: The Future of Programming (2013)

#57

Post by clusmore »

Slightly off-topic but does anybody know of other great talks with a quirky theme like this, where the talk is "set" in the 70s talking about the "future" (present)?

I'll kick it off by submitting [Growing a Language] (https://youtu.be/_ahvzDzKdB0) by Guy Steele, where he speaks using only monosyllabic words and words he defines in terms of other monosyllabic (or previously defined) words.

Re: The Future of Programming (2013)

#58

Post by empath75 »

shalabhc wrote: post #23
kareemamin wrote: post #19

Earlier quoted context omitted.

Yeah it's definitely crazy! A few people are working on this from different angles. There is research https://harc.ycr.org/project/realtalk/ , side projects that explore Jupyter notebook like programming environments: https://www.maria.cloud/intro , or https://www.runkit.com ; my team and I are working on https://www.clay.run : making it easier to prototype by allowing developers to write code that is instantly runni…

Maria, clay and runkit look interesting - I like the quick iterations and incremental programming they allow. But you're still writing 'text' to manipulate 'data'. An example of something fundamentally different would be if you can make programs without text. I intentionally said make not write to avoid framing the discussion. For instance why write `(circle 10)` when you can instead just draw a circle and then perha…

https://vcvrack.com

Here’s an example of visual programming. All you’re really doing there is chaining together functions and tuning parameters, but instead of typing, you’re dragging wires around and twiddling knobs.

Re: The Future of Programming (2013)

#59

Post by dragonwriter »

shalabhc wrote: post #55
muxator wrote: post #52

Earlier quoted context omitted.

Maybe I am old school, but the fact that text is easily version able and comparable means a lot to me. I use to code with two side-by-side windows, comparing the old and the new version of my program. It's a sort of fluid evolution where I can always be in control. It would be a hard time doing that via visual programming.

> text is easily version able and comparable means a lot to me. Don't you really want to do more meaningful comparisons though? I think text is a poor form for versioning and comparison because you always have to mentally extrapolate the textual diff (lines added/deleted) to the syntactic diff (functions added/deleted/modified) to the diff in effect (which logic in which systems is modified). There is no reason other…

Syntax-aware diff for text isn't hard, but it's just not usually worth the effort because line-oriented text diff is good enough and more generally applicable.

Re: The Future of Programming (2013)

#60

Post by CyberDildonics »

There is a huge disconnect between these flashy ideas and what you can actually use to create software. Showing cool ideas is great, but there needs to be interfaces that scale to complex software and a realistic way to integrate them with languages that already exist. Brand new languages with no eco system and without mature compilers backing them are not going to allow general software to be written in them.
Post reply on HN