March 17, 2013
On 3/17/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>  it should be handled correctly by dmd.  If not, that is a bug.

It likely wasn't located at the beginning. Anyway the samples now seem to be images.
March 17, 2013
On 03/17/2013 07:09 AM, Paulo Pinto wrote:
> On 17.03.2013 11:01, Russel Winder wrote:
>> On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote:
>> […]
>>> The first known one is that Go is the only strong typed language to
>>> eschew generics in the 21st century.
>>
>> On the other hand, perhaps generics is not a good thing, yet has created
>> an unchallenged mindset? NB I am tainted by C++ templates and generics
>> on the JVM both of which really suck as far as I am concerned – C# has
>> much less of a problem here, and Scala hacks it's way around it. Also I
>> use Python a lot which has only one variable type, reference to object.
>> Heterogeneity is not your enemy.
>>
>> I like the experiment of objects as values with methods added as needed,
>> very Pythonic. Go even makes this static compile time type checked;
>> though I think they miss the underlying irony of this.
>
> I think for static strong type languages you need some kind of
> genericity support like generics, parametric types or similar.
>
> There are many other ways to implement them. Eiffel, Modula-3, Ada
> and many other strong type languages also offer generics.
>
> Interfaces are halfway there, because if you are not allowed to use
> operators as functions, then there is always the need to write
> boilerplate code, even for basic types.
>
> Dynamic type languages don't require this of course, given the way their
> type systems work.
>
>>
>> Far too many "object oriented" languages have forgotten that the
>> computational model is one of sending messages to objects asking them to
>> undertake a behaviour. Statically typed languages constrain objects not
>> to be able to evolve their behaviours.
>
> I might be brain damaged here, because I used OO in Object Pascal, C++,
> Smalltalk, CLOS, Prolog, Java, C#, VB, C++, ML and a few obscure languages.
>
> So I don't see the mainstream enterprise OO way of doing things as the
> only way of how OO is supposed to be.
>
> Sadly most developers in the enterprise world lack this kind of
> understanding and write the type of code that gives bad name to OO.
>
>>
>>> For the rest, copying from my discussion on Lambda the Ultimate about
>>> C++ developers not jumping into Go
>>> (http://lambda-the-ultimate.org/node/4554#comment-71504):
>>>
>>> - exceptions;
>>> - enumerations;
>>> - generic types;
>>> - direct use of OS APIs, without the need of writing wrappers;
>>> - currently only static compilation is available;
>>> - due to static compilation only model, there are issues with 3rd party
>>> code;
>>> - no support for meta-programming;
>>> - rich set of available libraries;
>>> - the PR about go routines and channels, usually forgets to mention that
>>> similar features do exist as libraries for other languages
>>
>> Go is a stripped down C with stronger type checking. memory management
>> and CSP. This actually makes it an important language in the scheme of
>> things, even if I agree with you that in so many way it is a regression
>> into the 1960s.
>
> Here they follow Niklaus Wirth, which I admire, school of though.
>
> When he went out to create Oberon, he decided to remove all language
> features he did not consider essential in a programming language.
>
> Actually all the successors, Oberon-2, Component Pascal and Active
> Oberon were created by his students or collaborators. In 2011 the last
> Oberon language report, Oberon-07, removes even a few more features.
>
> On his talk at HOPL-3 he recognizes that the industry did not follow his
> appreciation for smaller languages.
>
> http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf
>
> Go seems to be heading this way, as Rob Pike already wrote a blog entry
> about the same issue, where he mentions that Go only attracts Ruby and
> Python guys, but not the C++ one he expected to attract.
>
> Although I am a big fan of the Oberon operating systems and languages, I
> think we are no longer in the late 90's, and given the mainstream
> acceptance of many features that used to be only academic, why throw
> them away?
>
> Go's workarounds for lack of generics remind me of the time C++ still
> lacked generics and there were a few pre-processor tools to generate
> generic code. Borland used to ship one in their compilers.
>
> I don't miss those days.
>
>>
>> The major problem for all statically compiled languages is the reliance
>> on hardware integers.
>>
>>> I know you can fake enumerations with typed consts, but it is not the
>>> same thing as real enumerations.
>>
>> On the other hand C and C++ enumerations are just syntactic sugar for
>> the same thing so not real difference. In fact exactly the opposite,
>> they are a delusion. Conversely Java enumerations are a bit heavyweight.
>
> I prefer the enumerations the Pascal away, similar to what Java and .NET
> offer with primitives for generic manipulation of values.
>
>>
>>> My point about direct OS APIs is that while D and Rust follow the
>>> approach used by other languages where you just declare bindings, Go
>>> forces the use of the CGO tool and a C compiler that speaks Go ABI.
>>
>> I guess this is because of the segmented stacks architecture behind the
>> realization of Go.
>>
>>> Their talk about fast compilation is also quite effective with young
>>> developers that did not grew up with Modula-2 and Mac/Turbo Pascal or
>>> using other compiled languages with modules, so they think Go is the
>>> first compiled language to offer that.
>>>
>>> Feel free to destroy. :)
>>
>> Far from it. I think Go is a significant improvement over C, but that in
>> 2013 applications programmers should be using something better. I
>> continue to be surprised by Python people moving to Go. The only
>> "positive" for Go is goroutines. Python's GIL's days are numbered at
>> which point even that issue goes away.
>
> Me too.
>
>>
>> The issue is then how to make D appealing to Python programmers. People
>> need to convince me why I should stop training people to use Python.
>> This will be hard given that C/C++/Python is now the standard model for
>> computational systems.
>>
>
> Actually I think the day PyPy becomes the main Python implementation
> there is hardly the need for Python developers to write C or C++ code.
>
> --
> Paulo

The day I can compile pypy without needing 8Gb of memory is the day I'll consider it.
March 17, 2013
On 3/17/2013 3:06 AM, Russel Winder wrote:
> On the other hand "creeping featurism" can be a bad thing. Isn't the
> mantra "small language, large (properly indexed) library"?

It can be a bad thing, no doubt about it. On the other hand:

When I was in London for the 2010 ACCU (when the volcano stranded me there), I took a chance to tour the Belfast cruiser sitting in the Thames. One interesting aspect of it was the ship's machine shop.

It was full of carefully selected machine tools. It was pretty clear to me that an expert machinist could quickly and accurately make or repair about anything that broke on that ship.

Sure, you can make do with fewer, more general purpose machines. But it'll take you considerably longer, and the result won't be as good. For example, I've used electric drills for years. I was never able to get it to drill a hole perfectly perpendicular. I finally got a drill press, and problem solved. Not only is it far more accurate, it's much faster when you've got a lot of holes to drill.

I prefer to view D as a fully equipped machine shop with the right tools for the right job. Yes, it will take longer to master it than a simpler language. But we're professionals, we program all day. The investment of time to master it is trivial next to the career productivity improvement.

And as for the library, yes that is crucial. A large part of D's feature set is there to enable more powerful libraries, such as the language support for ranges, and the language support for library-defined garbage collection.
March 17, 2013
On 3/17/2013 8:58 AM, Suliman wrote:
> Yesterday I had tried to put it reddit, but I have never used reddit before and
> do not sure that it was added at proper section.
>

reddit.com/r/programming is where it should go.
March 17, 2013
On 3/17/2013 3:01 AM, Russel Winder wrote:
> I guess this is because of the segmented stacks architecture behind the
> realization of Go.

Segmented stacks have a significant performance cost to them, as well as making it hard to interface to other languages. I also think that the shift to 64 bits makes them obsolete anyway.

