On Wed, Jan 16, 2013 at 12:57:43AM +0100, Rob T wrote: [...]
> The sad part is that after all these decades, we're still _writing_ code, and we're doing it in essentially the exact same way as was done 30 years ago using a text editor.
> 
> For whatever reason, no other means of constructing software programs has really taken off, and I have to wonder why.
[...]

I think it's because people have vastly underestimated (1) the complexity of programming -- it is non-trivial to reduce it to a simple, tractable paradigm, and (2) the expressive power of language -- that is, a linear medium of concept representation.

It's paradoxical that a 1D (i.e. linear) representation is more useful for capturing the complexity of programming as opposed to, say, a 2D graphical representation, say, or even a 3D representation. But perhaps it's not so paradoxical if one considers that a linear representation is sufficient to capture all of programming, and processing a 2D or 3D representation adds no expressive power yet introduces more expensive processing on the part of the compiler/language processor.

Or maybe it's just because humans are just linear-thinking creatures. :)


T

-- 
Verbing weirds language. -- Calvin (& Hobbes)

On Wed, Jan 16, 2013 at 02:06:59AM +0100, Era Scarecrow wrote:
> On Tuesday, 15 January 2013 at 22:35:04 UTC, Jonathan M Davis wrote:
> >I've had _one_ coworker that I know of who liked using. I still don't understand how he could read code that way. Proportional fonts make perfect sense for normal text, but they're horrible for code. Nothing lines up right. That's why I hate writing code in e-mails. Not only is it hard to get right with a proportional font, you don't even know if it's going to look the same for the person reading it.
> 
>  I remember being taught Java and helping everyone else debug their
> code. One girl had changed her fonts to this really fancy cursive
> font with purple & pink color. Why, I have no clue. Being too hard
> to read I refused to help her.

Maybe I should invent a programming language in which color has semantic value. And fonts. :-P

In fact, that might be a solution to the creeping modifierism that modern functions seem to have contracted: first it's just return type, function name, arguments, then there's const, then pure, then @safe, then nothrow, and all that jazz. If we could map @safe->green, pure->blue, and nothrow->red (or lack thereof), then a pure nothrow fuction would be blue, a pure throwing function magenta, a @safe pure function cyan, and a @safe, pure, throwing function would be white.

Then const can rendered in italics, non-const in upright, immutable in Fraktur, ref in serif. This way, we can get rid of all those annoying verbose modifiers and return to the pure joy of return type, function name, and arguments. Fixing const issues in Phobos would be as simple as selecting the entire source code and changing the font to italics. :-P


T

-- 
The easy way is the wrong way, and the hard way is the stupid way. Pick one.

On Wednesday, 16 January 2013 at 01:31:20 UTC, H. S. Teoh wrote:
> Or maybe it's just because humans are just linear-thinking creatures. :)

I was just a while ago thinking that a reason why text based programming has been so predominant may be that the ability to transmit and discuss programming problems are much easier to do when the program is represented in written form.

The minute you move to what could be a much more efficient and effective method of programing, you suddenly lose the ability to easily transmit the source code to other people. For example, it is very easy to post code samples in this forum for discussion, but if we represented programs in graphical form, we would have to upload images instead which not quite as easy to do.

Another issue at hand, is when collaborating over the wire with Git and other revision control systems, none of them operate effectively when using encoding methods that are not text based. Revision control systems just don't work well with binary files.

Having said this, there may still be better ways of representing programs that do not lose the advantages of text based programming, but what those methods look like is not so obvious.

--rt

