On 11/22/13 1:49 PM, Max Samukha wrote:
> On Wednesday, 6 November 2013 at 19:42:21 UTC, Andrei Alexandrescu wrote:
>
>> Go's team was unable to add generics to the language.
>
> Not adding generics was Go's deliberate decision.

http://golang.org/doc/faq#generics

"We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it."

> For that matter, D got
> its type system all wrong compared to Haskell. So why won't we all move
> there?

Move where?


Andrei

Chris:

> But D goes deeper. D raises fundamental questions about how
> a good program should look like, what is good / practicable.

You could write a blog post/article to explain why you think this, with some examples.

Bye,
bearophile

On Saturday, 23 November 2013 at 00:13:03 UTC, bearophile wrote:
> Chris:
>
>> But D goes deeper. D raises fundamental questions about how
>> a good program should look like, what is good / practicable.
>
> You could write a blog post/article to explain why you think this, with some examples.
>
> Bye,
> bearophile

Sure. One of the reasons is that you have the choice. OO, structs, ranges, functional. This makes me think about how to solve which problem. In Java you get one concept, OO, and that's it. What do you do? Write a class, what ever the task at hand may be.

Am 23.11.2013 15:16, schrieb Chris:
> On Saturday, 23 November 2013 at 00:13:03 UTC, bearophile wrote:
>> Chris:
>>
>>> But D goes deeper. D raises fundamental questions about how
>>> a good program should look like, what is good / practicable.
>>
>> You could write a blog post/article to explain why you think this,
>> with some examples.
>>
>> Bye,
>> bearophile
>
> Sure. One of the reasons is that you have the choice. OO, structs,
> ranges, functional. This makes me think about how to solve which
> problem. In Java you get one concept, OO, and that's it. What do you do?
> Write a class, what ever the task at hand may be.

Well,

structs => Packed Objects (IBM J9, being discussed for Java 9)

ranges => Iterator/Iterable/Streams (Java 8)

functional => Method handles/Lambda (Java 8)

--
Paulo

On Friday, 22 November 2013 at 15:52:31 UTC, Andrei Alexandrescu
wrote:
> Ary Borenszweig <ary@esperanto.org.ar> wrote:
>> On 11/21/13 6:36 PM, Andrei Alexandrescu wrote:
>>> On 11/21/13 1:16 PM, Gary Willoughby wrote:
>>>> On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei Alexandrescu wrote:
>>>>> Fortunately a lot has changed since :o).
>>>> 
>>>> Please, do tell. ;)
>>> 
>>> Not much that people don't know already. We have one solid D project
>>> installed and a couple of heavy-hitting engineers have started using D
>>> for scripts and tools (e.g. replacing Python for a 2x speedup for the
>>> same source code size/complexity).
>> 
>> I would have expected a lot more speedup than just 2x, D being a compiled language.
>
> Amdahl's law.
>
> Andrei

BTW, D needs a multithreading example here:
http://saml.rilspace.org/moar-languagez-gc-content-in-python-d-fpc-c-and-c

On Sunday, 24 November 2013 at 05:45:05 UTC, Paulo Pinto wrote:
> Am 23.11.2013 15:16, schrieb Chris:
>> On Saturday, 23 November 2013 at 00:13:03 UTC, bearophile wrote:
>>> Chris:
>>>
>>>> But D goes deeper. D raises fundamental questions about how
>>>> a good program should look like, what is good / practicable.
>>>
>>> You could write a blog post/article to explain why you think this,
>>> with some examples.
>>>
>>> Bye,
>>> bearophile
>>
>> Sure. One of the reasons is that you have the choice. OO, structs,
>> ranges, functional. This makes me think about how to solve which
>> problem. In Java you get one concept, OO, and that's it. What do you do?
>> Write a class, what ever the task at hand may be.
>
> Well,
>
> structs => Packed Objects (IBM J9, being discussed for Java 9)
>
> ranges => Iterator/Iterable/Streams (Java 8)
>
> functional => Method handles/Lambda (Java 8)
>
> --
> Paulo

That's my point. D had / has it all, while Java is bringing it in bit by bit after years, and people have to re-learn Java with every new update. But maybe that's by design, because there's a huge Java-certificate industry out there.

On 25/11/13 11:10, Chris wrote:
> That's my point. D had / has it all, while Java is bringing it in bit by bit
> after years, and people have to re-learn Java with every new update. But maybe
> that's by design, because there's a huge Java-certificate industry out there.

D obtained it over years, too, and has been much less constrained by the need to support a huge existing user-base ...  I think you are once again letting your distaste for corporate management get the better of you ;-)

On Monday, 25 November 2013 at 10:28:12 UTC, Joseph Rushton Wakeling wrote:
> On 25/11/13 11:10, Chris wrote:
>> That's my point. D had / has it all, while Java is bringing it in bit by bit
>> after years, and people have to re-learn Java with every new update. But maybe
>> that's by design, because there's a huge Java-certificate industry out there.
>
> D obtained it over years, too, and has been much less constrained by the need to support a huge existing user-base

Yes, D could breathe, which only goes to show that commercialization can seriously slow down the introduction of useful features.

> ...  I think you are once again letting your distaste for corporate management get the better of you ;-)

I agree, I wasn't clear about it. Corporate management does not mean that the product is bad. But it means that a bad product gets more attention, hype and finally users than a good product that is not developed within a big corporation. I think it is only logical that as soon as a language becomes a product designed within a corporation, the language's design may suffer from external factors that have nothing to do with language design itself. As you said, you have to support an existing user-base. There are marketing issues, the company offers courses (these have to be re-designed, if the language is being re-designed). There is a whole array of external factors that hamper the development of the language. It has nothing to do with my liking or disliking corporate thinking. It's just a logical consequence.

C# was Microsoft's answer to Java, to undermine Java and gain some market shares, and of course in order to do so, they had to make it (at least a bit) better. But strategic thinking and marketing played a big role, thus the language is naturally affected by it.

I'm sure that both C# and Java designers could tell us how much corporate thinking influences and impedes language design. I'm almost sure that there is some kind of "corporate ideology". I'm saying this as someone who actually liked Java and did a lot of Java programming.

> That's my point. D had / has it all, while Java is bringing it in bit by bit after years, and people have to re-learn Java with every new update. But maybe that's by design, because there's a huge Java-certificate industry out there.

Well, I think the guys at Sun back then thought anonymous inner
class would get them around having to add closures to the
language. Maybe they thought they would get away with that quick
hack and later found out it only results in a lot of boilerplate
code. Then it turned out they have to put them in as every other
JVM language has closures baked in from the beginning...

On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:

> Go is web-oriented, so it seems, and I'm sure it will be marketed as the "one size fits all" solution for web development, multi-core and whatnot. But D goes deeper. D raises fundamental questions about how a good program should look like, what is good / practicable. I know that this approach doesn't sell, but it's the best I've ever come across. D makes you think and re-assess your own code time and again.

I basically I agree with this. But lately, I was asking myself, though, whether me classifying Go as simplistic was wrong. I programmed the canonical Scala trait sample in Go. In that sample from the Scala book there is a trait Rectangular with a upperLeft and bottomRight point. Some class Rectangle extends trait Rectangular. I could get the same accomplished using delegation in Go. The solution in Go is much much simpler and from what I can tell the power is the same. So this made me think.

I guess the solution in Scala is easier to recognize for the reader as the code is more structured using specific language constructs. Therefore someone reading the code would easier see the structure in the code and understand the solution. Nevertheless, with a simple construct like delegation with some compromises in visibility you get almost the same power as with inheritance, traits/mixins, etc. This is still amazing to me.

-- Bienlein