Declaration syntax

[H. S. Teoh]

On Wed, Jan 08, 2014 at 05:19:59PM +0000, Boyd wrote:
> On Wednesday, 8 January 2014 at 16:31:06 UTC, H. S. Teoh wrote:
> >On Wed, Jan 08, 2014 at 08:47:21AM +0000, Boyd wrote:
> >[...]
> >>I've been experimenting with language design a bit and I found that
> >>a much bigger issue with coding, is that we still use files and
> >>plain text. An IDE where code is represented in a simple tree and
> >>saved in a database, for example, would improve things dramatically,
> >>and no language changes would be necessary.
> >
> >I disagree with that direction. The advantage of a text format is
> >that it can represent *anything* (suitably serialized, of course),
> >and that when things go wrong with your tools (IDE corrupts the file,
> >or doesn't support certain operations, or, for that matter, you're
> >working in an environment where no IDE is available and all you have
> >is a bare-bones text editor), you have a way of reaching into the
> >data and fixing it yourself. Having a custom binary representation of
> >the code makes it impossible to manipulate outside of the IDE, which
> >makes data recovery very time-consuming or impossible.
> >
> >That's not to say that plain text is the best representation for
> >code, of course. But I have yet to find an alternative that doesn't
> >suck, and that offers advantages that plain text can't offer. This
> >isn't the first time this idea came up. I've heard of many attempts
> >to replace text representation for code, and all of them sucked. If
> >you think you have a superior representation, please convince me
> >otherwise.
> >
> >
> >T
> -------------
> I'm not suggesting getting rid of all plain text, but I'm
> definitely for replacing most of the text we need to define
> structural information.
> 
> Furthermore, a custom binary implementation wouldn't be a problem
> as long as there is a well defined exchange format that all IDE's
> would share. This could simply be the code files we use now.

I suppose it depends on the way you're used to working. Me, I don't even
use GUI's (well, my "GUI" is so bare bones that my manager doesn't even
understand how I can even begin to use it), much less IDE's, and I
generally prefer formats that can be processed by generic tools that
aren't necessarily catered for manipulating code.


> I agree that current alternatives are less than stellar. I think
> that's mostly because any attempts either go too far (visual
> programming), or not nearly far enough (just listing the
> available objects).

No, I think the issue is that nobody has truly tackled the real problem
yet. Visual programming is just a misguided attempt at modelling
computation with physical metaphors, which don't work because they
utterly fall flat in capturing the sheer, immense complexity of
computation. Most people don't even understand rudimentary complexity /
computational theory (and through no fault of theirs: the nature of the
subject is extremely complex, no pun intended), much less have any sort
of useful visualization of it that is generically applicable.  Listing
available objects to me is like printing a catalogue of telescopes when
the task at hand is to study astronomy. Until we shift our attention
from the toys of syntax and representation to truly capture the nature
of computation, the current state of things will continue to hold.


> Unfortunately I don't have anything concrete. Only ideas, that I
> will eventually try to work out, when I have the time. (Don't
> hold your breath)
> 
> I do wish that programmers would be more open to such ideas.
> There is too much pointless bickering about miniscule syntactic
> changes, yet no one seems to be interested in fixing the archaic
> use of plain text files.

https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality

:-)

We like to bicker about syntax because everybody understands it and has
direct experience of it. Semantics -- we know we need it, and we've
dabbled in it some, but nobody really understands it in its entirety, so
as long as it's Turing-complete (whatever *that* means... :P), that's
good enough for us. Leave us the time to argue over syntax and how to
make the "right" coffee.

On a more serious note, though, I classify the use of plain text files
vs. whatever alternative representation format to be equally trivial as
bikeshedding over syntax.  The important issues at hand are the
*semantics* of programming -- how to capture the sheer complexity of
computation in a way that can make extremely complex computations
tractable to our limited mental capacity.  The history of the progress
of programming is keyed on exactly this issue.

>From the days of fiddling directly with binary bits to the first
rudimentary assembler, progress was made by being able to express, for
example, addition, without needing to specify how exactly the bits are
to be flipped. Then from assembly language to the first
human-comprehensible languages, progress was made by being able to
express a computation as a mathematical expression (more or less),
without needing to specify exactly how each machine register is to be
assigned to various intermediate quantities in order to produce the
desired result. Then from the first (rather low-level) languages to
(slightly) higher-level languages like C, progress was made by being
able to encapsulate complex computations in functional units that can be
reused without needing to rewrite a custom adaptation thereof for every
occasion the same (or similar) computation is needed. At every stage,
progress was made by building more powerful and far-reaching
abstractions that can span greater scopes of computation.

Whether said abstractions are represented by one syntax or another, in
one medium (plain text) or another (binary), is ultimately mere clerical
work. Whether you represent the number 8 as the glyph "8", as the word
"eight", or as the Roman numeral VIII, doesn't matter as far as the
ability to express that mathematical quantity is concerned. It's rather
telling that today's mathematics, which has developed far beyond
anyone's ability to fully comprehend in its entirety and scope, is still
represented as mere symbols on paper (or some equivalent digital
medium). There's a lot to be said about symbolic representations of
abstract concepts: so far, no one has found any superior method of
representing and manipulating abstract concepts. The crux of the issue
is how to define a symbol -> semantics mapping that is maximally
expressive and amenable to easy use. How these symbols are to be
represented and stored, that's mere clerical work. Necessary, but by no
means an issue more important than syntax.


T

-- 
Political correctness: socially-sanctioned hypocrisy.