On 01/15/2013 09:57 PM, Stewart Gordon wrote:
> On 15/01/2013 01:11, Timon Gehr wrote:
> <snip>
>> I assume you are using thunderbird, because that changed its layout
>> fairly recently. You can fix this by right-clicking on the button ->
>> 'Customize...' IIRC.
>
> But for some strange reason, getting rid of the Reply button gets rid of
> it when viewing email as well. :(
>
> Stewart.
>

That is indeed strange. I managed to get it work just right.

On 01/15/2013 11:59 AM, Artur Skawina wrote:
> ...
>
> Except if you'd like to have 'printf("%.2g", d)' instead of 'printf!"%.2g"(d)'
> syntax.

printf(q!"%.2g", d) works too.

On Wed, Jan 16, 2013 at 03:54:17AM +0100, Rob T wrote: [...]
> I was just a while ago thinking that a reason why text based programming has been so predominant may be that the ability to transmit and discuss programming problems are much easier to do when the program is represented in written form.
> 
> The minute you move to what could be a much more efficient and effective method of programing, you suddenly lose the ability to easily transmit the source code to other people. For example, it is very easy to post code samples in this forum for discussion, but if we represented programs in graphical form, we would have to upload images instead which not quite as easy to do.

I invented a 4-dimensional esolang once, that represented program code as tiles in an N*N*N*N tesseract. It was ultimately represented in text, but you couldn't effectively program directly in a text editor because it was a pain to keep things aligned properly, and non-trivial programs wouldn't fit on your screen. For coding, I wrote a 4D tile editor.  :-P

Extreme example, granted. But you could include snippets of code in, say, email, and the recipient could paste it into the 4D editor for viewing, editing, etc..


> Another issue at hand, is when collaborating over the wire with Git and other revision control systems, none of them operate effectively when using encoding methods that are not text based. Revision control systems just don't work well with binary files.

That's not quite true, you know. Binary diffing has been around for a long time now. But I suppose you could say that there is currently no effective, generic way to display binary diffs in an understandable way. But then, I believe git has diff plugins that one could write custom diff displayers for, so this is merely a small impediment, not a fundamental one.


> Having said this, there may still be better ways of representing programs that do not lose the advantages of text based programming, but what those methods look like is not so obvious.
[...]

Whatever structures said methods may use, can ultimately be reduced to some kind of linear representation, which in turn can be reduced to some text representation. I mean, no matter what you do, it will ultimately have to be stored as a sequence of binary bytes. And programmers like getting to the bottom of things, so directly manipulating a text representation is the most obvious approach.

Now, granted, just because something can be represented as text doesn't mean a text editor is the best tool for manipulating it (XML comes to mind ;-)). One could imagine programming by visually manipulating graphs, for example. Or take music composition as a kind of analogous process: while you can certainly use a text editor to edit, say, a Lilypond file and spell out notes and stuff directly, most people would prefer a graphical interface where you can manipulate the musical notation directly instead. Trying to write highly-polyphonic music interspersed with chords in plain text format is possible, but extremely painful and tedious, whereas writing it out in musical notation is almost trivially straightforward. I've no idea what the programming analogue of musical notation would be, though.  (Please don't say APL. ;-P)


T

-- 
Ignorance is bliss... but only until you suffer the consequences!

On Wednesday, 16 January 2013 at 06:05:41 UTC, H. S. Teoh wrote:
>
> That's not quite true, you know. Binary diffing has been around for a
> long time now. But I suppose you could say that there is currently no
> effective, generic way to display binary diffs in an understandable way.
> But then, I believe git has diff plugins that one could write custom
> diff displayers for, so this is merely a small impediment, not a
> fundamental one.
>

Better than using binary files would be to store the state of the system using text (json, xml, whatever). For correct visual representation as intended by the programmer, the state of the visual representation is loaded up when the graphical editor is launched.

A nice thing about a graphical representation of code, is that the execution can be animated for much better feedback and debugging abilities.

> Whatever structures said methods may use, can ultimately be reduced to
> some kind of linear representation, which in turn can be reduced to some
> text representation. I mean, no matter what you do, it will ultimately
> have to be stored as a sequence of binary bytes. And programmers like
> getting to the bottom of things, so directly manipulating a text
> representation is the most obvious approach.

True.

This is interesting, and it maps to text based source code.

SAM - An Animated 3D Programming Language (PDF)
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1.7976&rep=rep1&type=pdf

[...]
> Lilypond file and spell out notes and stuff directly, most people would
> prefer a graphical interface where you can manipulate the musical
> notation directly instead. Trying to write highly-polyphonic music
> interspersed with chords in plain text format is possible, but extremely
> painful and tedious, whereas writing it out in musical notation is
> almost trivially straightforward. I've no idea what the programming
> analogue of musical notation would be, though.  (Please don't say APL.

Not exactly music, and not a general purpose 3D programming language but this is somewhat interesting (and annoying!)
http://www.youtube.com/watch?v=Tq0hbfvNKWQ

On 16/01/2013 01:39, H. S. Teoh wrote:
<snip>
> Maybe I should invent a programming language in which color has semantic
> value. And fonts. :-P
<snip>

There are languages where source takes the form of an image, a musical score or some other kind of binary file.
http://esolangs.org/wiki/Category:Non-textual

But I haven't seen one before where it's a word-processor document. What document format(s) do you plan to support?  (I guess this would be defined at the language level, just like D files being in Unicode is at the moment.)

Stewart.

H. S. Teoh wrote:
> Maybe I should invent a programming language in which color has semantic
> value. And fonts. :-P

ColorForth by Chuck Moore ....

http://www.colorforth.com/cf.htm

Peter

On Wed, 2013-01-16 at 00:57 +0100, Rob T wrote:
[…]
> The sad part is that after all these decades, we're still _writing_ code, and we're doing it in essentially the exact same way as was done 30 years ago using a text editor.

In the early to mid 1980s there was a move to not using text files but using AST with meta-data as the stored form of code. Not just the syntax oriented editing people but people doing for C, Fortran, etc. what Smalltalk did for Smalltalk, treat the text form of the code as a rendering of the stored form.

Sadly two things stopped this from becoming the norm: a. hardware wasn't up to the job required (whereas now it is the other way round); b. programmers refused to give up files containing text as the stored form.

Now look at people not still using Emacs and VIM: IDEs everywhere. What do IDEs spend most of their time doing? Reconstructing ASTs on the fly in order to provide all the help and code completion programmers now claim is their inalienable right.

> For whatever reason, no other means of constructing software programs has really taken off, and I have to wonder why.

It would have done if programmers had been less conservative and more willing to be open to change. But no, text files had to be the right medium of storage. Bah.

In the next round of funding in Europe, there are various project proposals to revisit the whole 1980s way of thinking about code development and code development environments. Replace text file as the stored form with a representation of the AST with meta-data. Allow IDEs like Eclipse, IntelliJ IDEA, NetBeans not to have to infer ASTs in parallel to compiling code. Reclaim some memory and machine cycles by getting IDEs right.

(Emacs|VIM|GEdit|Sublime Text|.*) your days really ought to be numbered. We the programmers demand development tools that are modern and up to date. Eclipse, IntelliJ IDEA, NetBeans are legacy as well.

There is an analogy: actor model, CSP, dataflow were all invented in the 1960s and 1970s but studiously ignored by programmers in favour of "close to the metal" shared-memory multi-threading because parallelism was about performance and you have to wring every cycle.  Bah. Mere infrastructure. Now any programmer who isn't using dataflow, CSP or actors for concurrency and parallelism is legacy. Look at D ;-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder