On Wednesday, 6 November 2013 at 08:22:36 UTC, Bienlein wrote:

> Then have a look at this thread in the Scala user forum:
> https://groups.google.com/forum/?hl=de#!topic/scala-user/D9QDOnHSUu8
> It is about build times in Scala not scaling up. One reply was
> "Do you have very fast SSDs in your computer?". When I read that
> I decided only to do a little spare time Scala project and that's
> it. Might serve me to find a better Java job one day. D has
> immutable objects and pure functions. I rather do D than Scala,
> actually ...
>

Do you really make heavy use of immutable objects and pure functions and get benefit from it? I've been trying for quite a while and there are many many impediments. The fact that const/immutable and postblits don't mix is a big issue. The fact that many functions in the library are not pure that you might want to use in a pure context (.dup, text with doubles, etc) reduces pure's value in a viral manner. Hopefully there will be a solution for const/immutable members with mutable aliasing in structs. Hopefully what should be pure in the libraries will be made pure. Hopefully the inference of purity in functions like chain will improve. But when you describe immutable and purity as a plus, are you describing the idea of its use as positive (which I agree is) or the actual use of it (which I think needs work)?

On Wed, 2013-11-06 at 08:26 +0100, Paulo Pinto wrote:
[…]
> I rather use D than Go, but it has more to do with Go's community with their religion decisions about generics, dynamic loading, exceptions, enumerations, package management than anything else.

I find the Go community excellent. The mailing list is only a small part of the community. Try coming to one of the monthly Go user group meetings in London.

All communities are "religious". This D community takes religious decisions just as much as the Go, Scala, C++, etc. ones. The position on generics is not strange if you understand the Go language, it's computational model and philosophy. Go is taking a non-standard position, but it is not wrong, it just means that approaches to algorithms you would take in Ada, C++, D, Rust, Java, Scala, etc. do not apply directly to Go. It is a shift of mindset and view. If this doesn't work for you, fine.

> The language follows the Pascal tradition of type declarations and safety before performance dirty tricks. I find quite appealing its Oberon and Alef/Lingo influences.
> 
> It is good enough for many cases where people, wrongly, still use C. For example, the complete UNIX user space.
> 
> Now for those of us that have become used to the niceties the mainstream languages have adopted from academia in the last 30 years, Go feels a bit too light.

But for those people seeking a native code language coming from Python, Go is a breath of fresh air where D, C++, etc. are claustrophobic language stuck in the attitudes of the 1970s.

> Anyway on my day job, we will not be moving away from JVM/.NET world any time soon.

You and most of the rest of the world. This is why Java 8, Ceylon, Kotlin, and Groovy (not to mention Clojure) on the one hand and C# and F# (not to mention VB) are way more important for most programmers than C, C++, D, Go, Rust.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

> in functions like chain will improve. But when you describe immutable and purity as a plus, are you describing the idea of its use as positive (which I agree is) or the actual use of it (which I think needs work)?

What I meant to say was that Scala wants to call itself
functional to a certain extend. But as a matter of fact a
language like D that doesn't claim to belong to the functional
camp has better support for FP than Scala. In case I do heavy
concurrent stuff immutable objects and pure functions are of
enourmous help. Did some heavy concurrent stuff for some years
and I can see that immutability has great value in that regards.
But I wouldn't make everything immutable. Only the objects I hand
over to some actor or to some parallel computation.

Yeah, the problem that in the end some C function is not const
and all your const correctnes in C++ becomes void I know. Again,
If I know something is happening concurrently I would take the
effort to copy the data into some immutable data structure just
to be on the save side that no other thread can mess around with
my data.

On Wed, 2013-11-06 at 10:53 +0100, Paulo Pinto wrote:
[…]
> I do know Scala, but my co-workers do not.
> 
> When you work in large organizations, you are constrained to what everyone knows.

Or are willing to be trained in. The problem is not the status quo in the organization, the problem is the intransigent inability to learn that far too many programmers seem to display. People should be wanting to use new technologies if available and appropriate. Of course the current language is a candidate and may be the right choice, it just shouldn't be assumed it is the only choice.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 6 November 2013 at 13:39:51 UTC, Russel Winder wrote:
> On Wed, 2013-11-06 at 08:26 +0100, Paulo Pinto wrote:
> […]
>> I rather use D than Go, but it has more to do with Go's community with their religion decisions about generics, dynamic loading, exceptions, enumerations, package management than anything else.
>
> I find the Go community excellent. The mailing list is only a small part
> of the community. Try coming to one of the monthly Go user group
> meetings in London.

A bit far away from Düsseldorf. :)

>
> All communities are "religious". This D community takes religious
> decisions just as much as the Go, Scala, C++, etc. ones. The position on
> generics is not strange if you understand the Go language, it's
> computational model and philosophy. Go is taking a non-standard
> position, but it is not wrong, it just means that approaches to
> algorithms you would take in Ada, C++, D, Rust, Java, Scala, etc. do not
> apply directly to Go. It is a shift of mindset and view. If this doesn't
> work for you, fine.
>
>> The language follows the Pascal tradition of type declarations and safety before performance dirty tricks. I find quite appealing its Oberon and Alef/Lingo influences.
>> 
>> It is good enough for many cases where people, wrongly, still use C. For example, the complete UNIX user space.
>> 
>> Now for those of us that have become used to the niceties the mainstream languages have adopted from academia in the last 30 years, Go feels a bit too light.
>
> But for those people seeking a native code language coming from Python,
> Go is a breath of fresh air where D, C++, etc. are claustrophobic
> language stuck in the attitudes of the 1970s.