March 17, 2013
Am 17.03.2013 20:28, schrieb 1100110:
> On 03/17/2013 07:09 AM, Paulo Pinto wrote:
>> On 17.03.2013 11:01, Russel Winder wrote:
>>> On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote:
>>> […]
>>>> The first known one is that Go is the only strong typed language to
>>>> eschew generics in the 21st century.
>>>
>>> On the other hand, perhaps generics is not a good thing, yet has created
>>> an unchallenged mindset? NB I am tainted by C++ templates and generics
>>> on the JVM both of which really suck as far as I am concerned – C# has
>>> much less of a problem here, and Scala hacks it's way around it. Also I
>>> use Python a lot which has only one variable type, reference to object.
>>> Heterogeneity is not your enemy.
>>>
>>> I like the experiment of objects as values with methods added as needed,
>>> very Pythonic. Go even makes this static compile time type checked;
>>> though I think they miss the underlying irony of this.
>>
>> I think for static strong type languages you need some kind of
>> genericity support like generics, parametric types or similar.
>>
>> There are many other ways to implement them. Eiffel, Modula-3, Ada
>> and many other strong type languages also offer generics.
>>
>> Interfaces are halfway there, because if you are not allowed to use
>> operators as functions, then there is always the need to write
>> boilerplate code, even for basic types.
>>
>> Dynamic type languages don't require this of course, given the way their
>> type systems work.
>>
>>>
>>> Far too many "object oriented" languages have forgotten that the
>>> computational model is one of sending messages to objects asking them to
>>> undertake a behaviour. Statically typed languages constrain objects not
>>> to be able to evolve their behaviours.
>>
>> I might be brain damaged here, because I used OO in Object Pascal, C++,
>> Smalltalk, CLOS, Prolog, Java, C#, VB, C++, ML and a few obscure
>> languages.
>>
>> So I don't see the mainstream enterprise OO way of doing things as the
>> only way of how OO is supposed to be.
>>
>> Sadly most developers in the enterprise world lack this kind of
>> understanding and write the type of code that gives bad name to OO.
>>
>>>
>>>> For the rest, copying from my discussion on Lambda the Ultimate about
>>>> C++ developers not jumping into Go
>>>> (http://lambda-the-ultimate.org/node/4554#comment-71504):
>>>>
>>>> - exceptions;
>>>> - enumerations;
>>>> - generic types;
>>>> - direct use of OS APIs, without the need of writing wrappers;
>>>> - currently only static compilation is available;
>>>> - due to static compilation only model, there are issues with 3rd party
>>>> code;
>>>> - no support for meta-programming;
>>>> - rich set of available libraries;
>>>> - the PR about go routines and channels, usually forgets to mention
>>>> that
>>>> similar features do exist as libraries for other languages
>>>
>>> Go is a stripped down C with stronger type checking. memory management
>>> and CSP. This actually makes it an important language in the scheme of
>>> things, even if I agree with you that in so many way it is a regression
>>> into the 1960s.
>>
>> Here they follow Niklaus Wirth, which I admire, school of though.
>>
>> When he went out to create Oberon, he decided to remove all language
>> features he did not consider essential in a programming language.
>>
>> Actually all the successors, Oberon-2, Component Pascal and Active
>> Oberon were created by his students or collaborators. In 2011 the last
>> Oberon language report, Oberon-07, removes even a few more features.
>>
>> On his talk at HOPL-3 he recognizes that the industry did not follow his
>> appreciation for smaller languages.
>>
>> http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf
>>
>> Go seems to be heading this way, as Rob Pike already wrote a blog entry
>> about the same issue, where he mentions that Go only attracts Ruby and
>> Python guys, but not the C++ one he expected to attract.
>>
>> Although I am a big fan of the Oberon operating systems and languages, I
>> think we are no longer in the late 90's, and given the mainstream
>> acceptance of many features that used to be only academic, why throw
>> them away?
>>
>> Go's workarounds for lack of generics remind me of the time C++ still
>> lacked generics and there were a few pre-processor tools to generate
>> generic code. Borland used to ship one in their compilers.
>>
>> I don't miss those days.
>>
>>>
>>> The major problem for all statically compiled languages is the reliance
>>> on hardware integers.
>>>
>>>> I know you can fake enumerations with typed consts, but it is not the
>>>> same thing as real enumerations.
>>>
>>> On the other hand C and C++ enumerations are just syntactic sugar for
>>> the same thing so not real difference. In fact exactly the opposite,
>>> they are a delusion. Conversely Java enumerations are a bit heavyweight.
>>
>> I prefer the enumerations the Pascal away, similar to what Java and .NET
>> offer with primitives for generic manipulation of values.
>>
>>>
>>>> My point about direct OS APIs is that while D and Rust follow the
>>>> approach used by other languages where you just declare bindings, Go
>>>> forces the use of the CGO tool and a C compiler that speaks Go ABI.
>>>
>>> I guess this is because of the segmented stacks architecture behind the
>>> realization of Go.
>>>
>>>> Their talk about fast compilation is also quite effective with young
>>>> developers that did not grew up with Modula-2 and Mac/Turbo Pascal or
>>>> using other compiled languages with modules, so they think Go is the
>>>> first compiled language to offer that.
>>>>
>>>> Feel free to destroy. :)
>>>
>>> Far from it. I think Go is a significant improvement over C, but that in
>>> 2013 applications programmers should be using something better. I
>>> continue to be surprised by Python people moving to Go. The only
>>> "positive" for Go is goroutines. Python's GIL's days are numbered at
>>> which point even that issue goes away.
>>
>> Me too.
>>
>>>
>>> The issue is then how to make D appealing to Python programmers. People
>>> need to convince me why I should stop training people to use Python.
>>> This will be hard given that C/C++/Python is now the standard model for
>>> computational systems.
>>>
>>
>> Actually I think the day PyPy becomes the main Python implementation
>> there is hardly the need for Python developers to write C or C++ code.
>>
>> --
>> Paulo
>
> The day I can compile pypy without needing 8Gb of memory is the day I'll
> consider it.

