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

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis

On Wednesday, 8 January 2014 at 00:23:34 UTC, deed wrote:
> 1. Swap type and name. Like Go, but return type between function name and
>    parameter list.

I find the Go swap to be less clear like "functionname(x,y,z int)", but the swap with ":" is ok.

However, then you might as well create a separate type name space starting with colon so that all types start with ":" and have a single colon mean auto (kinda like Go):

x :int; // int x;
y := 2; // auto y = 2;

I think the basic advantage with the swap is to have the return value after the the function parameter list:

add(x:int,y:int) :int
{}
sub(x:int,y:int) :int
{}

It is also more consistent with subclassing, an instance being a special case of a type.

define :subclass:superclass{} // class subclass : superclass{}

anonclass_instance:superclass{...}(...)

etc.

This is particularly useful in a language like Beta where you can inject code into the middle of the superclass:

define :dbaccess {
   db :=dbopen();
   INNER;
   db.close();
}

define :dbtransaction:dbaccess{
   db.begin();
   INNER;
   db.end();
}

define :updatedb:dbtransaction{
   db.get(...);
   db.put(...);
   db.put(...);
   INNER;
   db.consistencycheck();
}

:updatedb{
   db.put(...morestuff...)
}

> 2. Names come first, all other annotations after. ALWAYS.

Yep, or rather: more specific identifiers come first.

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

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.

"Tobias Pankrath" <tobias@pankrath.net> wrote in message news:ointgouwuqyhuoowhzej@forum.dlang.org...
> On Wednesday, 8 January 2014 at 14:13:16 UTC, dajones wrote:
>>
>> "deed" <none@none.none> wrote in message news:unsbvdjdsxtsqgfdetby@forum.dlang.org...
>>> Modifications:
>>>
>>> 1. Swap type and name. Like Go, but return type between function name
>>> and parameter list.
>>> 2. Names come first, all other annotations after. ALWAYS. Example:
>>>
>>>       private const(int)[] foo(const(int)[] all, int newNum, int sum) {}
>>>
>>>    becomes
>>>
>>>       foo const(int)[](all const(int)[], newNum int, sum int) private {}
>>
>> Why have a function declaration take a different form than an expression?
>>
>> h = sqrt(x*x+y*y)
>> s = sin(theta)
>>
>> There's thousands of years of math behind that, we are taught that form before we ever get near programming a computer.
>>
>> result = do_somthing_with(parameters)
>
> x : Int = 4
> h = sqrt(x * x)
>
> Is 'h' a function or is it 2? Should h change if I change x?

if you showed the line

h = sqrt(x*x)

to 100 people, either programmers or people familiar with algebra, how many do you think would say that 'h' is a variable and how many do you think would say 'h' is a function?

And FWIW the square root of 4*4 is 4 not 2.

> Why have a function declaration take a different form than an expression?
>
> h = sqrt(x*x+y*y)
> s = sin(theta)
>
> There's thousands of years of math behind that, we are taught that form
> before we ever get near programming a computer.
>
> result = do_somthing_with(parameters)


Your example seems to show how the functions are used, not how they are declared. I'm only considering declarations and prototyping. After point 2 they would be declared like this, assuming double as parameter and return type for sqrt and sin:

sqrt double(x double) {}
sin  double(x double) {}
foo  const(int)[] (all const(int)[], newNum int, sum int) {}

And after point 3, the declaration would be:

sqrt(x)               double(double) {}
sin(x)                double(double) {}
foo(all, newNum, sum) const(int)[] (const(int)[], int, int) {}

Currently we have:

double sqrt(double x)
double sin(double x)
const(int)[] foo(const(int)[] all, int newNum, int sum) {}

With 20 of these methods inside a struct or class, heavily annotated, and the code folded to get an overview, one have to search in the middle of all the declarations to identify them. And you need to identify said methods, otherwise the information value is quite limited.

Consider

struct {
    private Data[]
    @property const nothrow bool
    @property Data
    void
}

struct {
    _data
    empty()
    front()
    popFront()
}

I believe the last part provides more overall information by itself than the first. Also, the information in the first part is of limited value alone; we want to know that empty is the method that can be used as a property, returns bool, won't change our struct and doesn't throw more than that the struct contains that annotation or that that annotation happens to be named empty. And if the last part is changed to

struct {
    _veryImportantData
    isDiskFull()
    lastAdded()
    deleteAll()
}