I think the main issue is that many of those developers never learned the toolchains of Pascal family of languages and have so far mixed the C/C++ toolchains with native development.

>
>> Anyway on my day job, we will not be moving away from JVM/.NET world any time soon.
>
> You and most of the rest of the world. This is why Java 8, Ceylon,
> Kotlin, and Groovy (not to mention Clojure) on the one hand and C# and
> F# (not to mention VB) are way more important for most programmers than
> C, C++, D, Go, Rust.

Yep, on my area of work I can only use those languages on hobby projects.

My last C++ work project was in 2006 and we routinely replace C/C++ systems by JVM/.NET based ones, with C/C++ leftovers for the few cases where no other solution is possible.

Even for gaming hobby stuff I am using Unity/LibGDX which are good enough for my humble graphic skills.

--
Paulo

On Wednesday, 6 November 2013 at 14:06:19 UTC, Russel Winder wrote:
> On Wed, 2013-11-06 at 10:53 +0100, Paulo Pinto wrote:
> […]
>> I do know Scala, but my co-workers do not.
>> 
>> When you work in large organizations, you are constrained to what everyone knows.
>
> Or are willing to be trained in. The problem is not the status quo in
> the organization, the problem is the intransigent inability to learn
> that far too many programmers seem to display. People should be wanting
> to use new technologies if available and appropriate. Of course the
> current language is a candidate and may be the right choice, it just
> shouldn't be assumed it is the only choice.

It does not work on my field, because my employer does consulting for Fortune 500 companies usually multi-site with off-shoring component, where the technology stack is given by the customers themselves.

So unless Scala,D, Go, ... are requested, they won't be used.

--
Paulo

> It does not work on my field, because my employer does consulting for Fortune 500 companies usually multi-site with off-shoring component, where the technology stack is given by the customers themselves.
>
> So unless Scala,D, Go, ... are requested, they won't be used.

I'm out of the consulting business for quite a while now. Now I'm
an internal employee and have to put up with what the architects
decide. And my company is not a large organization. The CTO
things you need an architect and then your software development
is fine. The architect is good at drawing system diagrams and
theoretical things. He doesn't care about languages, would never
talk to some developer, neither would the CTO. If you want a
change to JDK8 within 2020 you have to explain to the architect
what a closure is and why it is beneficial. I think it will be
very hard ... The problem is in general that company internal
development is not on a good technical level. You have to work
for some startup or a good technical company such as Google,
Facebook, Apple, Yahoo, etc. Those guys are out of the league of
most "ordinary" developers. So it will be Java and something else
in your spare time. Not wanting to be fatalistic, but this is how
I see the situation.

-- Bienlein

On Wednesday, 6 November 2013 at 14:41:45 UTC, Bienlein wrote:
>> It does not work on my field, because my employer does consulting for Fortune 500 companies usually multi-site with off-shoring component, where the technology stack is given by the customers themselves.
>>
>> So unless Scala,D, Go, ... are requested, they won't be used.
>
> I'm out of the consulting business for quite a while now. Now I'm
> an internal employee and have to put up with what the architects
> decide. And my company is not a large organization. The CTO
> things you need an architect and then your software development
> is fine. The architect is good at drawing system diagrams and
> theoretical things. He doesn't care about languages, would never
> talk to some developer, neither would the CTO. If you want a
> change to JDK8 within 2020 you have to explain to the architect
> what a closure is and why it is beneficial. I think it will be
> very hard ... The problem is in general that company internal
> development is not on a good technical level. You have to work
> for some startup or a good technical company such as Google,
> Facebook, Apple, Yahoo, etc. Those guys are out of the league of
> most "ordinary" developers. So it will be Java and something else
> in your spare time. Not wanting to be fatalistic, but this is how
> I see the situation.
>
> -- Bienlein


Yeah, I am pretty old at this game. I already lost count how many technologies I have used since 1986. :)

On Wed, 2013-11-06 at 15:59 +0100, Paulo Pinto wrote:
[…]
> Yeah, I am pretty old at this game. I already lost count how many technologies I have used since 1986. :)

1986. You are a youngster then. ;-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 6 November 2013 at 07:02:20 UTC, Jonathan M Davis wrote:
> Yikes. Sorting time in D is trivial. It would never occur to me that that would be hard.

I know, it's something I use. Something one probably expects to Just Work. I thought for sure Go would have provided the needed functions, but no they didn't.

While I was trying to find additional information I came across this blog[1] which had such a fitting quote, "The sort package in Go is pretty neat." Directly followed by "there are some specific functions for sort some of the basic types."

When trying to write a blog which centers around the sort packaging being *the* example of why Go's lack of generics sucks, reading that the package is "neat" was not something I expected.

1. http://blog.jessta.id.au/2012/06/gos-sort-package.html