Uau, that much?!

I tend to use Python only for shell scripting type of tasks, so I wasn't aware that PyPy is so memory hungry.

--
Paulo
March 17, 2013
Am 17.03.2013 21:56, schrieb Walter Bright:
> On 3/17/2013 3:01 AM, Russel Winder wrote:
>> I guess this is because of the segmented stacks architecture behind the
>> realization of Go.
>
> Segmented stacks have a significant performance cost to them, as well as
> making it hard to interface to other languages. I also think that the
> shift to 64 bits makes them obsolete anyway.
>

If I am not mistaken, Rust makes use of them as well.
March 17, 2013
Walter Bright wrote:
[snip]
> I prefer to view D as a fully equipped machine shop with the right tools for the right job. Yes, it will take longer to master it than a simpler language. But we're professionals, we program all day.

Not everyone is. With its "scripting abilities" (fast compilation,
a rich std lib, nice syntax) D is attractive for people which has
used a scripting language + C/C++ before to get their job done and
are frustrated by the limitations of such a combo.

> The investment of  time to master it is trivial next to the career
> productivity improvement.

IMHO the problem here is documentation and integration of the various
aspects of the language. The learning curve is rather steep and takes
(much) more time than is really needed.

Of course, I agree with you on the bottom line to prefer a rich set
of tools over overly simplification.

Peter
March 17, 2013
On 03/17/2013 03:44 PM, Walter Bright wrote:
> On 3/17/2013 3:06 AM, Russel Winder wrote:
>> On the other hand "creeping featurism" can be a bad thing. Isn't the
>> mantra "small language, large (properly indexed) library"?
>
> It can be a bad thing, no doubt about it. On the other hand:
>
> When I was in London for the 2010 ACCU (when the volcano stranded me
> there), I took a chance to tour the Belfast cruiser sitting in the
> Thames. One interesting aspect of it was the ship's machine shop.
>
> It was full of carefully selected machine tools. It was pretty clear to
> me that an expert machinist could quickly and accurately make or repair
> about anything that broke on that ship.
>
> Sure, you can make do with fewer, more general purpose machines. But
> it'll take you considerably longer, and the result won't be as good. For
> example, I've used electric drills for years. I was never able to get it
> to drill a hole perfectly perpendicular. I finally got a drill press,
> and problem solved. Not only is it far more accurate, it's much faster
> when you've got a lot of holes to drill.
>
> I prefer to view D as a fully equipped machine shop with the right tools
> for the right job. Yes, it will take longer to master it than a simpler
> language. But we're professionals, we program all day. The investment of
> time to master it is trivial next to the career productivity improvement.
>
> And as for the library, yes that is crucial. A large part of D's feature
> set is there to enable more powerful libraries, such as the language
> support for ranges, and the language support for library-defined garbage
> collection.

Soo...  You're saying D is like Vim?  =P
March 17, 2013
On Sunday, March 17, 2013 17:14:42 1100110 wrote:
> Soo...  You're saying D is like Vim?  =P

LOL. D's learning curve is nowhere near as steep as that. Almost nothing has a learning curve as steep as vim...

But on some level, the concept is the same. In order for something to be powerful enough to properly equip an experienced user, it usually ends up being more complicated for the newbie to learn. Making it super easy for the newbie to learn will just make it less useful for them in the long run, because the power just won't be there even when they're no longer a newbie. The trick is to make something which is powerful and flexible for the experienced user and yet not too daunting for the newbie. I don't know how well we've succeeded on that front, but I'm sure that more tutorials and better documentation and whatnot would help.

- Jonathan M Davis