more overall information is provided than

struct {
    private VeryImportantData[]
    @property const nothrow bool
    @property VeryImportantData
    void
}

Therefore it feels natural to compose this as

struct {
    _data VeryImportantData[] private
    isDiskFull() bool() @property const nothrow
    lastChanged() VeryImportantData() @property
    deleteAll() void()
}

rather than

struct {
    private VeryImportantData[] _data
    @property bool isDiskFull() const nothrow
    @property VeryImportantData lastChanged()
    void() deleteAll
}

or instead of

struct {
    pure double  sin(double x)  nothrow
    immutable double  pi
    double  sqrt(double x)  nothrow @safe
    const(int)[]  foo(const(int)[] all, int newNum, int sum)
}

have

struct {
    sqrt(x)  double(double)  nothrow
    pi  immutable double
    sin(x)  double(double)
    foo(all, newNum, sum)  const(int)[] (const(int)[], int, int)
}


Anyway, I'm not trying to push this, I was just curious about the two questions in my initial post.

"deed" <none@none.none> wrote in message news:lludycbhnhjzyypowtci@forum.dlang.org...
>> Why have a function declaration take a different form than an expression?
>>
>> h = sqrt(x*x+y*y)
>> s = sin(theta)
>>
>> There's thousands of years of math behind that, we are taught that form before we ever get near programming a computer.
>>
>> result = do_somthing_with(parameters)
>
>
> Your example seems to show how the functions are used, not how they are declared. I'm only considering declarations and prototyping.

My point was that the form should be the same for declaration and use. It's more consitent / intuative that way.

I can see your point that the names would be more visable at the front of the declaration, but I cant honestly think that it's ever been a problem for me. That's what syntax highlighting and formating is for. Eg...

struct {
     pure double          sin(double x)  nothrow
     immutable double  pi
     double                  sqrt(double x)  nothrow @safe
     const(int)[]            foo(const(int)[] all, int newNum, int sum)
}

is better than...

struct {
     sqrt(x)  double(double)  nothrow
     pi  immutable double
     sin(x)  double(double)
     foo(all, newNum, sum)  const(int)[] (const(int)[], int, int)
}

imo at least,  and if the names are all highlighted in luminous green it's all moot then anyway.

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.

>> x : Int = 4
>> h = sqrt(x * x)
>>
>> Is 'h' a function or is it 2? Should h change if I change x?
>
> if you showed the line
>
> h = sqrt(x*x)
>
> to 100 people, either programmers or people familiar with algebra, how many
> do you think would say that 'h' is a variable and how many do you think
> would say 'h' is a function?
>
> And FWIW the square root of 4*4 is 4 not 2.

Value, all of them. I know any calculus/syntax where it would be different. The only difference I am aware of is whether a change of x propagates to h.

On Wednesday, 8 January 2014 at 20:12:03 UTC, H. S. Teoh wrote:
>> 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.

Well I mostly learned programming using Borland Delphi, so I'm kinda spoiled with GUI goodness.

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

Yeah, the whole software engineering field still seems to be in its infancy.

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

Oh feel free too keep bickering, I'll even join you:) I was just being a bit dramatic, and maybe hoping to find someone with similar ideas.

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

It's not exactly the representation format I'm worried about, but rather the organization of code.

On Wed, Jan 08, 2014 at 09:18:16PM +0000, Boyd wrote:
> On Wednesday, 8 January 2014 at 20:12:03 UTC, H. S. Teoh wrote:
[...]
> >>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.
> 
> Oh feel free too keep bickering, I'll even join you:) I was just being a bit dramatic, and maybe hoping to find someone with similar ideas.

No problem, let's just call the $1 billion D compiler nuclear reactor project a done deal, and get back to the bickering over the syntactic bikeshed. :-)


> >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.
> 
> It's not exactly the representation format I'm worried about, but rather the organization of code.

Well, how *should* code be organized?

So far, the best we've come up with in the industry is to break it up into functions at the low levels, and classes and modules at the mid-level, and libraries and packages at the high-level. I'm not sure this hierarchical arrangement is the best there is, though it seems sufficient for what it does. Unfortunately, I don't have a better solution either.  Nothing on the level of ground-breaking ideas that change the way we think about code, anyway.


T

-- 
Public parking: euphemism for paid parking. -- Flora