October 31, 2014
On Friday, 31 October 2014 at 10:21:47 UTC, ketmar via Digitalmars-d wrote:
> On Fri, 31 Oct 2014 10:06:50 +0000
> via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> p.s. and title that "Z", as "the last language you'll need ever. in all meanings." ;-)

Indeed, for the english speaking world, but as a patriotic scandinavian I'm inclined to think there are three more letters. And I cannot have that, can I?

In Denmark and Norway the alphabet ends with : Z, Æ, Ø, Å…
And in Sweden: Z, Å, Ä, Ö…

So the name of the ultimate language has to be one of:

ZÅÖ
ZÖÅ
ÅZÖ
ÅÖZ
ÖZÅ
or
ÖÅZ

Hm…
October 31, 2014
On Friday, 31 October 2014 at 12:09:29 UTC, Ola Fosheim Grøstad wrote:
> ZÅÖ
> ZÖÅ
> ÅZÖ
> ÅÖZ
> ÖZÅ
> or
> ÖÅZ
>
> Hm…

On second thought I think I should stick to the Norwegian alphabet, but resort to old spelling rules. That will make the name of the ultimate language: "AA", pronounced "Awe":

http://www.youtube.com/watch?v=BX5W8gXcAW4

And, as a bonus it will be listed first in programming language listings, such as Rosetta Code.

OK. That's it. I am from now on working on a new system level programming language called "AA", pronounced "Awe" which should be sorted first in all english listings, and sorted last in all scandinavian listings.

No more patches. I'm speccing!

October 31, 2014
On Fri, 31 Oct 2014 12:09:27 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Friday, 31 October 2014 at 10:21:47 UTC, ketmar via Digitalmars-d wrote:
> > On Fri, 31 Oct 2014 10:06:50 +0000
> > via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > p.s. and title that "Z", as "the last language you'll need ever. in all meanings." ;-)
> 
> Indeed, for the english speaking world, but as a patriotic scandinavian I'm inclined to think there are three more letters. And I cannot have that, can I?
> 
> In Denmark and Norway the alphabet ends with : Z, Æ, Ø, Å… And in Sweden: Z, Å, Ä, Ö…
> 
> So the name of the ultimate language has to be one of:
> 
> ZÅÖ
> ZÖÅ
> ÅZÖ
> ÅÖZ
> ÖZÅ
> or
> ÖÅZ
> 
> Hm…
i bet you can find a nicely looking hieroglyph too. that would be cool for graffiti.


October 31, 2014
On Friday, 31 October 2014 at 12:22:56 UTC, ketmar via Digitalmars-d wrote:
> i bet you can find a nicely looking hieroglyph too. that would be cool for graffiti.

Good point. So the logo would be "Å", it is spelled "AA", pronounced "Awe" and sorted both first and last in listings.

It has to be a very minimalistic language:

http://en.wikipedia.org/wiki/Angstrom
October 31, 2014
On Friday, 31 October 2014 at 12:31:25 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 31 October 2014 at 12:22:56 UTC, ketmar via Digitalmars-d wrote:
>> i bet you can find a nicely looking hieroglyph too. that would be cool for graffiti.
>
> Good point. So the logo would be "Å", it is spelled "AA", pronounced "Awe" and sorted both first and last in listings.
>
> It has to be a very minimalistic language:
>
> http://en.wikipedia.org/wiki/Angstrom

Oh drat, someone is squatting my would-be website…

http://www.aa.org/
October 31, 2014
On Friday, 31 October 2014 at 10:06:51 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 31 October 2014 at 09:58:41 UTC, ketmar via Digitalmars-d wrote:
>> if you have something concrete in mind, write ER or forum post, so we can destroy it. ;-)

> - make uniqe_ptr a language builtin

I would go with this by default for all pointers/references.

Something that I read here:

https://news.ycombinator.com/item?id=7650917

My feeling too.

If you need more owners for a resource, then explicitly ask for.
October 31, 2014
On Friday, 31 October 2014 at 13:16:17 UTC, eles wrote:
> Something that I read here:
>
> https://news.ycombinator.com/item?id=7650917
>
> My feeling too.
>
> If you need more owners for a resource, then explicitly ask for.

Thank you for sharing, a very interesting discussion topic.

I am increasingly thinking that it might be possible to have a system level language where you can do progressive refinement from a garbage collection supported sketch to a hardcore real time app.

Basically have different compilation modes where you start out in executable pseudo-code and gradually turn on more switches which give you performance/ownership etc warnings (integrated in the IDE).

Kinda a like starting out with Python and ending up with C.

D supports this a little bit, but has not been designed for it (I think).
October 31, 2014
On Fri, 31 Oct 2014 12:56:58 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Oh drat, someone is squatting my would-be website… http://www.aa.org/
ah. just wait until they got drunk and buy it in exchange for one more shot.


October 31, 2014
On Friday, 31 October 2014 at 13:42:53 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 31 October 2014 at 13:16:17 UTC, eles wrote:
>> Something that I read here:
>>
>> https://news.ycombinator.com/item?id=7650917
>>
>> My feeling too.
>>
>> If you need more owners for a resource, then explicitly ask for.
>
> Thank you for sharing, a very interesting discussion topic.

Just skimming over this:

http://dlang.org/const-faq.html#const-parameters

it would seem to make sense to make them all const by default, and one would have to specifically mark as mutable those that would be changed. The problems with this are:

    It would be a huge break from past D practice, and practice in C, C++, Java, C#, etc.

-- Actually, this is the sole reason, but the breakage would be far less that the breakage introduced by Rust & co. The two reasons that follow are almost hypocrisy to justify the fear in point 1.


    It would require a new keyword, say mutable.

-- Big deal. C++ has mutable too.

    And worst, it would make declarations inconsistent:

    void foo(int* p)
    {
        int* q;
        ...
    }

    p points to const, and q points to mutable. This kind of inconsistency leads to all sorts of mistakes. It also makes it very hard to write generic code that deals with types.

-- Why not make all pointer declarations as constant by default? Then, you explicitely ask for a mutable reference (hell, you could even limit the number of mutable references that could be asked for, if you want). Just reformulate to say:

"p points to const, and q points to const. This kind of consistency leads to all kind of great code. It also makes it very easy to write generic code that deals with types."
November 01, 2014
On Friday, 31 October 2014 at 21:43:26 UTC, eles wrote:
> it would seem to make sense to make them all const by default, and one would have to specifically mark as mutable those that would be changed.

Yes, I think that would be interesting. I also thought about the possibility of putting all mutable parameters to the left of a dot-operator, but it takes some time getting used to (not sure if I could get used to it):

(arr1,arr2).swap_range(10,20);

arr1.merge(arr2); //merge by copy
(arr1,arr2).merge; // merge by moving

> -- Why not make all pointer declarations as constant by default? Then, you explicitely ask for a mutable reference (hell, you could even limit the number of mutable references that could be asked for, if you want). Just reformulate to say:

I think immutable/const by default is the best option. It is primarily in loops that mutable is needed and since mutables are more likely to cause bugs it would be nice to have some attention drawn to them.