www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs Go in real life

reply "Atila Neves" <atila.neves gmail.com> writes:
So my buddy Jeff at work is a massive Go fan and goes on about it 
all the time. He even got me to try it once but I mostly hated 
it. To each his own. However, he laid down the gauntlet last 
Thursday saying his MQTT broker implementation in Go couldn't be 
beaten in performance. For those not in the know, MQTT is a 
publish/subscribe network protocol. And Go is all about parallel 
network programming, so what could beat it, right?

Always up for a challenge, I went ahead and implemented enough of 
an MQTT broker to handle the functionality required by the 
benchmark program he wrote to test his own code. In D of course, 
with the network code coming from vibe.d.

The result? 11% - 34% faster than the Go implementation depending 
on the workload (34%, 30%, 11%, 30%). The low end of that was 
with a higher number of connected clients, and that could always 
be me not using vibe.d well (I'd never used it before last 
Friday).

I also measured Mosquitto, an open-source C implementation. It 
mostly beat my D one, and went from 1% slower to 17% faster than 
the D/vibe.d combo depending on workload, with that 17% being an 
outlier (-1%, 5%, 17%, 3%, 3%).

I actually have error bars for all those values but thought it'd 
be too much to post them here. D FTW!

Atila

P.S. Not all was roses. Although getting to write D again was 
awesome (and I beat him), I ran into multiple problems:

- Trying to use dub to compile the project in release or profile 
mode flat out didn't work. I had to take the verbose output of 
dub, use it to compile vibe.d in debug mode into an object file 
and compile my own code separately and link it in. I believe this 
was a dmd regression. Speaking of which, why does dub recompile 
the world instead of tracking dependencies (I tried the rdmd 
option once but that didn't work, I can't remember why)?

- I ran into a dmd bug when I tried to use TaskPool.map with a 
delegate so I had to give up trying that possible optimisation.

- I ran into another dmd bug (it crashed) at one point if -inline 
was used.

- dub build with LDC and GDC failed miserably. I think it was 
because of vibe.d.
Nov 05 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Yeah, unfortunately there were lot of 2.063.2 bugs that vibe.d 
triggered during transition to 2.064, it was quite a mess for 
some time. I expect out-of-the-box experience to be much better 
at point of 2.064 release.
Nov 05 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 5 November 2013 at 13:11:26 UTC, Dicebot wrote:
 Yeah, unfortunately there were lot of 2.063.2 bugs that vibe.d 
 triggered during transition to 2.064, it was quite a mess for 
 some time. I expect out-of-the-box experience to be much better 
 at point of 2.064 release.
P.S. Also there are speculations about performance regressions, once those are figured out it may yield even better results :)
Nov 05 2013
parent "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 5 November 2013 at 13:12:33 UTC, Dicebot wrote:
 P.S. Also there are speculations about performance regressions,
 once those are figured out it may yield even better results :)
So I read while looking around for info on how to use vibe.d properly. I might revisit and remeasure once a see a post about it and rub it in my buddy's face again. :)
Nov 05 2013
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 5 November 2013 at 13:05:21 UTC, Atila Neves wrote:
 So my buddy Jeff at work is a massive Go fan and goes on about 
 it all the time. He even got me to try it once but I mostly 
 hated it. To each his own. However, he laid down the gauntlet 
 last Thursday saying his MQTT broker implementation in Go 
 couldn't be beaten in performance. For those not in the know, 
 MQTT is a publish/subscribe network protocol. And Go is all 
 about parallel network programming, so what could beat it, 
 right?

 Always up for a challenge, I went ahead and implemented enough 
 of an MQTT broker to handle the functionality required by the 
 benchmark program he wrote to test his own code. In D of 
 course, with the network code coming from vibe.d.

 The result? 11% - 34% faster than the Go implementation 
 depending on the workload (34%, 30%, 11%, 30%). The low end of 
 that was with a higher number of connected clients, and that 
 could always be me not using vibe.d well (I'd never used it 
 before last Friday).

 I also measured Mosquitto, an open-source C implementation. It 
 mostly beat my D one, and went from 1% slower to 17% faster 
 than the D/vibe.d combo depending on workload, with that 17% 
 being an outlier (-1%, 5%, 17%, 3%, 3%).

 I actually have error bars for all those values but thought 
 it'd be too much to post them here. D FTW!

 Atila

 P.S. Not all was roses. Although getting to write D again was 
 awesome (and I beat him), I ran into multiple problems:

 - Trying to use dub to compile the project in release or 
 profile mode flat out didn't work. I had to take the verbose 
 output of dub, use it to compile vibe.d in debug mode into an 
 object file and compile my own code separately and link it in. 
 I believe this was a dmd regression. Speaking of which, why 
 does dub recompile the world instead of tracking dependencies 
 (I tried the rdmd option once but that didn't work, I can't 
 remember why)?

 - I ran into a dmd bug when I tried to use TaskPool.map with a 
 delegate so I had to give up trying that possible optimisation.

 - I ran into another dmd bug (it crashed) at one point if 
 -inline was used.

 - dub build with LDC and GDC failed miserably. I think it was 
 because of vibe.d.
this is with dmd? I wonder how those numbers would look if you could get ldc/gdc up and running.
Nov 05 2013
parent reply "Atila Neves" <atila.neves gmail.com> writes:
 this is with dmd? I wonder how those numbers would look if you 
 could get ldc/gdc up and running.
Yep, dmd. I mentioned the problems getting the whole thing (including vibe.d) to compile with ldc and gdc because I was trying those two exactly to try and eke more performance out. Neither worked with dub and I think running them manually got me into problems too.
Nov 05 2013
parent reply Alexandr Druzhinin <drug2004 bk.ru> writes:
05.11.2013 22:17, Atila Neves пишет:
 this is with dmd? I wonder how those numbers would look if you could
 get ldc/gdc up and running.
Yep, dmd. I mentioned the problems getting the whole thing (including vibe.d) to compile with ldc and gdc because I was trying those two exactly to try and eke more performance out. Neither worked with dub and I think running them manually got me into problems too.
Did you try --compiler=ldmd2 to use ldc? May be it helps.
Nov 05 2013
parent "Atila Neves" <atila.neves gmail.com> writes:
 Did you try --compiler=ldmd2 to use ldc? May be it helps.
I tried every combination I could think of, including that one.
Nov 05 2013
prev sibling next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
So, is he writing D code now :D. Or did he complain about the 
syntax, all the types being on the left?
Nov 05 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, November 05, 2013 16:27:39 Jesse Phillips wrote:
 So, is he writing D code now :D. Or did he complain about the
 syntax, all the types being on the left?
LOL. I doubt that someone who's that big a fan of Go would switch thanks to that (would you have switched to Go if the Go implementation had won?) - especially when Go and D are so dissimilar. In general, I would expect fans of Go to dislike D and fans of D to dislike Go simply because of how very different their designs are. But it _would_ show him that D can compete with Go for performance even in Go's area of expertise. Go is on the list of languages that I'd like to spend more time becoming familiar with, because I think that it's good to know lots of programming languages, but the more I learn about it, the less I like it. Its design philosophies are just too different from my preferences. - Jonathan M Davis
Nov 05 2013
next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 6 November 2013 at 05:38:54 UTC, Jonathan M Davis 
wrote:
 LOL. I doubt that someone who's that big a fan of Go would 
 switch thanks to
 that (would you have switched to Go if the Go implementation 
 had won?) -
Of course not, Go puts the types on the wrong side for me to switch. Had a coworker mention to me that I should look into the philosophy of Go amongst other points (not enough tech talk around). After a little bit of discussion (mostly not around Go) I let him know I was already aware of Go's philosophy and it didn't match my desires. Citing my attempt at Sorting Time[1] as an example. He agreed, lack of generics sucks. 1. http://he-the-great.livejournal.com/49072.html
Nov 05 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 06, 2013 07:18:43 Jesse Phillips wrote:
 On Wednesday, 6 November 2013 at 05:38:54 UTC, Jonathan M Davis
 
 wrote:
 LOL. I doubt that someone who's that big a fan of Go would
 switch thanks to
 that (would you have switched to Go if the Go implementation
 had won?) -
Of course not, Go puts the types on the wrong side for me to switch. Had a coworker mention to me that I should look into the philosophy of Go amongst other points (not enough tech talk around). After a little bit of discussion (mostly not around Go) I let him know I was already aware of Go's philosophy and it didn't match my desires. Citing my attempt at Sorting Time[1] as an example. He agreed, lack of generics sucks. 1. http://he-the-great.livejournal.com/49072.html
Yikes. Sorting time in D is trivial. It would never occur to me that that would be hard. But I'm so sold on D's way of doing things with ranges and generic code that most any other language is likely to seem worse in comparison. - Jonathan M Davis
Nov 05 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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
Nov 06 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
06-Nov-2013 19:34, Jesse Phillips пишет:
 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."
I swear when I glanced at [1] I thought it was sarcasm. Reading it again - I see it wasn't :)
 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
-- Dmitry Olshansky
Nov 06 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 06.11.2013 19:45, schrieb Dmitry Olshansky:
 06-Nov-2013 19:34, Jesse Phillips пишет:
 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."
I swear when I glanced at [1] I thought it was sarcasm. Reading it again - I see it wasn't :)
You will find lots of similar explanations from Go devotees when reading gonuts mailing list. :) -- Paulo
Nov 06 2013
prev sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 6 November 2013 at 18:45:49 UTC, Dmitry Olshansky 
wrote:
 I swear when I glanced at [1] I thought it was sarcasm. Reading 
 it again - I see it wasn't :)
I know it. But I was already aware the author was very pro-Go from [2], "Interfaces in Go are very powerful, but their power comes from being generic." FYI, the blogs are actually good for learning Go (in the small scale), but they didn't contain quite enough information that I needed to reference them (just reiterated less information than I already had).
 1. http://blog.jessta.id.au/2012/06/gos-sort-package.html
2. http://blog.jessta.id.au/2011/06/golang-interfaces.html
Nov 06 2013
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 6 November 2013 at 15:34:54 UTC, Jesse Phillips 
wrote:
 1. http://blog.jessta.id.au/2012/06/gos-sort-package.html
Hmm... if sort.Sort accepts a sortable interface, they could define those 3 methods for respective arrays so that they would satisfy the interface, and sort.Sort would accept them transparently. Well, if go allows extending array's interface.
Nov 06 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 6 November 2013 at 20:52:41 UTC, Kagamin wrote:
 On Wednesday, 6 November 2013 at 15:34:54 UTC, Jesse Phillips 
 wrote:
 1. http://blog.jessta.id.au/2012/06/gos-sort-package.html
Hmm... if sort.Sort accepts a sortable interface, they could define those 3 methods for respective arrays so that they would satisfy the interface, and sort.Sort would accept them transparently. Well, if go allows extending array's interface.
It does not. A specific type must be created and the functions defined for it. Was one of the first WTFs I hit. It doesn't solve the lack of generics problem, which is much more important.
Nov 06 2013
parent "Kagamin" <spam here.lot> writes:
Heh, from http://research.swtch.com/interfaces
 Among other metadata, the type description structure contains a 
 list of the methods implemented by that type. Similarly, the 
 compiler generates a (different) type description structure for 
 each interface type like Stringer; it too contains a method 
 list. The interface runtime computes the itable by looking for 
 each method listed in the interface type's method table in the 
 concrete type's method table.
So methods are tightly coupled with types after all. Doesn't look like what go claims about decoupling types and methods.
Nov 07 2013
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 6 November 2013 at 05:38:54 UTC, Jonathan M Davis 
wrote:
 On Tuesday, November 05, 2013 16:27:39 Jesse Phillips wrote:
 So, is he writing D code now :D. Or did he complain about the
 syntax, all the types being on the left?
LOL. I doubt that someone who's that big a fan of Go would switch thanks to that (would you have switched to Go if the Go implementation had won?) - especially when Go and D are so dissimilar. In general, I would expect fans of Go to dislike D and fans of D to dislike Go simply because of how very different their designs are. But it _would_ show him that D can compete with Go for performance even in Go's area of expertise. Go is on the list of languages that I'd like to spend more time becoming familiar with, because I think that it's good to know lots of programming languages, but the more I learn about it, the less I like it. Its design philosophies are just too different from my preferences. - Jonathan M Davis
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. 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. Anyway on my day job, we will not be moving away from JVM/.NET world any time soon. -- Paulo
Nov 05 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 6 November 2013 at 07:26:42 UTC, Paulo Pinto wrote:
 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.
And still it is not quite safe.
 Anyway on my day job, we will not be moving away from JVM/.NET 
 world any time soon.
You may want to look at scala then.
Nov 05 2013
next sibling parent reply "Bienlein" <jeti789 web.de> writes:
Go is on the list of languages that I'd like to spend more time 
becoming familiar with, because I think that it's good to know 
lots of programming languages, but the more I learn about it, 
the less I like it. Its design philosophies are just too 
different from my preferences.
Go IMHO is a modernized C and there is nothing in addition from what I can see (except CSP). It is what turns out if someone nowadays did something exactly like C with modern means.
I rather use D than Go, but it has more to do with Go's 
community with their religion decisions about generics, dynamic 
loading,
I spent some time reading postings in the Go user forum. Go is today what for us earlier was Basic or Pascal. Something very exciting to get into all this stuff. People seem to be quite religious about it in the sense that it feels holes of boredom in your life by getting exciting about a programming language.
 You may want to look at scala then.
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 ... Lightweight Threads in Go and Rust What is a *BIG* plus for Go and Rust are lightweight threads. You can spawn some thousand of them and it's no problem. I really wished D had that kind of threads as well. For nowaydays server-side development where applications need to bear heavy load and load peaks this is an important thing. -- Bienlein
Nov 06 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 6 November 2013 at 08:22:36 UTC, Bienlein wrote:
 ..
 Lightweight Threads in Go and Rust

 What is a *BIG* plus for Go and Rust are lightweight threads. 
 You
 can spawn some thousand of them and it's no problem. I really
 wished D had that kind of threads as well. For nowaydays
 server-side development where applications need to bear heavy
 load and load peaks this is an important thing.

 -- Bienlein
Which are also available in many JVM implementations and in .NET as tasks and asynch. Although, it is nice PR for HN guys that ignore what these platforms offer. -- Paulo
Nov 06 2013
parent reply "Bienlein" <jeti789 web.de> writes:
 Which are also available in many JVM implementations and in 
 .NET as tasks and asynch.

 Although, it is nice PR for HN guys that ignore what these 
 platforms offer.
I'm sure about that. When you block a thread in Java it is no longer available for the thread pool and increasing the size of it cannot be done at will, because creating new threads is not lightweigt on the JVM. There is a CSP implemention for Java made by some English university: http://www.cs.kent.ac.uk/projects/ofa/jcsp/ Groovy CSP makes use of it: http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html But I haven't tried what happens when you block threads.
Nov 06 2013
next sibling parent "Bienlein" <jeti789 web.de> writes:
On Wednesday, 6 November 2013 at 10:10:06 UTC, Bienlein wrote:
 Which are also available in many JVM implementations and in 
 .NET as tasks and asynch.

 Although, it is nice PR for HN guys that ignore what these 
 platforms offer.
I'm sure about that. When you block a thread in Java it is no longer available for the thread pool and increasing the size of it cannot be done at will, because creating new threads is not lightweigt on the JVM.
Ah, unhappily Groovy CSP also can't do this: "Some implementations (e.g. GoLang) can also detach the thread from the CSP process when blocked on a channel." Source: http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html So it's basically non-blocking IO. -- Bienlein
Nov 06 2013
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-11-06 at 11:10 +0100, Bienlein wrote:
[…]
 I'm sure about that. When you block a thread in Java it is no
 longer available for the thread pool and increasing the size of
 it cannot be done at will, because creating new threads is not
 lightweigt on the JVM.
Anyone using thread management explicitly in Java is doing it wrong. The one thing Go has totally right is "share data by passing messages" (*), even the functional programming community know this one. Kernel threads are not lightweight on any system, hence threads pools and fibres (**).
 There is a CSP implemention for Java made by some English
 university: http://www.cs.kent.ac.uk/projects/ofa/jcsp/ Groovy
 CSP makes use of it:
 http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html But I
 haven't tried what happens when you block threads.
JCSP has many problems, not least it hasn't been formally released in eons. People are still working on it but their concerns are academic focussed rather than production focussed. Long story elided. Groovy CSP is an integral part of GPars, but Václav Pech and I have been wanting to create a new CSP realization in GPars directly rather than using JCSP as a delegate. Sadly neither of us have the time these days. The whole idea of even knowing about threads when using CSP, especially Groovy CSP, and GPars in general, is total anathema. The whole point is that the comutational model is about messages and the events they cause. Threads are a hidden animating infrastructure. Programmers working with CSP should never think about threads. (*) There are some reasonable exceptions, but they are fewer and further between than most people think. (**) Which are really just threads from the 1970s and 1980s. -- 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
Nov 06 2013
prev sibling next sibling parent "qznc" <qznc web.de> writes:
On Wednesday, 6 November 2013 at 08:22:36 UTC, Bienlein wrote:
 Lightweight Threads in Go and Rust

 What is a *BIG* plus for Go and Rust are lightweight threads. 
 You
 can spawn some thousand of them and it's no problem. I really
 wished D had that kind of threads as well. For nowaydays
 server-side development where applications need to bear heavy
 load and load peaks this is an important thing.
Use std.parallelism.Task or core.thread.Fiber. This is also conveniently packaged in Vibe.d. They have some syntactic sugar, though.
Nov 06 2013
prev sibling parent reply "Daniel Davidson" <nospam spam.com> writes:
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)?
Nov 06 2013
parent "Bienlein" <jeti789 web.de> writes:
 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.
Nov 06 2013
prev sibling next sibling parent "Bienlein" <jeti789 web.de> writes:
 Anyway on my day job, we will not be moving away from JVM/.NET 
 world any time soon.
You may want to look at scala then.
I fear the language on the JVM in 95% of all cases will be Java. Sad, but I guess it is true. But it helps to talk about it ... ;-). You might have a look at Kotlin: http://kotlin.jetbrains.org/ I like it very much: Scala without the mistakes that were made in Scala. But it will take another year till Kotlin turns 1.0.
Nov 06 2013
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 6 November 2013 at 07:33:54 UTC, deadalnix wrote:
 On Wednesday, 6 November 2013 at 07:26:42 UTC, Paulo Pinto 
 wrote:
 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.
And still it is not quite safe.
 Anyway on my day job, we will not be moving away from JVM/.NET 
 world any time soon.
You may want to look at scala then.
I do know Scala, but my co-workers do not. When you work in large organizations, you are constrained to what everyone knows. -- Paulo
Nov 06 2013
parent reply Russel Winder <russel winder.org.uk> writes:
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
Nov 06 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Nov 06 2013
parent reply "Bienlein" <jeti789 web.de> writes:
 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
Nov 06 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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. :)
Nov 06 2013
parent reply Russel Winder <russel winder.org.uk> writes:
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
Nov 06 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 06.11.2013 16:10, schrieb Russel Winder:
 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. ;-)
Started using computers at the age of 10, so 1986 - 10 ...
Nov 06 2013
parent reply "Bienlein" <jeti789 web.de> writes:
On Wednesday, 6 November 2013 at 16:24:12 UTC, Paulo Pinto wrote:
 Am 06.11.2013 16:10, schrieb Russel Winder:
 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. ;-)
Started using computers at the age of 10, so 1986 - 10 ...
1976? Man, you are a teenager then ;-)
Nov 06 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-11-06 at 17:39 +0100, Bienlein wrote:
[…]
 1976? Man, you are a teenager then ;-)
The year I went apesh!t when I found that the elliptic integral solver routines in the NAG library were broken. I idled away the time by creating idioms for writing abstract data type code in FORTRAN 66. Bizarrely, analogous tricks appear to be essential in JavaScript. It was also the third year of listening to Dark Side of the Moon and the first year of Wish You Were Here which is much better. But you didn't want to know this. -- 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
Nov 06 2013
parent "Mike James" <foo bar.com> writes:
Mmmm - that reminds me...

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

-=mike=-


"Russel Winder" <russel winder.org.uk> wrote in message 
news:mailman.230.1383757333.9546.digitalmars-d puremagic.com...
 On Wed, 2013-11-06 at 17:39 +0100, Bienlein wrote:
 […]
 1976? Man, you are a teenager then ;-)
The year I went apesh!t when I found that the elliptic integral solver routines in the NAG library were broken. I idled away the time by creating idioms for writing abstract data type code in FORTRAN 66. Bizarrely, analogous tricks appear to be essential in JavaScript. It was also the third year of listening to Dark Side of the Moon and the first year of Wish You Were Here which is much better. But you didn't want to know this. -- 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
Nov 07 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2013 6:05 AM, Russel Winder wrote:
 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.
While your comment seems to be a commonsense truism, there are so many new things constantly coming out that one cannot possibly learn them all and pick the best, and even then there's another one that just appeared. It is not an unreasonable strategy to wait a bit and see which ones have staying power. Most don't, and in hindsight would have been a waste of time to learn.
Nov 06 2013
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-11-06 at 08:33 +0100, deadalnix wrote:
[…]
 
 You may want to look at scala then.
Or possibly Ceylon or Kotlin. Or Groovy. At least on the JVM -- 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
Nov 06 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
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
Nov 06 2013
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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
Nov 06 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/6/13 5:38 AM, 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.
Online fora are the universal place where the community meets.
 All communities are "religious". This D community takes religious
 decisions just as much as the Go, Scala, C++, etc. ones.
I disagree with this relativism that makes all language communities somehow idempotent. Programming languages' communities are very strongly influenced by their leaders. I'm friends with Walter so I can't be objective on that one, but let me just say his core values are well propagated within the community. I'll abstain to comment much about the Go community beyond this: it doesn't seem my cup of tea (even leaving aside technical issues).
 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.
I also disagree with this "agree to disagree" that leaves everybody vacuously lukewarm. I think there are things that are just right and things that are just wrong. Go's team was unable to add generics to the language. That locks Go out of a variety of tools and techniques, which does not make it only "different", it effectively pauperizes the language leaving it the sole advantage that it's smaller. One non-technical current that I find quite difficult to like is that the Go proponents have not only shun generics, but effectively made it a politically incorrect topic in their community. All discussion on generics on the go forums are quickly shushed away.
 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.
Interesting. Why would be D in the same category with C++ 1970s-attidude-wise, and how is Go a breath of fresh air? If anything, the latter seems to me it kinda implements ideas that seemed cool in the 1970s, but nothing since. Andrei
Nov 06 2013
parent reply "Max Samukha" <maxsamukha gmail.com> writes:
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. For that matter, D got its type system all wrong compared to Haskell. So why won't we all move there?
Nov 22 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 22 2013
parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Friday, 22 November 2013 at 23:08:38 UTC, Andrei Alexandrescu 
wrote:
 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."
Ok, I stand corrected.
 For that matter, D got
 its type system all wrong compared to Haskell. So why won't we 
 all move
 there?
Move where?
Tried to implement a GADT in D?
 Andrei
Nov 30 2013
parent "Max Samukha" <maxsamukha gmail.com> writes:
On Saturday, 30 November 2013 at 21:14:53 UTC, Max Samukha wrote:
 On Friday, 22 November 2013 at 23:08:38 UTC, Andrei 
 Alexandrescu wrote:
 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."
Ok, I stand corrected.
 For that matter, D got
 its type system all wrong compared to Haskell. So why won't 
 we all move
 there?
Move where?
Tried to implement a GADT in D?
To clarify: "Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly." Can you implement a GADT in D as "smoothly" as in Haskell?
Nov 30 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2013 5:38 AM, Russel Winder wrote:
 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 know that D carries forward some attitudes from the 1980's, particularly in its orientation towards supporting the separate compilation model, its dependency on object file formats and standard linkers, etc. But other than that I do not know what you mean about D.
Nov 06 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2013-11-05 at 21:38 -0800, Jonathan M Davis wrote:
[…]
 Go is on the list of languages that I'd like to spend more time becoming 
 familiar with, because I think that it's good to know lots of programming 
 languages, but the more I learn about it, the less I like it. Its design 
 philosophies are just too different from my preferences.
I would suggest that this is the core of the point: programming language is about personal preference as much as it is about language features. There are many dimensions to the scale including language complexity, ability to easily express algorithms, ease of handling errors and exceptions, context of use, problems being addressed, composition of team programming, individual preference, etc., etc. Go is a very small language, with great data communication mechanisms, a simple build and deploy strategy, a view that DVCS (Git, Mercurial and Bazaar) is all the version management you need, all pivoting around static compilation of executables. I really like it, except for the obsession with error codes and no exceptions (except one which is the "terminate now" exception. Go is being pushed by Google and now Canonical, so its market penetration and traction in the programming community is assured. Rust is an interesting language, not least because it is taking many, many lessons from the functional programming community and transporting them into the imperative native code world. cf. the influence of ML and especially OCaml. Like C++ and D, Rust is actually a big language and aimed at the same sort of context and problem. And, of course, Rust has Mozilla pushing it. Go and Rust are, of course, new languages, C++ and D are old language. For D this is a bad thing. D is always playing "catch up" and has no big influential organization saying "this is the language we use for our developments (in such and such an area)". Given the current situation, I would advocate creating a new language, call it Brite say, which is an evolution of D2 (where the difference is in reality zero), and push the LDC2 realization of it as the primary implementation, with the GCC version a proud second. This way you get "new", "llvm", and a high quality statically typed native code language out there for people to go "wow" to. -- 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
Nov 06 2013
parent reply "Bienlein" <jeti789 web.de> writes:
And, of course, Rust has
Mozilla pushing it.
Well, I don't know what muscle Mozilla has. I don't really understand where they get their money from (in part from Google?). Mozilla backing Rust is on a smaller scale than M$ backing C#.
Go is being pushed by Google and now Canonical, so its market
penetration and traction in the programming community is assured.
The Go user forum is the most active one I have seen besides the one from Python. But it doesn't look like Go is a success inside Google itself so far. For both, Go and Rust, wait and see might be a good strategy.
Nov 07 2013
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2013-11-07 at 13:04 +0100, Bienlein wrote:
[…]
 The Go user forum is the most active one I have seen besides the
 one from Python. But it doesn't look like Go is a success inside
 Google itself so far.
 
 For both, Go and Rust, wait and see might be a good strategy.
I guess the question is whether Canonical and Google end up rewriting the systems currently using Go in something else sometime down the line. There are a lot of SMEs in London using Go as their core language. Their enthusiasm stems, I think, from otherwise having to use C. None of them have used or even heard of D (until I mention it to them in conversation). -- 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
Nov 07 2013
parent reply "Bienlein" <jeti789 web.de> writes:
 There are a lot of SMEs in London using Go as their core 
 language. Their
 enthusiasm stems, I think, from otherwise having to use C.
Well, I think that says it all. Go is made by C programmers for C programmers. I would say that this is even objectively correct. What puzzles me is the enormous activity in the Go forum. Only the Python forum has that much traffic. It seems to me that people are all that happy if they have a language with which they can just start hacking around on something. That is because Go doesn't force anyone to think about design. The only design-level construct it has is the class an that's it. Embedding is truly only to save coding effort not having to type in dereferenciation chains as in C. There is nothing except classes, but no inheritance, traits, mixins, overriding, etc. So there is nothing that forces you to think about your design in Go. And you don't have to know about manual memory management as in Rust. -- Bienlein
Nov 21 2013
next sibling parent reply "Bienlein" <jeti789 web.de> writes:
On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:
 What puzzles me is the enormous activity in the Go forum. Only
 the Python forum has that much traffic. It seems to me that
 people are all that happy if they have a language with which 
 they
 can just start hacking around on something.

 That is because Go doesn't force anyone to think about design.
 The only design-level construct it has is the class an that's 
 it.
 Embedding is truly only to save coding effort not having to type
 in dereferenciation chains as in C. There is nothing except
 classes, but no inheritance, traits, mixins, overriding, etc. So
 there is nothing that forces you to think about your design in
 Go. And you don't have to know about manual memory management as
 in Rust.

 -- Bienlein
I forgot to say that I really don't know what this will end up in ...
Nov 21 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 21 November 2013 at 09:57:35 UTC, Bienlein wrote:
 On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:
 What puzzles me is the enormous activity in the Go forum. Only
 the Python forum has that much traffic. It seems to me that
 people are all that happy if they have a language with which 
 they
 can just start hacking around on something.

 That is because Go doesn't force anyone to think about design.
 The only design-level construct it has is the class an that's 
 it.
 Embedding is truly only to save coding effort not having to 
 type
 in dereferenciation chains as in C. There is nothing except
 classes, but no inheritance, traits, mixins, overriding, etc. 
 So
 there is nothing that forces you to think about your design in
 Go. And you don't have to know about manual memory management 
 as
 in Rust.

 -- Bienlein
I forgot to say that I really don't know what this will end up in ...
I'm wary of languages that are hyped by big companies or the web programming community. First there was Java which is still getting face lifts and plastic surgery. Then there was Ruby, "the way to go", but it hasn't convinced me yet. If all these languages are "soooo good", why do people still feel the need to come up with new solutions (cf. all the new languages for the JVM)? The answer is probably "tunnel vision" design and development. The language designers offer one ideology and users don't have to think when designing their programs. Simple as that. If you have a big company to back this up, people will think "it's THE ultimate best ever" language. Personally, I enjoy the freedom of D programming, even though with this freedom come tough questions as to the design of the program.
Nov 21 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 21 November 2013 at 11:07:15 UTC, Chris wrote:
 On Thursday, 21 November 2013 at 09:57:35 UTC, Bienlein wrote:
 On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:
 What puzzles me is the enormous activity in the Go forum. Only
 the Python forum has that much traffic. It seems to me that
 people are all that happy if they have a language with which 
 they
 can just start hacking around on something.

 That is because Go doesn't force anyone to think about design.
 The only design-level construct it has is the class an that's 
 it.
 Embedding is truly only to save coding effort not having to 
 type
 in dereferenciation chains as in C. There is nothing except
 classes, but no inheritance, traits, mixins, overriding, etc. 
 So
 there is nothing that forces you to think about your design in
 Go. And you don't have to know about manual memory management 
 as
 in Rust.

 -- Bienlein
I forgot to say that I really don't know what this will end up in ...
I'm wary of languages that are hyped by big companies or the web programming community. First there was Java which is still getting face lifts and plastic surgery. Then there was Ruby, "the way to go", but it hasn't convinced me yet. If all these languages are "soooo good", why do people still feel the need to come up with new solutions (cf. all the new languages for the JVM)? The answer is probably "tunnel vision" design and development. The language designers offer one ideology and users don't have to think when designing their programs. Simple as that. If you have a big company to back this up, people will think "it's THE ultimate best ever" language. Personally, I enjoy the freedom of D programming, even though with this freedom come tough questions as to the design of the program.
You mean like C and C++ were by AT&T? Or FORTRAN and PL/I/M by IBM? Java was not the first one. Languages need a corporate sponsor or a killer framework to gain market share. Luckily we can now point to Facebook as possible corporate sponsor. -- Paulo
Nov 21 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 21 November 2013 at 12:14:09 UTC, Paulo Pinto wrote:
 On Thursday, 21 November 2013 at 11:07:15 UTC, Chris wrote:
 On Thursday, 21 November 2013 at 09:57:35 UTC, Bienlein wrote:
 On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:
 What puzzles me is the enormous activity in the Go forum. 
 Only
 the Python forum has that much traffic. It seems to me that
 people are all that happy if they have a language with which 
 they
 can just start hacking around on something.

 That is because Go doesn't force anyone to think about 
 design.
 The only design-level construct it has is the class an 
 that's it.
 Embedding is truly only to save coding effort not having to 
 type
 in dereferenciation chains as in C. There is nothing except
 classes, but no inheritance, traits, mixins, overriding, 
 etc. So
 there is nothing that forces you to think about your design 
 in
 Go. And you don't have to know about manual memory 
 management as
 in Rust.

 -- Bienlein
I forgot to say that I really don't know what this will end up in ...
I'm wary of languages that are hyped by big companies or the web programming community. First there was Java which is still getting face lifts and plastic surgery. Then there was Ruby, "the way to go", but it hasn't convinced me yet. If all these languages are "soooo good", why do people still feel the need to come up with new solutions (cf. all the new languages for the JVM)? The answer is probably "tunnel vision" design and development. The language designers offer one ideology and users don't have to think when designing their programs. Simple as that. If you have a big company to back this up, people will think "it's THE ultimate best ever" language. Personally, I enjoy the freedom of D programming, even though with this freedom come tough questions as to the design of the program.
You mean like C and C++ were by AT&T? Or FORTRAN and PL/I/M by IBM? Java was not the first one. Languages need a corporate sponsor or a killer framework to gain market share.
D's advantage is that there is no committee, laboratory or marketing department that decides which features to implement. It's as close to a grassroots thing as you can get, I think.
 Luckily we can now point to Facebook as possible corporate 
 sponsor.
But that's post-factum. The language already happily exists outside the corporate sphere, unlike Java that was a product from the very beginning.
 --
 Paulo
Nov 21 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/13 7:31 AM, Chris wrote:
 Luckily we can now point to Facebook as possible corporate sponsor.
But that's post-factum. The language already happily exists outside the corporate sphere, unlike Java that was a product from the very beginning.
Each language has its story, but it's undeniable that corporate sponsorship offers a lot of liftoff. Back in 2010 (I think) a highly influential manager at Facebook said "I'd much more support use of Go than D at Facebook because Go has Google behind it." That was an assessment based exclusively on social proof, before (and instead of) any technical argument. Fortunately a lot has changed since :o). Andrei
Nov 21 2013
next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei 
Alexandrescu wrote:
 Fortunately a lot has changed since :o).
Please, do tell. ;)
Nov 21 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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). Walter and I are working on a second large project, which is quite likely to be a hit. The bug bounty is an obvious nod of interest. Things are happening. At this point focusing on making D solid and reliable is the best thing to do. Andrei
Nov 21 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 At this point focusing on making D solid and reliable is the 
 best thing to do.
At this point what's important is to perform the small breaking changes that are left to do (and deprecate what needs to be deprecated), because doing that even later will be a problem. Bye, bearophile
Nov 21 2013
next sibling parent Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-21 22:17:05 +0000, bearophile said:

 Andrei Alexandrescu:
 
 At this point focusing on making D solid and reliable is the best thing to do.
At this point what's important is to perform the small breaking changes that are left to do (and deprecate what needs to be deprecated), because doing that even later will be a problem. Bye, bearophile
+1
Nov 21 2013
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
22-Nov-2013 02:17, bearophile пишет:
 Andrei Alexandrescu:

 At this point focusing on making D solid and reliable is the best
 thing to do.
At this point what's important is to perform the small breaking changes that are left to do (and deprecate what needs to be deprecated), because doing that even later will be a problem.
Spot on, +1 from me.
 Bye,
 bearophile
-- Dmitry Olshansky
Nov 22 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 21 November 2013 at 22:17:07 UTC, bearophile wrote:
 Andrei Alexandrescu:

 At this point focusing on making D solid and reliable is the 
 best thing to do.
 changes that are left to do
property int[$] x=[1,2,3];
Nov 22 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-22 09:56, eles wrote:

 int[$] x=[1,2,3];
This would hopefully not be a braking change. The dollar sign can't be used like that currently? -- /Jacob Carlborg
Nov 22 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 22, 2013 11:20:41 Jacob Carlborg wrote:
 On 2013-11-22 09:56, eles wrote:
 int[$] x=[1,2,3];
This would hopefully not be a braking change. The dollar sign can't be used like that currently?
What would that even mean? The only thing that $ is used for is for representing the length of the array in an indexing or slicing operation. That statement is trying to use it in a declaration, which is nonsensical. - Jonathan M Davis
Nov 22 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 What would that even mean? The only thing that $ is used for is 
 for
 representing the length of the array in an indexing or slicing 
 operation. That
 statement is trying to use it in a declaration, which is 
 nonsensical.
It's not nonsensical, it's a new tiny feature. It means the lenght of x is statically determined by the literal. So this: int[$] x=[1,2,3]; means: int[3] x=[1,2,3]; But this is not a breaking change, it's just an additive change, so it's not urgent. Bye, bearophile
Nov 22 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 21 November 2013 at 21:36:28 UTC, 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). Walter and I are working on a second large project, which is quite likely to be a hit. The bug bounty is an obvious nod of interest. Things are happening. At this point focusing on making D solid and reliable is the best thing to do. Andrei
Any plans for rvalue references before D gets stable?
Nov 21 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 21 November 2013 at 21:36:28 UTC, 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). Walter and I are working on a second large project, which is quite likely to be a hit. The bug bounty is an obvious nod of interest. Things are happening. At this point focusing on making D solid and reliable is the best thing to do. Andrei
Just reiterating a common point: We have a smattering of things that need fixing that involve breakage. Surely we should make said changes now, not later? Or is it implicit in what you're saying that things like rvalue ref, property etc. are now won't-fix until D3 or whatever comes next?
Nov 21 2013
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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.
Nov 22 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:

 I would have expected a lot more speedup than just 2x, D being 
 a compiled language.
I have seen many cases where Python is faster than D: reading files by line, some cases of associative array creation, and more. Python contains many very efficient routines written in C. Bye, bearophile
Nov 22 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdan.org> writes:
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
Nov 22 2013
parent "SomeDude" <lovelydear mailmetrash.com> writes:
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
Nov 24 2013
prev sibling next sibling parent "Bienlein" <jeti789 web.de> writes:
On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei
Alexandrescu wrote:
 Each language has its story, but it's undeniable that corporate 
 sponsorship offers a lot of liftoff.
I think books for some new language being available is also an important factor. It tells people that some language has already received some attention and an investment in that new language is less likely to be in vain. I remember that Scala received a lot of attention in my Java community when the Scala book by Martin Odersky was published. Last week Dart went 1.0. You can already now buy 4 books about it, one from a renowned author such as Gilad Braha. I think the book about D by Andrei was very important and it would be a good thing if during the years more books about D would follow. -- Bienlein
Nov 22 2013
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei 
Alexandrescu wrote:
 On 11/21/13 7:31 AM, Chris wrote:
 Luckily we can now point to Facebook as possible corporate 
 sponsor.
But that's post-factum. The language already happily exists outside the corporate sphere, unlike Java that was a product from the very beginning.
Each language has its story, but it's undeniable that corporate sponsorship offers a lot of liftoff. Back in 2010 (I think) a highly influential manager at Facebook said "I'd much more support use of Go than D at Facebook because Go has Google behind it." That was an assessment based exclusively on social proof, before (and instead of) any technical argument. Fortunately a lot has changed since :o). Andrei
Yes, yes, yes. You are of course right that corporate backing gives a language a boost, even if it's a mediocre language. But as soon as corporate thinking comes into a language (profit, ideology, branding, hype and whatnot), it's doomed. D has to breathe, and I admire all the people who have made D happen, and who are making it happen. I've learned a lot just by listening (well, reading).
Nov 22 2013
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Friday, 22 November 2013 at 10:29:35 UTC, Chris wrote:
 Yes, yes, yes. You are of course right that corporate backing 
 gives a language a boost, even if it's a mediocre language. But 
 as soon as corporate thinking comes into a language (profit, 
 ideology, branding, hype and whatnot), it's doomed. D has to 
 breathe, and I admire all the people who have made D happen, 
 and who are making it happen. I've learned a lot just by 
 listening (well, reading).
You're talking about corporate _management_ rather than corporate backing. The former can obviously lead to problems (though it doesn't have to) -- the latter is almost invariably good, as it means there's someone who can serve as guarantor that any necessary work will get done.
Nov 22 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 12:34:23 UTC, Joseph Rushton 
Wakeling wrote:
 On Friday, 22 November 2013 at 10:29:35 UTC, Chris wrote:
 Yes, yes, yes. You are of course right that corporate backing 
 gives a language a boost, even if it's a mediocre language. 
 But as soon as corporate thinking comes into a language 
 (profit, ideology, branding, hype and whatnot), it's doomed. D 
 has to breathe, and I admire all the people who have made D 
 happen, and who are making it happen. I've learned a lot just 
 by listening (well, reading).
You're talking about corporate _management_ rather than corporate backing. The former can obviously lead to problems (though it doesn't have to) -- the latter is almost invariably good, as it means there's someone who can serve as guarantor that any necessary work will get done.
You cannot separate the two. Management will creep into development sooner or later. E.g. one day D might implement features that have to do with what Facebook needs more than features that programmers need in general. So a module std.webshite.upload.latest.picture gets all the attention while std.reallyhandy is being neglected.
Nov 22 2013
next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Friday, 22 November 2013 at 13:22:10 UTC, Chris wrote:
 You cannot separate the two. Management will creep into 
 development sooner or later. E.g. one day D might implement 
 features that have to do with what Facebook needs more than 
 features that programmers need in general. So a module 
 std.webshite.upload.latest.picture gets all the attention while 
 std.reallyhandy is being neglected.
Attention of and negclection from the people payed by facebook.
Nov 22 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris wrote:

 E.g. one day D might implement features that have to do with 
 what Facebook needs more than features that programmers need in 
 general. So a module std.webshite.upload.latest.picture gets 
 all the attention while std.reallyhandy is being neglected.
Do you know one or two cases where this phenomenon has happened to a language? Bye, bearophile
Nov 22 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 14:11:50 UTC, bearophile wrote:
 Chris wrote:

 E.g. one day D might implement features that have to do with 
 what Facebook needs more than features that programmers need 
 in general. So a module std.webshite.upload.latest.picture 
 gets all the attention while std.reallyhandy is being 
 neglected.
Do you know one or two cases where this phenomenon has happened to a language? Bye, bearophile
Good question! To be honest I cannot put my finger on any module of any language in particular. Maybe Objective-C would be an example where sometimes things would advance at breakneck pace in Cocoa, while some handy features in the standard Objective-C library (e.g. in NSString) would still be missing (but that's years ago now, I haven't used it for a while, so I dunno how it has developed). Java is a good example of how (corporate) ideology (and management) ruins things. Everything is a class, if you don't want this, you create a class and declare static functions to turn off OOP. Well, ... You can see that people are trying to redefine Java, to come up with a better Java. Why is that? Because there is a committee that decides and won't have any criticism. So people say "Hold on, this is not really practicable, let's try something else!", and D already is the something else. What attracts me to D (among other things) is its practical approach. 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.
Nov 22 2013
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:
 On Friday, 22 November 2013 at 14:11:50 UTC, bearophile wrote:
 Chris wrote:

 E.g. one day D might implement features that have to do with 
 what Facebook needs more than features that programmers need 
 in general. So a module std.webshite.upload.latest.picture 
 gets all the attention while std.reallyhandy is being 
 neglected.
Do you know one or two cases where this phenomenon has happened to a language? Bye, bearophile
Good question! To be honest I cannot put my finger on any module of any language in particular. Maybe Objective-C would be an example where sometimes things would advance at breakneck pace in Cocoa, while some handy features in the standard Objective-C library (e.g. in NSString) would still be missing (but that's years ago now, I haven't used it for a while, so I dunno how it has developed). Java is a good example of how (corporate) ideology (and management) ruins things. Everything is a class, if you don't want this, you create a class and declare static functions to turn off OOP. Well, ... You can see that people are trying to redefine Java, to come up with a better Java. Why is that? Because there is a committee that decides and won't have any criticism. So people say "Hold on, this is not really practicable, let's try something else!", and D already is the something else. What attracts me to D (among other things) is its practical approach. 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.
What I'm saying is basically: "D is what happens when you take language design away from the realms of the committee." (http://www.gamedev.net/page/resources/_/technical/general-programming/what-language-do-i-use-r3318) Later it says: "That is to say that D would be the best of all worlds if it gained more support. It simply doesn't yet have the huge libraries of code, wealth of tools, and base of user support of the other languages. Hopefully its support will grow and it will receive the attention it deserves, but that will take some time." The problem is that people flock to languages like Python and Java etc. because of all the tools and libraries. You can easily send an email in Python, download extensions blah blah. But people often confuse "usability" as in libraries & tools with "usability" as in program design (options), robustness and performance.
Nov 22 2013
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:
 On Friday, 22 November 2013 at 14:11:50 UTC, bearophile wrote:
 Chris wrote:

 E.g. one day D might implement features that have to do with 
 what Facebook needs more than features that programmers need 
 in general. So a module std.webshite.upload.latest.picture 
 gets all the attention while std.reallyhandy is being 
 neglected.
Do you know one or two cases where this phenomenon has happened to a language? Bye, bearophile
Good question! To be honest I cannot put my finger on any module of any language in particular. Maybe Objective-C would be an example where sometimes things would advance at breakneck pace in Cocoa, while some handy features in the standard Objective-C library (e.g. in NSString) would still be missing (but that's years ago now, I haven't used it for a while, so I dunno how it has developed). Java is a good example of how (corporate) ideology (and management) ruins things. Everything is a class, if you don't want this, you create a class and declare static functions to turn off OOP.
You know that this comes from the original concept of what OOP is all about and Smalltalk, right? There are no free functions in pure OO languages, like there are no objects in pure FP languages. Of course, meanwhile we have learned there are other ways to do OO, but don't blame Java for Smalltalk concepts. -- Paulo
Nov 22 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 15:31:18 UTC, Paulo Pinto wrote:
 On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:
 On Friday, 22 November 2013 at 14:11:50 UTC, bearophile wrote:
 Chris wrote:

 E.g. one day D might implement features that have to do with 
 what Facebook needs more than features that programmers need 
 in general. So a module std.webshite.upload.latest.picture 
 gets all the attention while std.reallyhandy is being 
 neglected.
Do you know one or two cases where this phenomenon has happened to a language? Bye, bearophile
Good question! To be honest I cannot put my finger on any module of any language in particular. Maybe Objective-C would be an example where sometimes things would advance at breakneck pace in Cocoa, while some handy features in the standard Objective-C library (e.g. in NSString) would still be missing (but that's years ago now, I haven't used it for a while, so I dunno how it has developed). Java is a good example of how (corporate) ideology (and management) ruins things. Everything is a class, if you don't want this, you create a class and declare static functions to turn off OOP.
You know that this comes from the original concept of what OOP is all about and Smalltalk, right? There are no free functions in pure OO languages, like there are no objects in pure FP languages. Of course, meanwhile we have learned there are other ways to do OO, but don't blame Java for Smalltalk concepts. -- Paulo
I don't blame Java for Smalltalk. I just don't like ideological constraints. As you said, we've learned that there are other ways of doing OO, but how can people cling to things when they know they are not good. I can't get my head around it. Same goes for JVM. If you have JIT, why not go all the way and have the _option_ to compile it to machine code?
Nov 22 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 22 November 2013 at 15:36:43 UTC, Chris wrote:
 On Friday, 22 November 2013 at 15:31:18 UTC, Paulo Pinto wrote:
 On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:
 On Friday, 22 November 2013 at 14:11:50 UTC, bearophile wrote:
 Chris wrote:

 E.g. one day D might implement features that have to do 
 with what Facebook needs more than features that 
 programmers need in general. So a module 
 std.webshite.upload.latest.picture gets all the attention 
 while std.reallyhandy is being neglected.
Do you know one or two cases where this phenomenon has happened to a language? Bye, bearophile
Good question! To be honest I cannot put my finger on any module of any language in particular. Maybe Objective-C would be an example where sometimes things would advance at breakneck pace in Cocoa, while some handy features in the standard Objective-C library (e.g. in NSString) would still be missing (but that's years ago now, I haven't used it for a while, so I dunno how it has developed). Java is a good example of how (corporate) ideology (and management) ruins things. Everything is a class, if you don't want this, you create a class and declare static functions to turn off OOP.
You know that this comes from the original concept of what OOP is all about and Smalltalk, right? There are no free functions in pure OO languages, like there are no objects in pure FP languages. Of course, meanwhile we have learned there are other ways to do OO, but don't blame Java for Smalltalk concepts. -- Paulo
I don't blame Java for Smalltalk. I just don't like ideological constraints. As you said, we've learned that there are other ways of doing OO, but how can people cling to things when they know they are not good. I can't get my head around it. Same goes for JVM. If you have JIT, why not go all the way and have the _option_ to compile it to machine code?
Just get Aonix, J9, RoboVM, JET, Jasmine, JikesRVM, just to cite a few examples. There are plenty AOT compilers to chose from for Java. Oracle JVM is not the only JDK around, although people tend to think so. -- Paulo
Nov 22 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 15:40:07 UTC, Paulo Pinto wrote:
 On Friday, 22 November 2013 at 15:36:43 UTC, Chris wrote:
 On Friday, 22 November 2013 at 15:31:18 UTC, Paulo Pinto wrote:
 On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:
 On Friday, 22 November 2013 at 14:11:50 UTC, bearophile 
 wrote:
 Chris wrote:

 E.g. one day D might implement features that have to do 
 with what Facebook needs more than features that 
 programmers need in general. So a module 
 std.webshite.upload.latest.picture gets all the attention 
 while std.reallyhandy is being neglected.
Do you know one or two cases where this phenomenon has happened to a language? Bye, bearophile
Good question! To be honest I cannot put my finger on any module of any language in particular. Maybe Objective-C would be an example where sometimes things would advance at breakneck pace in Cocoa, while some handy features in the standard Objective-C library (e.g. in NSString) would still be missing (but that's years ago now, I haven't used it for a while, so I dunno how it has developed). Java is a good example of how (corporate) ideology (and management) ruins things. Everything is a class, if you don't want this, you create a class and declare static functions to turn off OOP.
You know that this comes from the original concept of what OOP is all about and Smalltalk, right? There are no free functions in pure OO languages, like there are no objects in pure FP languages. Of course, meanwhile we have learned there are other ways to do OO, but don't blame Java for Smalltalk concepts. -- Paulo
I don't blame Java for Smalltalk. I just don't like ideological constraints. As you said, we've learned that there are other ways of doing OO, but how can people cling to things when they know they are not good. I can't get my head around it. Same goes for JVM. If you have JIT, why not go all the way and have the _option_ to compile it to machine code?
Just get Aonix, J9, RoboVM, JET, Jasmine, JikesRVM, just to cite a few examples. There are plenty AOT compilers to chose from for Java. Oracle JVM is not the only JDK around, although people tend to think so. -- Paulo
Which kind of proves my point. There is demand for it. Why not ship Java with a machine code compiler? javac -native MyClass.java
Nov 22 2013
prev sibling next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:
 Java is a good example of how (corporate) ideology (and 
 management) ruins things.
I think you are attributing results to the wrong thing. Go isn't simplistic because of Google corporate management, it is because the creators decided that was what it would be. Java isn't ruined because of the corporation behind it is because of the vision and goals of its creator, which happens to be a corporation. D hasn't become what it is because of a lack of corporate backing, but because its creator decided being influenced by the community would be beneficial.
Nov 22 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 22 November 2013 at 15:36:08 UTC, Jesse Phillips wrote:
 On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:
 Java is a good example of how (corporate) ideology (and 
 management) ruins things.
I think you are attributing results to the wrong thing. Go isn't simplistic because of Google corporate management, it is because the creators decided that was what it would be. Java isn't ruined because of the corporation behind it is because of the vision and goals of its creator, which happens to be a corporation. D hasn't become what it is because of a lack of corporate backing, but because its creator decided being influenced by the community would be beneficial.
Go simplicity is easy to understand once you know the background of language designers. It has Oberon-2 method syntax and the simplicity design advocated by Niklaus Wirth, starting with the Oberon project. Robert Griesemer did part of his studies at ETHZ. Go also has many similarities to Alef (Plan9) and Limbo(Inferno). Projects where Rob Pike and Ken Thompson were part of. -- Paulo
Nov 22 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 22 November 2013 at 15:56:14 UTC, Paulo Pinto wrote:
 background of language designers.
Which just reinforces my point. It is the language designer (creator) which dictates the result of the language. Being a corporation isn't what is going to drive it (much).
Nov 22 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 16:24:25 UTC, Jesse Phillips wrote:
 On Friday, 22 November 2013 at 15:56:14 UTC, Paulo Pinto wrote:
 background of language designers.
Which just reinforces my point. It is the language designer (creator) which dictates the result of the language. Being a corporation isn't what is going to drive it (much).
But being a corporation bars the community from influencing the language design. It reinforces self-righteousness and tunnel vision, committee thinking. And of course the language will go in a direction that suits its application within the corporation (web, gaming and the like). There are just too many things attached to a language developed by a corporation, things that have nothing to do with the language as such. (And don't forget BIG EGOS, we tend to forget that language designers are human beings with all their flaws and shortcomings).
Nov 22 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 22 November 2013 at 16:34:06 UTC, Chris wrote:
 On Friday, 22 November 2013 at 16:24:25 UTC, Jesse Phillips 
 wrote:
 On Friday, 22 November 2013 at 15:56:14 UTC, Paulo Pinto wrote:
 background of language designers.
Which just reinforces my point. It is the language designer (creator) which dictates the result of the language. Being a corporation isn't what is going to drive it (much).
But being a corporation bars the community from influencing the language design.
It doesn't, it is the creator which causes it. I think Go and C# both prove that. Go has corporate backing, but it would be silly to say the design is coming from Google and not the creators (though they claim the community has influence in its direction). C# is IMO a great language which I think is silly to claim had anything but corporate interest driving it.
Nov 22 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 18:11:34 UTC, Jesse Phillips wrote:
 On Friday, 22 November 2013 at 16:34:06 UTC, Chris wrote:
 On Friday, 22 November 2013 at 16:24:25 UTC, Jesse Phillips 
 wrote:
 On Friday, 22 November 2013 at 15:56:14 UTC, Paulo Pinto 
 wrote:
 background of language designers.
Which just reinforces my point. It is the language designer (creator) which dictates the result of the language. Being a corporation isn't what is going to drive it (much).
But being a corporation bars the community from influencing the language design.
It doesn't, it is the creator which causes it. I think Go and C# both prove that. Go has corporate backing, but it would be silly to say the design is coming from Google and not the creators (though they claim the community has influence in its direction). C# is IMO a great language which I think is silly to claim had anything but corporate interest driving it.
I remember the hype around C# when it was claimed that it was better than Java, then D. True or not, I don't like that kind of propaganda. I think it's better if a company uses a language, but the design is done somewhere else.
Nov 22 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Nov 22 2013
parent reply "Chris" <wendlec tcd.ie> writes:
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.
Nov 23 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
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
Nov 23 2013
parent reply "Chris" <wendlec tcd.ie> writes:
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.
Nov 25 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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 ;-)
Nov 25 2013
parent "Chris" <wendlec tcd.ie> writes:
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.
Nov 25 2013
prev sibling parent "Bienlein" <jeti789 web.de> writes:
 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...
Nov 25 2013
prev sibling parent reply "Bienlein" <jeti789 web.de> writes:
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
Nov 28 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/28/13 8:07 AM, Bienlein wrote:
 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.
Interesting. Could you please create a paste with the two code samples? Thanks, Andrei
Nov 28 2013
parent reply "Bienlein" <jeti789 web.de> writes:
On Thursday, 28 November 2013 at 19:22:06 UTC, Andrei 
Alexandrescu wrote:

 Interesting. Could you please create a paste with the two code 
 samples?

 Thanks,

 Andrei
Hello, here is the Go code: package main import ( "fmt" ) type Point struct { x, y int } type Rectangular struct { topLeft, bottomRight Point } func (self Rectangular) Left() int { return self.topLeft.x } func (self Rectangular) Right() int { return self.bottomRight.x } func (self Rectangular) Width() int { return self.Right() - self.Left() } type Rectangle struct { Rectangular } func NewRectangle(topLeft, bottomRight Point) *Rectangle { rectangle := new(Rectangle) rectangle.Rectangular.topLeft = topLeft rectangle.Rectangular.bottomRight = bottomRight return rectangle } func main() { rectangle := NewRectangle(Point{1, 2}, Point{12, 2}) fmt.Println(rectangle.Width()) } And this is the Scala code: import java.awt.Point trait Rectangular { protected val topLeft: Point protected val bottomRight: Point def width : Int = bottomRight.x - topLeft.x } class Rectangle(val topLeft: Point, val bottomRight: Point) extends Rectangular object RunIt extends Application { val rectangle = new Rectangle(new Point(1, 2), new Point(12, 2)) println(rectangle.width) } I guess in D you would do something like this: mixin template Rectangular() { Point x, y; } mixin Rectangular; struct Rectangle { mixin Rectangular; } Note that in the Scala code Rectangular.topLeft and Rectangular.bottomRight are protected. Since the solution in Go makes use of delegation this can only be accomplished in Go through making getters public or defining Rectangle in the same package as Rectangular. Since Go does not have constructors the way to initialize a Rectangle in Go looks more clumsy. An interesting point to me is that Rectangular in Go is just an ordinary struct whereas Rectangular is a special construct in Scala (being a trait) and in D (being a mixin). So Scala and D force you to design ahead, e.g. you have to decide in advance whether to make Rectangular a trait or mixin. Thereafter, Rectangular is not of use on its own, only when used as a trait or mixin. What makes me think is whether delegation as a language construct has been underrated and whether Go now makes this obvious. -- Bienlein
Nov 29 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 29 November 2013 at 08:29:04 UTC, Bienlein wrote:
 On Thursday, 28 November 2013 at 19:22:06 UTC, Andrei 
 Alexandrescu wrote:

 Interesting. Could you please create a paste with the two code 
 samples?

 Thanks,

 Andrei
Hello, here is the Go code: package main import ( "fmt" ) type Point struct { x, y int } type Rectangular struct { topLeft, bottomRight Point } func (self Rectangular) Left() int { return self.topLeft.x } func (self Rectangular) Right() int { return self.bottomRight.x } func (self Rectangular) Width() int { return self.Right() - self.Left() } type Rectangle struct { Rectangular } func NewRectangle(topLeft, bottomRight Point) *Rectangle { rectangle := new(Rectangle) rectangle.Rectangular.topLeft = topLeft rectangle.Rectangular.bottomRight = bottomRight return rectangle } func main() { rectangle := NewRectangle(Point{1, 2}, Point{12, 2}) fmt.Println(rectangle.Width()) } And this is the Scala code: import java.awt.Point trait Rectangular { protected val topLeft: Point protected val bottomRight: Point def width : Int = bottomRight.x - topLeft.x } class Rectangle(val topLeft: Point, val bottomRight: Point) extends Rectangular object RunIt extends Application { val rectangle = new Rectangle(new Point(1, 2), new Point(12, 2)) println(rectangle.width) } I guess in D you would do something like this: mixin template Rectangular() { Point x, y; } mixin Rectangular; struct Rectangle { mixin Rectangular; } Note that in the Scala code Rectangular.topLeft and Rectangular.bottomRight are protected. Since the solution in Go makes use of delegation this can only be accomplished in Go through making getters public or defining Rectangle in the same package as Rectangular. Since Go does not have constructors the way to initialize a Rectangle in Go looks more clumsy. An interesting point to me is that Rectangular in Go is just an ordinary struct whereas Rectangular is a special construct in Scala (being a trait) and in D (being a mixin). So Scala and D force you to design ahead, e.g. you have to decide in advance whether to make Rectangular a trait or mixin. Thereafter, Rectangular is not of use on its own, only when used as a trait or mixin. What makes me think is whether delegation as a language construct has been underrated and whether Go now makes this obvious. -- Bienlein
Thanks for the example. To be honest the Go code looks like a glorified version of JavaScript to me. I think it is way too "obfuscated", and Go syntax seems a bit like someone _always_ wanted to do it differently, just a personal preference, no matter what people intuitively expect.[1] x, y int I prefer left-to-right: "type integer named x (or whatever)", i.e. int x; But why on earth (a []byte)? The type is important, not the name. I can give it any name. a, inComing, inBytes, response, draculaBytes ... [1] Raises the question whether we've been conditioned by C or whether C was intuitive.
Nov 29 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:

 But why on earth (a []byte)? The type is important, not the 
 name. I can give it any name. a, inComing, inBytes, response, 
 draculaBytes ...
I read that type "array of byte(s)", I find it a bit better than D syntax, especially when types become a little more complex. Bye, bearophile
Nov 29 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 29 November 2013 at 12:11:26 UTC, bearophile wrote:
 Chris:

 But why on earth (a []byte)? The type is important, not the 
 name. I can give it any name. a, inComing, inBytes, response, 
 draculaBytes ...
I read that type "array of byte(s)", I find it a bit better than D syntax, especially when types become a little more complex. Bye, bearophile
"byte array named a" vs "a is an array of bytes". Either is fine. I agree that sometimes the latter is better for complex types.
Nov 29 2013
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Fri, 2013-11-29 at 13:11 +0100, bearophile wrote:
 Chris:
 
 But why on earth (a []byte)? The type is important, not the 
 name. I can give it any name. a, inComing, inBytes, response, 
 draculaBytes ...
I read that type "array of byte(s)", I find it a bit better than D syntax, especially when types become a little more complex.
I believe it should be read as "slice of bytes" not "array of bytes". -- 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
Nov 29 2013
prev sibling next sibling parent reply "Bienlein" <jeti789 web.de> writes:
On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote:
 [1] Raises the question whether we've been conditioned by C or 
 whether C was intuitive.
My theory is that Go is from the beginning intended to be a modernized C. If I look at C from that perspective I can always explain why things in Go are the way they are. The syntax is only in part awkward as Go is in some ways inspired by Oberon. But what suprises me is that with a language feature as simple as delegates you can solve so many design problems that well. I wonder whether this is a result of a lot of thought or only a result of adding some language feature that frees you from having to write myStruct1->field1->myStruct2->field2-> ...
Nov 29 2013
parent reply "Chris" <wendlec tcd.ie> writes:
bearophile

I wonder, if it's just the way I've learned how to program that I 
prefer

byte[] buf;

to

buf []byte; // Which seems a bit awkward to me. "it's called 
'buf' and it is an array of ... of what???? Drum roll r-r-r-r-r 
... Of bytes! Yeah!!!

Maybe it's because in my culture we read (and think?) from left 
to right. Mind you, the apple symbol on the Mac is in the upper 
left corner. The "Launcher" in Ubuntu is on the left hand side by 
default. The folders and contacts in Gmail are on the left hand 
side. Your mouse cursor is in the left half of the screen most of 
the time.

On Friday, 29 November 2013 at 12:16:07 UTC, Bienlein wrote:
 On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote:
 [1] Raises the question whether we've been conditioned by C or 
 whether C was intuitive.
My theory is that Go is from the beginning intended to be a modernized C. If I look at C from that perspective I can always explain why things in Go are the way they are. The syntax is only in part awkward as Go is in some ways inspired by Oberon.
Very good point. But do we need to modernize C? C is only one step away form assembly. So if you modernize this, your still on the same level.
 But what suprises me is that with a language feature as simple 
 as delegates you can solve so many design problems that well. I 
 wonder whether this is a result of a lot of thought or only a 
 result of adding some language feature that frees you from 
 having to write myStruct1->field1->myStruct2->field2-> ...
I like structs and classes for the fact that they can handle stuff on their own. But we do have delegation in D and it is a useful feature in Objective-C too. structs/classes and delegation are not mutually exclusive. And your question is very good. Is delegation in Go a "work around" within a limited language or is it a design feature? If Go is modernized C, will it end up like C++?
Nov 29 2013
parent "Bienlein" <jeti789 web.de> writes:
On Friday, 29 November 2013 at 12:53:02 UTC, Chris wrote:

 Very good point. But do we need to modernize C? C is only one 
 step away form assembly. So if you modernize this, your still 
 on the same level.
Agree. If I accept a language that simple then it needs to deliver execution speed. And Go fails in that domain.
 delegation are not mutually exclusive. And your question is 
 very good. Is delegation in Go a "work around" within a limited 
 language or is it a design feature?
The question I ask myself whether delegation is a nglected gross concept. I don't mean 1:1 associations as such, of course, but I mean that you can simply say myStruct1-fieldN instead of myStruct1->field1-> ... myStructN->fieldN.
But we do have delegation in D and it is a useful feature in 
Objective-C too.
Concerning D you mean mixins? Yeah, I wonder why no JVM language has them. On the JVM all languages on a higher level than Java have chosen to go with traits only (Scala, Kotlin). Groovy has the Delegate annotation, but the Groovy compiler doesn't complain in case some diamond problem pops up in your code. So it's not truly for real. With regard to Objective-C you mean the instancesRespondToSelector: thing? But this is some kind of hack. In Go the compiler checks for correctness.
 If Go is modernized C, will it end up like C++?
Well, at least Go is very consistent. No tons of complicated special cases you need to know about. Rust did things very well here. It is made for speed and low memory consumption. The way it adds OO elements to the language is not that minimalistic. I don't see how Go can compete with Java when a company is already using Java as Go runs at about the same speed. They have done concurrency very well with goroutines and channels. Some of the excitement about Go clearly comes from concurrency being well done. They have a tool that can analyse the channels in some Go code and tell you whether a deadlock is inevitably bound to happen. That's not bad. I think Go is more for C or Python people and for Java/.NET people that want to do a little bit of system programming in their spare time. -- Bienlein
Nov 29 2013
prev sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote:
 [1] Raises the question whether we've been conditioned by C or 
 whether C was intuitive.
I'll answer for you: C was very counter intuitive which is why no one has done exactly what it did since. Look up the spiral rule for reading types in C. Most often it can be thought of being read from right to left, but that's not the actual reading. http://c-faq.com/decl/spiral.anderson.html D fixes this massive issue to a certain degree, but it still feels backwards to me, despite me having been raised with "types on the left of the name". After using a language doing it "the right way" for awhile, you quickly adapt and realize it makes the most sense. At least, that's the way that I feel.
Nov 29 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 29 November 2013 at 15:21:26 UTC, Chris Cain wrote:
 On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote:
 [1] Raises the question whether we've been conditioned by C or 
 whether C was intuitive.
I'll answer for you: C was very counter intuitive which is why no one has done exactly what it did since. Look up the spiral rule for reading types in C. Most often it can be thought of being read from right to left, but that's not the actual reading. http://c-faq.com/decl/spiral.anderson.html D fixes this massive issue to a certain degree, but it still feels backwards to me, despite me having been raised with "types on the left of the name". After using a language doing it "the right way" for awhile, you quickly adapt and realize it makes the most sense. At least, that's the way that I feel.
I agree that D, too, can be a bit confusing. I sometimes have problems with AA declarations. Example: string[string][string] hm; // What am I? But I don't think it's the reading direction. I wonder why you would want the variable name first. var omitNewline bool or func (r RepeatByte) Read(p []byte) (n int, err error) or ":=" or "var". _Of course_ it's a variable: bool yes; string answer; For my liking Go code looks too cluttered (pointing out the obvious). But I guess it's just the way you're "brought up" with a language. Maybe I'm a dinosaur.
Nov 29 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Friday, 29 November 2013 at 16:15:10 UTC, Chris wrote:
 I agree that D, too, can be a bit confusing. I sometimes have 
 problems with AA declarations.

 Example:

 string[string][string] hm; // What am I?

 But I don't think it's the reading direction.
Actually it is. D is pretty good about being consistently read backwards (which, as you can tell, is a tiny bit awkward, hence why I think "the other way" is better). hm is an associative array mapping string to another associative array mapping string to string. Pseudocode: hm [string][string]string; How about something *ridiculous* in right-to-left reading: rofl *[string][]*bool; Try to read that before seeing what's below: ----- rofl is a pointer to an associative array mapping strings to arrays of pointers to bools. Very simple and very intuitive. After reading a few things like that you become very comfortable with it.
 I wonder why you would want the variable name first.
It's really irrelevant either way, but it "reads out loud" much better in my experience
 For my liking Go code looks too cluttered (pointing out the 
 obvious). But I guess it's just the way you're "brought up" 
 with a language. Maybe I'm a dinosaur.
I'm not suggesting Go got it perfectly. I've seen a lot of languages that have cleaner declarations, IMO. To be honest, Go looks kind of cluttered in my eyes too. But the right-to-left reading order is something I'm a very strong proponent of. I'm fine with D, however, since you can usually reliably read it backwards. C, however, is a horrific mess.
Nov 30 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2013 1:19 PM, Chris Cain wrote:
 C, however, is a horrific mess.
The trick to reading C declarations is the form matches exactly how it is used in an expression. For example, a function pointer fp: int (*fp)(int); // declare (*fp)(3); // use
Nov 30 2013
parent reply "eles" <eles eles.com> writes:
On Sunday, 1 December 2013 at 06:43:13 UTC, Walter Bright wrote:
 On 11/30/2013 1:19 PM, Chris Cain wrote:
 C, however, is a horrific mess.
The trick to reading C declarations is the form matches exactly how it is used in an expression. For example, a function
They acknowledge that here: http://blog.golang.org/gos-declaration-syntax but they give a nice convoluted counter-example; read this: int (*(*fp)(int (*)(int, int), int))(int, int)
Dec 04 2013
next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Wednesday, 4 December 2013 at 10:33:02 UTC, eles wrote:
 http://blog.golang.org/gos-declaration-syntax

 but they give a nice convoluted counter-example; read this:

 int (*(*fp)(int (*)(int, int), int))(int, int)
Yep. Spiral reading on this: fp is a pointer to a function taking in ( a pointer to a function taking in an int and another int returning an int ) and an int returning a pointer to a function taking in an int and an int returning an int. Although it's an artificially really complex example, it's ridiculous you have to read it in a spiral to understand it.
Dec 04 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 4 December 2013 at 11:12:00 UTC, Chris Cain wrote:
 On Wednesday, 4 December 2013 at 10:33:02 UTC, eles wrote:
 http://blog.golang.org/gos-declaration-syntax

 but they give a nice convoluted counter-example; read this:

 int (*(*fp)(int (*)(int, int), int))(int, int)
Yep. Spiral reading on this: fp is a pointer to a function taking in ( a pointer to a function taking in an int and another int returning an int ) and an int returning a pointer to a function taking in an int and an int returning an int. Although it's an artificially really complex example, it's ridiculous you have to read it in a spiral to understand it.
C's int numbers[]; is really awkward. But I think that D's int[] numbers; is just as clear as Go's right-to-left declaration. I think the problem is not really the reading _direction_ but the reading _logic_ that makes clear what belongs to what. int[] is an array of integers, just as []int is an array of integers. It's clear because it's glued to the type and not to the variable name.
Dec 04 2013
parent "Chris Cain" <clcain uncg.edu> writes:
On Wednesday, 4 December 2013 at 11:23:35 UTC, Chris wrote:
 C's

 int numbers[];

 is really awkward. But I think that D's

 int[] numbers;

 is just as clear as Go's right-to-left declaration. I think the 
 problem is not really the reading _direction_ but the reading 
 _logic_ that makes clear what belongs to what. int[] is an 
 array of integers, just as []int is an array of integers. It's 
 clear because it's glued to the type and not to the variable 
 name.
Yeah. D's is mostly fine on this. I wouldn't at all recommend a change on this (even for D3). I'm just bringing up the point that it's more natural to read "the other way around". And that C's reading is terrible in this regard. I've never had an issue with understanding D's reading (but, that said, C's reading hasn't confused me after I learned the spiral rule, it's just annoyed me).
Dec 04 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/4/2013 2:33 AM, eles wrote:
 On Sunday, 1 December 2013 at 06:43:13 UTC, Walter Bright wrote:
 On 11/30/2013 1:19 PM, Chris Cain wrote:
 C, however, is a horrific mess.
The trick to reading C declarations is the form matches exactly how it is used in an expression. For example, a function
They acknowledge that here: http://blog.golang.org/gos-declaration-syntax but they give a nice convoluted counter-example; read this: int (*(*fp)(int (*)(int, int), int))(int, int)
It's not a counterexample. It's still the same as how you'd use it in an expression.
Dec 04 2013
parent "eles" <eles eles.com> writes:
On Wednesday, 4 December 2013 at 22:11:46 UTC, Walter Bright 
wrote:
 On 12/4/2013 2:33 AM, eles wrote:
 On Sunday, 1 December 2013 at 06:43:13 UTC, Walter Bright 
 wrote:
 On 11/30/2013 1:19 PM, Chris Cain wrote:
 but they give a nice convoluted counter-example; read this:

 int (*(*fp)(int (*)(int, int), int))(int, int)
It's not a counterexample. It's still the same as how you'd use it in an expression.
yes, it is not a counter-example to the C's choice, only to the human capacity to read declarations.
Dec 04 2013
prev sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Saturday, 30 November 2013 at 21:19:15 UTC, Chris Cain wrote:
 On Friday, 29 November 2013 at 16:15:10 UTC, Chris wrote:
 I agree that D, too, can be a bit confusing. I sometimes have 
 problems with AA declarations.

 Example:

 string[string][string] hm; // What am I?
string[string][string] hm; The result is a string, obtained through associative array with key string, obtained through associative array with key string which is located at hm.
 How about something *ridiculous* in right-to-left reading:

 rofl *[string][]*bool;
bool*[][string]* rofl; The result is bool, through a pointer, stored in an array, obtained through associative array with key of string, stored in array, and all pointeded to from a location rofl. It really doesn't matter to me, but I'm not use to Go's backward style so I prefer D's choice.
Dec 02 2013
next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Monday, 2 December 2013 at 21:33:19 UTC, Jesse Phillips wrote:
 The result is a string, obtained through associative array with 
 key string, obtained through associative array with key string 
 which is located at hm.
...
 The result is bool, through a pointer, stored in an array, 
 obtained through associative array with key of string, stored 
 in array, and all pointeded to from a location rofl.
Maybe it's just me, but if you said that (or wrote that) without the code I wouldn't have the beginnings of understanding what you were talking about.
Dec 02 2013
parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 3 December 2013 at 00:24:08 UTC, Chris Cain wrote:
 On Monday, 2 December 2013 at 21:33:19 UTC, Jesse Phillips 
 wrote:
 The result is a string, obtained through associative array 
 with key string, obtained through associative array with key 
 string which is located at hm.
...
 The result is bool, through a pointer, stored in an array, 
 obtained through associative array with key of string, stored 
 in array, and all pointeded to from a location rofl.
Maybe it's just me, but if you said that (or wrote that) without the code I wouldn't have the beginnings of understanding what you were talking about.
Thats ok, I can say the same thing about what you wrote. There are just too many details to keep in my head, so a nice succinct syntax is greatly appreciated. IMO English isn't the language to use for these complex descriptions e.g.[1]. 1. http://stackoverflow.com/questions/264309/why-do-people-defend-the-regex-syntax/264384#264384
Dec 02 2013
prev sibling parent "eles" <eles eles.com> writes:
On Monday, 2 December 2013 at 21:33:19 UTC, Jesse Phillips wrote:
 On Saturday, 30 November 2013 at 21:19:15 UTC, Chris Cain wrote:
 On Friday, 29 November 2013 at 16:15:10 UTC, Chris wrote:
 I agree that D, too, can be a bit confusing. I sometimes have 
 problems with AA declarations.

 Example:

 string[string][string] hm; // What am I?
string[string][string] hm; The result is a string, obtained through associative array with key string, obtained through associative array with key string which is located at hm.
 How about something *ridiculous* in right-to-left reading:

 rofl *[string][]*bool;
bool*[][string]* rofl; The result is bool, through a pointer, stored in an array, obtained through associative array with key of string, stored in array, and all pointeded to from a location rofl.
For the record, this is the idea behind the Go's declaration syntax: http://blog.golang.org/gos-declaration-syntax I liked their idea about declaring left-to-right, but using right-to-left (that is the distinction between type syntax and expression syntax). Shame that they didn't make the right choice for the pointer syntax.
Dec 04 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-29 09:29, Bienlein wrote:
 On Thursday, 28 November 2013 at 19:22:06 UTC, Andrei Alexandrescu wrote:

 Interesting. Could you please create a paste with the two code samples?

 Thanks,

 Andrei
Hello, here is the Go code: package main import ( "fmt" ) type Point struct { x, y int } type Rectangular struct { topLeft, bottomRight Point } func (self Rectangular) Left() int { return self.topLeft.x } func (self Rectangular) Right() int { return self.bottomRight.x } func (self Rectangular) Width() int { return self.Right() - self.Left() } type Rectangle struct { Rectangular } func NewRectangle(topLeft, bottomRight Point) *Rectangle { rectangle := new(Rectangle) rectangle.Rectangular.topLeft = topLeft rectangle.Rectangular.bottomRight = bottomRight return rectangle } func main() { rectangle := NewRectangle(Point{1, 2}, Point{12, 2}) fmt.Println(rectangle.Width()) } And this is the Scala code: import java.awt.Point trait Rectangular { protected val topLeft: Point protected val bottomRight: Point def width : Int = bottomRight.x - topLeft.x } class Rectangle(val topLeft: Point, val bottomRight: Point) extends Rectangular object RunIt extends Application { val rectangle = new Rectangle(new Point(1, 2), new Point(12, 2)) println(rectangle.width) } I guess in D you would do something like this: mixin template Rectangular() { Point x, y; } mixin Rectangular; struct Rectangle { mixin Rectangular; } Note that in the Scala code Rectangular.topLeft and Rectangular.bottomRight are protected. Since the solution in Go makes use of delegation this can only be accomplished in Go through making getters public or defining Rectangle in the same package as Rectangular. Since Go does not have constructors the way to initialize a Rectangle in Go looks more clumsy. An interesting point to me is that Rectangular in Go is just an ordinary struct whereas Rectangular is a special construct in Scala (being a trait) and in D (being a mixin). So Scala and D force you to design ahead, e.g. you have to decide in advance whether to make Rectangular a trait or mixin. Thereafter, Rectangular is not of use on its own, only when used as a trait or mixin. What makes me think is whether delegation as a language construct has been underrated and whether Go now makes this obvious.
You can do the exact thing in D with the help of UFCS. BTW, you need to decide in advance if you should use a class or a struct in D. That's basically the same thing as choosing if you need a template. -- /Jacob Carlborg
Nov 29 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2013 12:29 AM, Bienlein wrote:
 I guess in D you would do something like this:

 mixin template Rectangular() {
    Point x, y;
 }

 mixin Rectangular;

 struct Rectangle {
    mixin Rectangular;
 }
It's easier than that: struct Rectangular { Point x,y; } struct Rectangular { Rectangle rectangle; alias this rectangle; }
Nov 30 2013
next sibling parent reply "Bienlein" <jeti789 web.de> writes:
On Saturday, 30 November 2013 at 18:16:23 UTC, Walter Bright 
wrote:
 On 11/29/2013 12:29 AM, Bienlein wrote:
 I guess in D you would do something like this:

 mixin template Rectangular() {
   Point x, y;
 }

 mixin Rectangular;

 struct Rectangle {
   mixin Rectangular;
 }
It's easier than that: struct Rectangular { Point x,y; } struct Rectangular { Rectangle rectangle; alias this rectangle; }
D is always full of surprises ;-). Now the only feature in Go that sets it apart from other languages is CSP. I got this to work with help from the book by Ali Çehreli: struct Point { int x,y; } struct Rectangular { Point x,y; } struct Rectangle { Rectangular rectangular; Rectangular rect() const { return rectangular; } alias rect this; } void main(string[] args) { Rectangle rectangle = Rectangle(); rectangle.x = Point(); }
Nov 30 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2013 12:36 PM, Bienlein wrote:
 D is always full of surprises ;-).
The syntax for alias this is a bit off-putting to me, but it works great.
Nov 30 2013
prev sibling next sibling parent reply "Bienlein" <jeti789 web.de> writes:
On Saturday, 30 November 2013 at 18:16:23 UTC, Walter Bright
wrote:

 It's easier than that:

 struct Rectangular {
     Point x,y;
 }

 struct Rectangular {
     Rectangle rectangle;
     alias this rectangle;
 }
Are there any plans so that you can have multiple aliases per struct/class? That would be really awesome :-).
Dec 02 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 02, 2013 at 05:12:47PM +0100, Bienlein wrote:
 On Saturday, 30 November 2013 at 18:16:23 UTC, Walter Bright
 wrote:
 
It's easier than that:

struct Rectangular {
    Point x,y;
}

struct Rectangular {
    Rectangle rectangle;
    alias this rectangle;
}
Are there any plans so that you can have multiple aliases per struct/class? That would be really awesome :-).
+1. Can we have multiple alias this? Pretty please? :) T -- A mathematician is a device for turning coffee into theorems. -- P. Erdos
Dec 02 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:
 +1. Can we have multiple alias this? Pretty please? :)
It think it is all about "pretty pulls please" ;)
Dec 02 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 02, 2013 at 05:34:12PM +0100, Dicebot wrote:
 On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:
+1. Can we have multiple alias this? Pretty please? :)
It think it is all about "pretty pulls please" ;)
I know, I know... I just need to find the time to sit down and dig into the dmd code. Unfortunately, unlike Phobos where the code is easy to understand (thanks to being written in D), the dmd code is harder. Well, that, and I just haven't had the time to look over it more carefully. OTOH, there's also the temptation to wait until we've bootstrapped dmd into D, so that I can work with D source code instead of C++. :) T -- Guns don't kill people. Bullets do.
Dec 02 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.208.1386005781.3242.digitalmars-d puremagic.com...
 On Mon, Dec 02, 2013 at 05:34:12PM +0100, Dicebot wrote:
 On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:
+1. Can we have multiple alias this? Pretty please? :)
It think it is all about "pretty pulls please" ;)
I know, I know... I just need to find the time to sit down and dig into the dmd code. Unfortunately, unlike Phobos where the code is easy to understand (thanks to being written in D), the dmd code is harder. Well, that, and I just haven't had the time to look over it more carefully. OTOH, there's also the temptation to wait until we've bootstrapped dmd into D, so that I can work with D source code instead of C++. :)
The D version is automatically generated from the C++ version, so time spent learning the C++ code would not be wasted.
Dec 02 2013
parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-12-03 03:33:32 +0000, Daniel Murphy said:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.208.1386005781.3242.digitalmars-d puremagic.com...
 On Mon, Dec 02, 2013 at 05:34:12PM +0100, Dicebot wrote:
 On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:
 +1. Can we have multiple alias this? Pretty please? :)
It think it is all about "pretty pulls please" ;)
I know, I know... I just need to find the time to sit down and dig into the dmd code. Unfortunately, unlike Phobos where the code is easy to understand (thanks to being written in D), the dmd code is harder. Well, that, and I just haven't had the time to look over it more carefully. OTOH, there's also the temptation to wait until we've bootstrapped dmd into D, so that I can work with D source code instead of C++. :)
The D version is automatically generated from the C++ version, so time spent learning the C++ code would not be wasted.
Please tell me more. Is this actually happening? Where's it at?
Dec 03 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Shammah Chancellor" <anonymous coward.com> wrote in message 
news:l7lrsm$2s0c$1 digitalmars.com...
 On 2013-12-03 03:33:32 +0000, Daniel Murphy said:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.208.1386005781.3242.digitalmars-d puremagic.com...
 On Mon, Dec 02, 2013 at 05:34:12PM +0100, Dicebot wrote:
 On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:
 +1. Can we have multiple alias this? Pretty please? :)
It think it is all about "pretty pulls please" ;)
I know, I know... I just need to find the time to sit down and dig into the dmd code. Unfortunately, unlike Phobos where the code is easy to understand (thanks to being written in D), the dmd code is harder. Well, that, and I just haven't had the time to look over it more carefully. OTOH, there's also the temptation to wait until we've bootstrapped dmd into D, so that I can work with D source code instead of C++. :)
The D version is automatically generated from the C++ version, so time spent learning the C++ code would not be wasted.
Please tell me more. Is this actually happening? Where's it at?
Yeah. See: http://forum.dlang.org/post/khkst4$13ad$1 digitalmars.com http://forum.dlang.org/post/jqvduhyvfufpzovpyqbj forum.dlang.org Patches against dmd: https://github.com/D-Programming-Language/dmd/pull/1980 Converter tool: https://github.com/yebblies/magicport2 Pull requests marked DDMD: https://github.com/D-Programming-Language/dmd/pulls/yebblies
Dec 03 2013
parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-12-04 03:19:45 +0000, Daniel Murphy said:

 "Shammah Chancellor" <anonymous coward.com> wrote in message 
 news:l7lrsm$2s0c$1 digitalmars.com...
 On 2013-12-03 03:33:32 +0000, Daniel Murphy said:
 
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.208.1386005781.3242.digitalmars-d puremagic.com...
 On Mon, Dec 02, 2013 at 05:34:12PM +0100, Dicebot wrote:
 On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:
 +1. Can we have multiple alias this? Pretty please? :)
It think it is all about "pretty pulls please" ;)
I know, I know... I just need to find the time to sit down and dig into the dmd code. Unfortunately, unlike Phobos where the code is easy to understand (thanks to being written in D), the dmd code is harder. Well, that, and I just haven't had the time to look over it more carefully. OTOH, there's also the temptation to wait until we've bootstrapped dmd into D, so that I can work with D source code instead of C++. :)
The D version is automatically generated from the C++ version, so time spent learning the C++ code would not be wasted.
Please tell me more. Is this actually happening? Where's it at?
Yeah. See: http://forum.dlang.org/post/khkst4$13ad$1 digitalmars.com http://forum.dlang.org/post/jqvduhyvfufpzovpyqbj forum.dlang.org Patches against dmd: https://github.com/D-Programming-Language/dmd/pull/1980 Converter tool: https://github.com/yebblies/magicport2 Pull requests marked DDMD: https://github.com/D-Programming-Language/dmd/pulls/yebblies
This is AWESOME!!!! Keep up the good work. Can't wait to see how the DMD frontend performs in D. With the version, is there any chance of LLVM being the default backend -- or is Walter opposed to that? -Shammah
Dec 04 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/4/2013 4:16 AM, Shammah Chancellor wrote:
 With the version, is there any chance of LLVM being the default backend -- or
is
 Walter opposed to that?
I'm opposed to it. For one example, a year ago I had to make dmd work on Win64. LLVM didn't support Win64. I would have been stymied. It is very good for D to have 3 equivalent implementations - dmd, gdc, and ldc. Each has its strengths and weaknesses. It makes for a very strong ecosystem.
Dec 04 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-04 23:14, Walter Bright wrote:

 For one example, a year ago I had to make dmd work on Win64. LLVM didn't
 support Win64. I would have been stymied.
The answer to that would be: contribute that implementation to LLVM. But I know you're opposed to that as well. If they don't accept the contributions, use a fork. -- /Jacob Carlborg
Dec 05 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/5/2013 12:11 AM, Jacob Carlborg wrote:
 On 2013-12-04 23:14, Walter Bright wrote:

 For one example, a year ago I had to make dmd work on Win64. LLVM didn't
 support Win64. I would have been stymied.
The answer to that would be: contribute that implementation to LLVM. But I know you're opposed to that as well. If they don't accept the contributions, use a fork.
Easy to say, but doing Win64 was a major effort: 1. bizarre function calling conventions 2. undocumented symbolic debug info format 3. new object file format Making such changes on a backend without thoroughly understanding how the backend works would be quite a challenge. I seriously doubt anyone could have done that on the tight schedule I was under. Besides, forking LLVM subverts most of the advantages of using it.
Dec 05 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-12-06 03:02, Walter Bright wrote:

 Easy to say, but doing Win64 was a major effort:

 1. bizarre function calling conventions

 2. undocumented symbolic debug info format

 3. new object file format

 Making such changes on a backend without thoroughly understanding how
 the backend works would be quite a challenge. I seriously doubt anyone
 could have done that on the tight schedule I was under.
Yes, I understand that. Hopefully you wouldn't have moved to LLVM and at the same time implement Win64. Meaning that hopefully you would have had better knowledge about the LLVM source code when starting with Win64.
 Besides, forking LLVM subverts most of the advantages of using it.
Just fold in the changes from upstream. Yes, I know that won't be as easy as having the code merged with upstream. -- /Jacob Carlborg
Dec 05 2013
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 04/12/13 23:14, Walter Bright wrote:
 I'm opposed to it.

 For one example, a year ago I had to make dmd work on Win64. LLVM didn't
support
 Win64. I would have been stymied.

 It is very good for D to have 3 equivalent implementations - dmd, gdc, and ldc.
 Each has its strengths and weaknesses. It makes for a very strong ecosystem.
The problem we have is that while all 3 implementations are equivalent, some implementations are more equivalent than others ... :-) Sometimes this can be a downstream problem -- people testing code with DMD but not LDC or GDC, so bugs or issues don't get recognized (or they do, but the bugs don't get reported to the compiler teams). But more fundamentally, it's that if you're running git-HEAD DMD, you're running the very latest code, whereas if you're running git-HEAD LDC or GDC, you're still running only the latest stable frontend/runtime/standard library releases. So, that means that if you need the ability to get fast turnaround on bugfixes or new features, you HAVE to run DMD. That really seems a constraint that we ought to be free of.
Dec 06 2013
next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Friday, 6 December 2013 at 12:13:28 UTC, Joseph Rushton 
Wakeling wrote:
 On 04/12/13 23:14, Walter Bright wrote:
 I'm opposed to it.

 For one example, a year ago I had to make dmd work on Win64. 
 LLVM didn't support
 Win64. I would have been stymied.

 It is very good for D to have 3 equivalent implementations - 
 dmd, gdc, and ldc.
 Each has its strengths and weaknesses. It makes for a very 
 strong ecosystem.
The problem we have is that while all 3 implementations are equivalent, some implementations are more equivalent than others ... :-) Sometimes this can be a downstream problem -- people testing code with DMD but not LDC or GDC, so bugs or issues don't get recognized (or they do, but the bugs don't get reported to the compiler teams). But more fundamentally, it's that if you're running git-HEAD DMD, you're running the very latest code, whereas if you're running git-HEAD LDC or GDC, you're still running only the latest stable frontend/runtime/standard library releases. So, that means that if you need the ability to get fast turnaround on bugfixes or new features, you HAVE to run DMD. That really seems a constraint that we ought to be free of.
But is D not still doing a better job than Microsoft is of keeping their C++ compiler up to the latest C++ standard? In fact in the C++ world all the compilers lag the standard to some extent. Its hard to expect that D would have all the compilers exactly in sync, though with the common front-end it should help.
Dec 06 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 06/12/13 13:38, Craig Dillabaugh wrote:
 But is D not still doing a better job than Microsoft is of keeping their C++
 compiler up to the latest C++ standard?
I'm not making any comparisons here, I'm simply saying that this is something it could be helpful to address, for D's own sake. Comparisons to Microsoft are not very helpful anyway, because Microsoft is to a great extent in the position of being able to effectively dictate solutions, even where they clash with or fail to live up to standards. That's both their advantage and their weakness.
 In fact in the C++ world all the compilers lag the standard to some extent. Its
 hard to expect that D would have all the compilers exactly in sync, though with
 the common front-end it should help.
That's the point -- with D we are in the lucky situation that not only do all our compilers share common frontends, runtimes and standard libraries, but all the developers are friends working together in a cooperative community. We have all the resources in place to ensure that the 3 compilers are truly equal players. All it will take is time and effort and a focus on making it happen. I should add that (since bounties have been mentioned) this is another thing I'd happily put money towards, if it would help.
Dec 06 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 6 December 2013 at 14:33:59 UTC, Joseph Rushton 
Wakeling wrote:
 On 06/12/13 13:38, Craig Dillabaugh wrote:
 But is D not still doing a better job than Microsoft is of 
 keeping their C++
 compiler up to the latest C++ standard?
I'm not making any comparisons here, I'm simply saying that this is something it could be helpful to address, for D's own sake. Comparisons to Microsoft are not very helpful anyway, because Microsoft is to a great extent in the position of being able to effectively dictate solutions, even where they clash with or fail to live up to standards. That's both their advantage and their weakness.
 In fact in the C++ world all the compilers lag the standard to 
 some extent. Its
 hard to expect that D would have all the compilers exactly in 
 sync, though with
 the common front-end it should help.
That's the point -- with D we are in the lucky situation that not only do all our compilers share common frontends, runtimes and standard libraries,
 but all the developers are friends working together in a 
 cooperative community.
Shhhhhhhhhhhhhhhhhhhhhh! Don't tell anyone!
 We have all the resources in place to ensure that the 3 
 compilers are truly equal players.  All it will take is time 
 and effort and a focus on making it happen.

 I should add that (since bounties have been mentioned) this is 
 another thing I'd happily put money towards, if it would help.
Dec 06 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/6/2013 4:13 AM, Joseph Rushton Wakeling wrote:
 So, that means that if you need the ability to get fast turnaround on bugfixes
 or new features, you HAVE to run DMD.
Or, you could contribute to the gdc and ldc projects!
Dec 12 2013
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Thursday, 12 December 2013 at 22:46:26 UTC, Walter Bright 
wrote:
 On 12/6/2013 4:13 AM, Joseph Rushton Wakeling wrote:
 So, that means that if you need the ability to get fast 
 turnaround on bugfixes
 or new features, you HAVE to run DMD.
Or, you could contribute to the gdc and ldc projects!
Well, when I first contributed to Phobos I looked into getting the same patches accepted into GDC, not least because I wanted the functionality for my own work. It wasn't really a workable thing to do, both because of the lack of common git history and because GDC (as LDC) works by matching the features of the current stable release -- so adding stuff only available via git-HEAD Phobos wasn't really an option. That situation would be much different if the frontend were truly common across all backends.
Dec 12 2013
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 12 December 2013 23:01, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On Thursday, 12 December 2013 at 22:46:26 UTC, Walter Bright wrote:
 On 12/6/2013 4:13 AM, Joseph Rushton Wakeling wrote:
 So, that means that if you need the ability to get fast turnaround on
 bugfixes
 or new features, you HAVE to run DMD.
Or, you could contribute to the gdc and ldc projects!
Well, when I first contributed to Phobos I looked into getting the same patches accepted into GDC, not least because I wanted the functionality for my own work. It wasn't really a workable thing to do, both because of the lack of common git history and because GDC (as LDC) works by matching the features of the current stable release -- so adding stuff only available via git-HEAD Phobos wasn't really an option.
Well patches that go into phobos will soon hit gdc (eventually) - and there's nothing wrong with cherry picking much needed patches prior to release, if you can't wait 6 months for the next release and your bug to be fixed. Of course, what you can't guarantee is if fixing a bug in phobos has some dependency on semantic changes/but fixed in the frontend.
 That situation would be much different if the frontend were truly common
 across all backends.
It's not too bad nowadays, I'll update the differences list sometime today, but the only notable differences now between the two are: https://github.com/D-Programming-Language/dmd/pull/2694 https://github.com/D-Programming-Language/dmd/pull/2200 https://github.com/D-Programming-Language/dmd/pull/2176 Where unless #2694 is applied, gdc will FTBFS. And unless #2200 and #2176 are applied, gdc will ICE when compiling certain code. Regards Iain.
Dec 13 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Iain Buclaw" <ibuclaw gdcproject.org> wrote in message 
news:mailman.525.1386923049.3242.digitalmars-d puremagic.com...
 On 12 December 2013 23:01, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:
 On Thursday, 12 December 2013 at 22:46:26 UTC, Walter Bright wrote:
 On 12/6/2013 4:13 AM, Joseph Rushton Wakeling wrote:
 So, that means that if you need the ability to get fast turnaround on
 bugfixes
 or new features, you HAVE to run DMD.
Or, you could contribute to the gdc and ldc projects!
Well, when I first contributed to Phobos I looked into getting the same patches accepted into GDC, not least because I wanted the functionality for my own work. It wasn't really a workable thing to do, both because of the lack of common git history and because GDC (as LDC) works by matching the features of the current stable release -- so adding stuff only available via git-HEAD Phobos wasn't really an option.
Well patches that go into phobos will soon hit gdc (eventually) - and there's nothing wrong with cherry picking much needed patches prior to release, if you can't wait 6 months for the next release and your bug to be fixed. Of course, what you can't guarantee is if fixing a bug in phobos has some dependency on semantic changes/but fixed in the frontend.
 That situation would be much different if the frontend were truly common
 across all backends.
It's not too bad nowadays, I'll update the differences list sometime today, but the only notable differences now between the two are: https://github.com/D-Programming-Language/dmd/pull/2694 https://github.com/D-Programming-Language/dmd/pull/2200 https://github.com/D-Programming-Language/dmd/pull/2176 Where unless #2694 is applied, gdc will FTBFS. And unless #2200 and #2176 are applied, gdc will ICE when compiling certain code. Regards Iain.
Well, you know how I feel about 2594. If you merge that ddmd will FTBFS.
Dec 13 2013
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 13 December 2013 11:11, Daniel Murphy <yebblies nospamgmail.com> wrote:
 "Iain Buclaw" <ibuclaw gdcproject.org> wrote in message
 news:mailman.525.1386923049.3242.digitalmars-d puremagic.com...
 On 12 December 2013 23:01, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:
 On Thursday, 12 December 2013 at 22:46:26 UTC, Walter Bright wrote:
 On 12/6/2013 4:13 AM, Joseph Rushton Wakeling wrote:
 So, that means that if you need the ability to get fast turnaround on
 bugfixes
 or new features, you HAVE to run DMD.
Or, you could contribute to the gdc and ldc projects!
Well, when I first contributed to Phobos I looked into getting the same patches accepted into GDC, not least because I wanted the functionality for my own work. It wasn't really a workable thing to do, both because of the lack of common git history and because GDC (as LDC) works by matching the features of the current stable release -- so adding stuff only available via git-HEAD Phobos wasn't really an option.
Well patches that go into phobos will soon hit gdc (eventually) - and there's nothing wrong with cherry picking much needed patches prior to release, if you can't wait 6 months for the next release and your bug to be fixed. Of course, what you can't guarantee is if fixing a bug in phobos has some dependency on semantic changes/but fixed in the frontend.
 That situation would be much different if the frontend were truly common
 across all backends.
It's not too bad nowadays, I'll update the differences list sometime today, but the only notable differences now between the two are: https://github.com/D-Programming-Language/dmd/pull/2694 https://github.com/D-Programming-Language/dmd/pull/2200 https://github.com/D-Programming-Language/dmd/pull/2176 Where unless #2694 is applied, gdc will FTBFS. And unless #2200 and #2176 are applied, gdc will ICE when compiling certain code. Regards Iain.
Well, you know how I feel about 2594. If you merge that ddmd will FTBFS.
Yeah, it's my fault really. I should have foresaw how the change would have affected me *before* I hit merge. Curse you hindsight! :o)
Dec 13 2013
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Shammah Chancellor" <anonymous coward.com> wrote in message 
news:l7n6fh$16s0$1 digitalmars.com...
 Yeah.  See:
 http://forum.dlang.org/post/khkst4$13ad$1 digitalmars.com
 http://forum.dlang.org/post/jqvduhyvfufpzovpyqbj forum.dlang.org

 Patches against dmd: 
 https://github.com/D-Programming-Language/dmd/pull/1980
 Converter tool: https://github.com/yebblies/magicport2
 Pull requests marked DDMD: 
 https://github.com/D-Programming-Language/dmd/pulls/yebblies
This is AWESOME!!!! Keep up the good work. Can't wait to see how the DMD frontend performs in D.
From a quick test, compiling ddmd with ddmd takes about 80% longer than compiling ddmd with c++dmd. I suspect a lot of this is from not using the tuned allocator from the C++ version.
 With the version, is there any chance of LLVM being the default backend --  
 or is Walter opposed to that?
As Walter said, there is no chance of that happening. However, we are slowly working to integrate or refactor away all gdc/ldc patches against the frontend. This should greatly reduce the effort to merge patches, hopefully resulting in all three compilers permanently being in sync.
Dec 04 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Dec 05, 2013 at 02:08:34PM +1100, Daniel Murphy wrote:
 "Shammah Chancellor" <anonymous coward.com> wrote in message 
 news:l7n6fh$16s0$1 digitalmars.com...
[...]
 With the version, is there any chance of LLVM being the default
 backend --  or is Walter opposed to that?
As Walter said, there is no chance of that happening. However, we are slowly working to integrate or refactor away all gdc/ldc patches against the frontend. This should greatly reduce the effort to merge patches, hopefully resulting in all three compilers permanently being in sync.
I'm looking forward to that. Recently I've been working on a compute-intensive program, and I've been hoping to test it with gdc to get maximal performance, but since I developed the code mainly with dmd git HEAD, it doesn't compile with gdc, which is rather frustrating. It would be great if the three compilers are always in sync -- if gdc could, for example, just pull straight from DFE git HEAD and Just Work(tm). T -- "The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."
Dec 04 2013
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 05/12/13 04:08, Daniel Murphy wrote:
 As Walter said, there is no chance of that happening.  However, we are
 slowly working to integrate or refactor away all gdc/ldc patches against the
 frontend.  This should greatly reduce the effort to merge patches, hopefully
 resulting in all three compilers permanently being in sync.
.... just as I brought the topic up in another branch of this thread [*] ... :-) How are things going with that, what's the current status in terms of GDC/LDC patches being eliminated? Do you have any idea of the timeframe within which it'll be complete, and does it rely at all on the C++ --> D transition? [* I'm not sure this mix of metaphors really works.]
Dec 06 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> wrote in message 
news:mailman.304.1386341329.3242.digitalmars-d puremagic.com...
 On 05/12/13 04:08, Daniel Murphy wrote:
 As Walter said, there is no chance of that happening.  However, we are
 slowly working to integrate or refactor away all gdc/ldc patches against 
 the
 frontend.  This should greatly reduce the effort to merge patches, 
 hopefully
 resulting in all three compilers permanently being in sync.
.... just as I brought the topic up in another branch of this thread [*] ... :-) How are things going with that, what's the current status in terms of GDC/LDC patches being eliminated? Do you have any idea of the timeframe within which it'll be complete, and does it rely at all on the C++ --> D transition?
It's going very slowly. There have been a few pulls working on some areas, but most of my effort has been on the d port. The frontend unification does not depend on the D port, and the D port is not technically blocked by it, but we will need to finish it before abandoning the C++ version of the frontend. I'd love to give a timeframe, but I don't have that much control over it. A fairly important step is currently blocked because Walter is sitting on a pull request. (https://github.com/D-Programming-Language/dmd/pull/2754)
Dec 06 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 06/12/13 16:37, Daniel Murphy wrote:
 It's going very slowly.  There have been a few pulls working on some areas,
 but most of my effort has been on the d port.  The frontend unification does
 not depend on the D port, and the D port is not technically blocked by it,
 but we will need to finish it before abandoning the C++ version of the
 frontend.
OK, clear. It's kind of what I'd expected; I'm glad to see that it's planned as a precursor to the D transition rather than something to take place as part of it.
 I'd love to give a timeframe, but I don't have that much control over it.  A
 fairly important step is currently blocked because Walter is sitting on a
 pull request. (https://github.com/D-Programming-Language/dmd/pull/2754)
That's a shame though I guess somewhat inevitable given that we're talking about quite significant changes. Is there a documented TODO list anywhere? And is there anything that those of us not contributing frontend code can do to help? (No, not spamming Walter with "Please look at Pull Request 2754!" messages:-)
Dec 06 2013
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> wrote in message 
news:mailman.307.1386345047.3242.digitalmars-d puremagic.com...
 On 06/12/13 16:37, Daniel Murphy wrote:

 Is there a documented TODO list anywhere?  And is there anything that 
 those of us not contributing frontend code can do to help?  (No, not 
 spamming Walter with "Please look at Pull Request 2754!" messages:-)
The TODO list is basically the diff between dmd's and ldc/gdc's frontends. I don't know of anything to do outside of the code, this is pretty much an internal refactoring and shouldn't have any visible effects on anything else.
Dec 10 2013
prev sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Saturday, 30 November 2013 at 18:16:23 UTC, Walter Bright 
wrote:
 It's easier than that:

 struct Rectangular {
     Point x,y;
 }

 struct Rectangular {
     Rectangle rectangle;
     alias this rectangle;
 }
The other day in IRC I asked about the transition to the newer alias X = Type syntax (I would love to see it everywhere!), and someone was saying that the "alias this" syntax always tripped him, because the name misleadingly suggests that the 'this' comes after the 'alias'. I guess it trips everybody :-)
Dec 05 2013
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 28 November 2013 at 16:07:47 UTC, Bienlein wrote:
 ...
 -- Bienlein
IMHO, problem with go simplicity is not as much as being not expressive enough to do something as with being forced to move lot of things to run-time. Which is not actually a problem for many applications but very discouraging for certain type of programmers.
Nov 28 2013
parent reply "Bienlein" <jeti789 web.de> writes:
On Thursday, 28 November 2013 at 19:25:56 UTC, Dicebot wrote:
 On Thursday, 28 November 2013 at 16:07:47 UTC, Bienlein wrote:
 ...
 -- Bienlein
IMHO, problem with go simplicity is not as much as being not expressive enough to do something as with being forced to move lot of things to run-time.
Could you just quickly describe what you mean by "being forced to move lot of things to run-time"? I simply don't see what you are refering to. Thanks.
Nov 29 2013
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 29 November 2013 at 08:35:58 UTC, Bienlein wrote:
 Could you just quickly describe what you mean by "being forced 
 to move
 lot of things to run-time"? I simply don't see what you are 
 refering to.
For example the dreaded generics issue. You can workaround it in many cases by using common polymorphic storage types but it costs. Or some applications of declarative programming in D - one can avoid using reflection and just move base data to runtime values but that requires to do processing during runtime. In your Rectangular example the difference will start to appear when one wants to express a function that accepts any Rectangular type. As far as I know, in Go only option uses fat pointer. In D you can also express it as template constrain and thus can make more finely tuned design decision.
Nov 29 2013
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 13:22:10 UTC, Chris wrote:
 On Friday, 22 November 2013 at 12:34:23 UTC, Joseph Rushton 
 Wakeling wrote:
 On Friday, 22 November 2013 at 10:29:35 UTC, Chris wrote:
 Yes, yes, yes. You are of course right that corporate backing 
 gives a language a boost, even if it's a mediocre language. 
 But as soon as corporate thinking comes into a language 
 (profit, ideology, branding, hype and whatnot), it's doomed. 
 D has to breathe, and I admire all the people who have made D 
 happen, and who are making it happen. I've learned a lot just 
 by listening (well, reading).
You're talking about corporate _management_ rather than corporate backing. The former can obviously lead to problems (though it doesn't have to) -- the latter is almost invariably good, as it means there's someone who can serve as guarantor that any necessary work will get done.
You cannot separate the two. Management will creep into development sooner or later. E.g. one day D might implement features that have to do with what Facebook needs more than features that programmers need in general. So a module std.webshite.upload.latest.picture gets all the attention while std.reallyhandy is being neglected.
To be clear, this doesn't mean that this is happening, it's not, and it is good that Facebook now uses D. But the two should be separate. What D does should not be influenced by any company.
Nov 22 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/22/13 9:38 AM, Chris wrote:
 On Friday, 22 November 2013 at 13:22:10 UTC, Chris wrote:
 On Friday, 22 November 2013 at 12:34:23 UTC, Joseph Rushton Wakeling
 wrote:
 On Friday, 22 November 2013 at 10:29:35 UTC, Chris wrote:
 Yes, yes, yes. You are of course right that corporate backing gives
 a language a boost, even if it's a mediocre language. But as soon as
 corporate thinking comes into a language (profit, ideology,
 branding, hype and whatnot), it's doomed. D has to breathe, and I
 admire all the people who have made D happen, and who are making it
 happen. I've learned a lot just by listening (well, reading).
You're talking about corporate _management_ rather than corporate backing. The former can obviously lead to problems (though it doesn't have to) -- the latter is almost invariably good, as it means there's someone who can serve as guarantor that any necessary work will get done.
You cannot separate the two. Management will creep into development sooner or later. E.g. one day D might implement features that have to do with what Facebook needs more than features that programmers need in general. So a module std.webshite.upload.latest.picture gets all the attention while std.reallyhandy is being neglected.
To be clear, this doesn't mean that this is happening, it's not, and it is good that Facebook now uses D. But the two should be separate. What D does should not be influenced by any company.
Oh please. Andrei
Nov 22 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 17:43:06 UTC, Andrei Alexandrescu 
wrote:
 On 11/22/13 9:38 AM, Chris wrote:
 On Friday, 22 November 2013 at 13:22:10 UTC, Chris wrote:
 On Friday, 22 November 2013 at 12:34:23 UTC, Joseph Rushton 
 Wakeling
 wrote:
 On Friday, 22 November 2013 at 10:29:35 UTC, Chris wrote:
 Yes, yes, yes. You are of course right that corporate 
 backing gives
 a language a boost, even if it's a mediocre language. But 
 as soon as
 corporate thinking comes into a language (profit, ideology,
 branding, hype and whatnot), it's doomed. D has to breathe, 
 and I
 admire all the people who have made D happen, and who are 
 making it
 happen. I've learned a lot just by listening (well, 
 reading).
You're talking about corporate _management_ rather than corporate backing. The former can obviously lead to problems (though it doesn't have to) -- the latter is almost invariably good, as it means there's someone who can serve as guarantor that any necessary work will get done.
You cannot separate the two. Management will creep into development sooner or later. E.g. one day D might implement features that have to do with what Facebook needs more than features that programmers need in general. So a module std.webshite.upload.latest.picture gets all the attention while std.reallyhandy is being neglected.
To be clear, this doesn't mean that this is happening, it's not, and it is good that Facebook now uses D. But the two should be separate. What D does should not be influenced by any company.
Oh please. Andrei
Yeah, you're right. Sometimes I get carried away and dramatize things.
Nov 22 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:
 What puzzles me is the enormous activity in the Go forum. Only
 the Python forum has that much traffic. It seems to me that
 people are all that happy if they have a language with which 
 they
 can just start hacking around on something.

 That is because Go doesn't force anyone to think about design.
 The only design-level construct it has is the class an that's 
 it.
 Embedding is truly only to save coding effort not having to type
 in dereferenciation chains as in C. There is nothing except
 classes, but no inheritance, traits, mixins, overriding, etc. So
 there is nothing that forces you to think about your design in
 Go. And you don't have to know about manual memory management as
 in Rust.

 -- Bienlein
That actually makes it a good first language to learn programming (and also bad programming). Simplicity is appealing. A language that can be learnt in a couple of afternoons is always pleasant and will draw masses. OTOH, if it doesn't force you to think about design, I guess the absence of design bites you in the long term. Then, the simplicity of the language added to the fact that it's statically typed might allow for fairly sophisticated refactoring using tooling. These are just suppositions, I don't have any experience with Go.
Nov 21 2013
parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 22 November 2013 at 02:25:22 UTC, SomeDude wrote:
 That is because Go doesn't force anyone to think about design.
 The only design-level construct it has is the class an that's 
 it.
That actually makes it a good first language to learn programming (and also bad programming). Simplicity is appealing.
Or a second language. Simple to learn makes it easy for one of any skill to pick it up. I don't think any language forces one to think about design. Go just removes design options. D allows for the same quick fix, but it makes it 100x easier to work that quick fix into a design. I'm not a fan of object oriented programming. Its strength is its weakness. It provides structure, structure is resistant to change. Change is what we do, problems come from change.
Nov 21 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 11/7/2013 7:04 AM, Bienlein wrote:
 And, of course, Rust has
 Mozilla pushing it.
Well, I don't know what muscle Mozilla has. I don't really understand where they get their money from (in part from Google?).
Primarily from Google, AIUI. From what I've read on Wikipedia, the vast majority of Mozilla's income is apparently from Google paying them to be Firefox's default search engine.
Nov 07 2013
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 5 November 2013 at 13:05:21 UTC, Atila Neves wrote:
 - Trying to use dub to compile the project in release or 
 profile mode flat out didn't work. I had to take the verbose 
 output of dub, use it to compile vibe.d in debug mode into an 
 object file and compile my own code separately and link it in. 
 I believe this was a dmd regression. Speaking of which, why 
 does dub recompile the world instead of tracking dependencies 
 (I tried the rdmd option once but that didn't work, I can't 
 remember why)?

 - I ran into a dmd bug when I tried to use TaskPool.map with a 
 delegate so I had to give up trying that possible optimisation.

 - I ran into another dmd bug (it crashed) at one point if 
 -inline was used.

 - dub build with LDC and GDC failed miserably. I think it was 
 because of vibe.d.
Are all of these issues noted on bugzilla? If not are you able to add them please? They sound serious and don't want to be forgotten about.
Nov 05 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/5/2013 5:05 AM, Atila Neves wrote:
 - I ran into a dmd bug when I tried to use TaskPool.map with a delegate so I
had
 to give up trying that possible optimisation.

 - I ran into another dmd bug (it crashed) at one point if -inline was used.
It's very important to file these issues in bugzilla.
 - dub build with LDC and GDC failed miserably. I think it was because of
vibe.d.
These too in the dub system.
Nov 05 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 5 November 2013 at 19:57:07 UTC, Walter Bright wrote:
 - I ran into another dmd bug (it crashed) at one point if 
 -inline was used.
At least this one will be fixed in 2.064
Nov 05 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 05.11.2013 21:33, schrieb Dicebot:
 On Tuesday, 5 November 2013 at 19:57:07 UTC, Walter Bright wrote:
 - I ran into another dmd bug (it crashed) at one point if -inline was
 used.
At least this one will be fixed in 2.064
Are you sure? There are still 5 open ICE-bugs with -inline https://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=-inline%20ICE&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr&component=DMD&product=D -- Kind Regards Benjamin Thaut
Nov 06 2013
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 6 November 2013 at 11:27:04 UTC, Benjamin Thaut 
wrote:
 Are you sure? There are still 5 open ICE-bugs with -inline

 https://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=-inline%20ICE&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr&component=DMD&product=D
Probably not all of them but at least on of "-inline" ICE's I got running vibe.d unittests on 2.063.2 faded away after switching to 2.064 branch
Nov 06 2013
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
I submitted the -inline bug. The other one with TaskPool.map was 
a known one, as was one with dub and dmd. I'll look at dub with 
ldc/gdc and at their bug tracking.


On Tuesday, 5 November 2013 at 19:57:07 UTC, Walter Bright wrote:
 On 11/5/2013 5:05 AM, Atila Neves wrote:
 - I ran into a dmd bug when I tried to use TaskPool.map with a 
 delegate so I had
 to give up trying that possible optimisation.

 - I ran into another dmd bug (it crashed) at one point if 
 -inline was used.
It's very important to file these issues in bugzilla.
 - dub build with LDC and GDC failed miserably. I think it was 
 because of vibe.d.
These too in the dub system.
Nov 06 2013
prev sibling parent reply "brad clawsie" <brad b7j0c.org> writes:
this has been a great thread and I've found a lot of the replies  
very insightful. I've been programming in Go at work for about a 
year or so now, so I have some opinions on Go that I believe are 
reasonably informed, while I am still a D novice but hope to 
continue learning.

First, let me say that it is obvious that, by design, D is a more 
powerful language than Go. Go's simplicity will either be an 
advantage or a deal-breaker based on who you ask.

On my vps instance last night I tried to create an initial D 
programming environment, with the following tools:

- dmd
- dub
- vibe.d
- ldc (not strictly necessary but I've heard so many good things 
about it)

First I tried installing dmd from source, which was fine but then 
I would get strange errors about referring to a file "object.d" 
when trying to build dub. Some poking around on the web resulted 
in the advice of installing the pre-built dmd binary that is in 
the release distribution. Now I was able to build dub, although 
it was strange to see two completely different build mechanisms 
for dmd and dub - dmd using a makefile and dub using a sh script 
wrapper. vibe.d was easier to install once dub worked. Over an 
hour just to get basic tools installed, although I feel HTTP 
serving is so common that it should be one of the accepted 
"batteries included" by default.

If this were Go, I would have installed the default build for my 
platform and had an http server in my standard sdk and everything 
else available by "go get", which has never failed to work 
flawlessly for me in a year of dealing with code from the web. 
This is one reason why there are already so many libraries for Go 
- it is trivial to expose your code to other developers via the 
supported toolchain.

This might not be a fair assessment given my shallow experience 
with D, but it seems much less polished relative to Go for 
setting up a development environment and working with code from 
the web.

Go's tools can be criticized as precluding operating system 
package managers, if people feel that criticism is valid, maybe a 
solution is something like the Haskell Platform, which was a 
reasonable response to the same criticism with haskell in years 
back - that setting up a development environment with basic 
consistent libraries was very painful. Haskell Platform does not 
seek to preclude operating system package managers.

Anyway, I hope this didn't seem too harsh. I still am playing 
with D and hopefully at some point in the future, package 
managers will address some of these needs.

brad
Nov 28 2013
next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:
 this has been a great thread and I've found a lot of the 
 replies  very insightful. I've been programming in Go at work 
 for about a year or so now, so I have some opinions on Go that 
 I believe are reasonably informed, while I am still a D novice 
 but hope to continue learning.

 First, let me say that it is obvious that, by design, D is a 
 more powerful language than Go. Go's simplicity will either be 
 an advantage or a deal-breaker based on who you ask.

 On my vps instance last night I tried to create an initial D 
 programming environment, with the following tools:

 - dmd
 - dub
 - vibe.d
 - ldc (not strictly necessary but I've heard so many good 
 things about it)

 First I tried installing dmd from source, which was fine but 
 then I would get strange errors about referring to a file 
 "object.d" when trying to build dub. Some poking around on the 
 web resulted in the advice of installing the pre-built dmd 
 binary that is in the release distribution. Now I was able to 
 build dub, although it was strange to see two completely 
 different build mechanisms for dmd and dub - dmd using a 
 makefile and dub using a sh script wrapper. vibe.d was easier 
 to install once dub worked. Over an hour just to get basic 
 tools installed, although I feel HTTP serving is so common that 
 it should be one of the accepted "batteries included" by 
 default.
So when you say you would install Go using the default build, did you mean as a binary, or do you mean some sort of default build configuration (from source) for your platform? If as binary then this comparison is a bit unfair here. For me (OpenSuse) all I need to do is: sudo zypper in dmd I've used the pre-built binaries on various Windows & Linux OSs with no troubles. If you want to build from source you might want to have a look at DVM: https://bitbucket.org/doob/dvm/wiki/Home (I don't have any experience with it personally, so I can't say how trouble free your experience would be).
 If this were Go, I would have installed the default build for 
 my platform and had an http server in my standard sdk and 
 everything else available by "go get", which has never failed 
 to work flawlessly for me in a year of dealing with code from 
 the web. This is one reason why there are already so many 
 libraries for Go - it is trivial to expose your code to other 
 developers via the supported toolchain.

 This might not be a fair assessment given my shallow experience 
 with D, but it seems much less polished relative to Go for 
 setting up a development environment and working with code from 
 the web.
Well D is a volunteer effort while Go is being backed by the worlds biggest web company! That sort of accounts for that I suppose. There has been recognition in the community that this needs to improve, but progress is only so fast with the limited resources.
 Go's tools can be criticized as precluding operating system 
 package managers, if people feel that criticism is valid, maybe 
 a solution is something like the Haskell Platform, which was a 
 reasonable response to the same criticism with haskell in years 
 back - that setting up a development environment with basic 
 consistent libraries was very painful. Haskell Platform does 
 not seek to preclude operating system package managers.

 Anyway, I hope this didn't seem too harsh. I still am playing 
 with D and hopefully at some point in the future, package 
 managers will address some of these needs.

 brad
Hope you enjoy your experience with D.
Nov 28 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/28/13 9:49 PM, Craig Dillabaugh wrote:
 On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:
 This might not be a fair assessment given my shallow experience with
 D, but it seems much less polished relative to Go for setting up a
 development environment and working with code from the web.
Well D is a volunteer effort while Go is being backed by the worlds biggest web company! That sort of accounts for that I suppose. There has been recognition in the community that this needs to improve, but progress is only so fast with the limited resources.
Thanks Brad for the compare & contrast. Craig, I think funding is part of the story but not all - our community could get better at being perfectionist about the out-of-the box experience. Go is underpowered but its good execution is undeniably attractive: the first experience, the implementation works as advertised, and the networking libraries show their authors' expertise. We stand to learn from that. Andrei
Nov 29 2013
prev sibling next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:
 First I tried installing dmd from source, which was fine but 
 then I would get strange errors about referring to a file 
 "object.d" when trying to build dub. Some poking around on the 
 web resulted in the advice of installing the pre-built dmd 
 binary that is in the release distribution.
I really have to agree. I recently had to set up an environment for contributing to phobos but the whole experience was a bit ... tedious. I ended up just using dmd.2.064.2.zip and putting the git repos in the src folder and making a bunch of scripts to move the built binaries into their correct positions. Being in the unique position of programming on Windows, Mac, and Linux, I've had to rewrite the coping script differently for each one. Windows is the worst for that sort of thing, but that's to be expected. The whole build process is a lot more involved than it really should be. Ideally you should be able to clone dmd, phobos, and druntime and just have everything compile and be put into a relative path together and just "work". Maybe alert you if you don't have phobos and druntime to build. Ultimately, you really "have to" download the binary version if you want it to work transparently, but it would be nice if it were easy enough to build from source that a printed 1 page guide would get you 100% running.
 I feel HTTP serving is so common that it should be one of the 
 accepted "batteries included" by default.
That I'm not sure I'd agree with. Maybe getting stuff via HTTP (we have curl at a.t.m.) but serving HTTP files really needs something more substantial than I'd feel comfortable being in the standard library. Something too simple would likely not be used in favor of something like vibe.d while something the size of vibe.d probably is a bit too expansive to really be considered for part in the standard library. Not to mention the fact that vibe.d is in reasonably rapid development. The speed of vibe.d releases outpaces DMD releases and I think that's a positive thing overall. Plus I feel like such an approach might make "simpler" things suffer (or, at least, make them feel like they suffer). Every time I use python I think "it's so nice that I can write an advanced http server with ssl encryption serving up a calculated meaning of life and the last digit of pi in one line, but I have to write an iterator to iterate over elements pairwise, which I'd really think should be in the standard library somewhere." (A "recipe" for it is in itertools which, strangely, suggests that they know how often it might be needed but failed to add it as an actual part of the standard library, but I digress...)
Nov 28 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 29 November 2013 at 05:51:48 UTC, Chris Cain wrote:
 The whole build process is a lot more involved than it really 
 should be. Ideally you should be able to clone dmd, phobos, and 
 druntime and just have everything compile and be put into a 
 relative path together and just "work". Maybe alert you if you 
 don't have phobos and druntime to build. Ultimately, you really 
 "have to" download the binary version if you want it to work 
 transparently, but it would be nice if it were easy enough to 
 build from source that a printed 1 page guide would get you 
 100% running.
Huh? git clone https://github.com/D-Programming-Language/dmd.git git clone https://github.com/D-Programming-Language/druntime.git git clone https://github.com/D-Programming-Language/phobos.git cd ./dmd/src make -f posix.mak MODEL=64 RELEASE=1 cd ../../druntime make -f posix.mak MODEL=64 DMD=../dmd/src/dmd RELEASE=1 cd ../phobos make -f posix.mak MODEL=64 DMD=../dmd/src/dmd RELEASE=1 After that just make symlink to dmd binary and add Phobos/druntime paths to dmd.conf and you are ready to go.
Nov 29 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-29 16:15, Dicebot wrote:

 After that just make symlink to dmd binary and add Phobos/druntime paths
 to dmd.conf and you are ready to go.
dmd.conf.default is only for Linux. There's also no sc.ini for Windows. -- /Jacob Carlborg
Nov 29 2013
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 29 November 2013 at 15:34:21 UTC, Jacob Carlborg wrote:
 On 2013-11-29 16:15, Dicebot wrote:

 After that just make symlink to dmd binary and add 
 Phobos/druntime paths
 to dmd.conf and you are ready to go.
dmd.conf.default is only for Linux. There's also no sc.ini for Windows.
Pardon my ignorance, I have never used D on Windows. Well, I guess at least building part should be pretty much the same (afair make binary for Windows is in distribution)
Nov 29 2013
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
This reply is not intended as a specific reply to Brad, so no pun 
inside, really, but...

I always wonder for how much attention there's out there 
regarding the setting up of the development environment: from my 
experience, I very very like the D simplicity, just grab a zip, 
and inside you have all the basic for every supported os. The 
_only_ missing thing in the zip is dub (guys, that MUST be in the 
official distribution).

It's so easy that when I hear about installer, packager, etc, etc 
I scratch my head... O_o

/Paolo

On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:

<snip>
 This might not be a fair assessment given my shallow experience 
 with D, but it seems much less polished relative to Go for 
 setting up a development environment and working with code from 
 the web.
<snip>
 brad
Nov 28 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-29 06:14, brad clawsie wrote:
 this has been a great thread and I've found a lot of the replies very
 insightful. I've been programming in Go at work for about a year or so
 now, so I have some opinions on Go that I believe are reasonably
 informed, while I am still a D novice but hope to continue learning.

 First, let me say that it is obvious that, by design, D is a more
 powerful language than Go. Go's simplicity will either be an advantage
 or a deal-breaker based on who you ask.

 On my vps instance last night I tried to create an initial D programming
 environment, with the following tools:

 - dmd
 - dub
 - vibe.d
 - ldc (not strictly necessary but I've heard so many good things about it)

 First I tried installing dmd from source, which was fine but then I
 would get strange errors about referring to a file "object.d" when
 trying to build dub. Some poking around on the web resulted in the
 advice of installing the pre-built dmd binary that is in the release
 distribution. Now I was able to build dub, although it was strange to
 see two completely different build mechanisms for dmd and dub - dmd
 using a makefile and dub using a sh script wrapper. vibe.d was easier to
 install once dub worked. Over an hour just to get basic tools installed,
 although I feel HTTP serving is so common that it should be one of the
 accepted "batteries included" by default.

 If this were Go, I would have installed the default build for my
 platform and had an http server in my standard sdk and everything else
 available by "go get", which has never failed to work flawlessly for me
 in a year of dealing with code from the web. This is one reason why
 there are already so many libraries for Go - it is trivial to expose
 your code to other developers via the supported toolchain.
Why did you install dmd from source and not the same way as Go? It's a bit unfair comparison. Dub is a package manager for D, with many libraries available. -- /Jacob Carlborg
Nov 29 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 29/11/13 14:53, Jacob Carlborg wrote:
 Why did you install dmd from source and not the same way as Go? It's a bit
 unfair comparison. Dub is a package manager for D, with many libraries
available.
There is absolutely no point trying to complain about "unfair comparison" here. The real question you have to ask is why there wasn't an obvious equivalent to Go's "install the default build for my platform". You can say, "Hey, D does have that equivalent, the .zip installer, or the .deb or .rpm files ...!" but that's not the point. The point is why OP considered that the natural way to do things was to install from source. The obvious solution to this is that the homepage should have a Big Friendly Button shouting "Get started with D!" that should take you to a page which auto-detects your system and makes available an appropriate installer.
Dec 03 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Tuesday, 3 December 2013 at 15:07:36 UTC, Joseph Rushton 
Wakeling wrote:
 On 29/11/13 14:53, Jacob Carlborg wrote:
 The obvious solution to this is that the homepage should have a 
 Big Friendly Button shouting "Get started with D!" that should 
 take you to a page which auto-detects your system and makes 
 available an appropriate installer.
At least let it be a *proeminent* link towards the "Downloads & Tools" page, which is so quietly hidden in the left menu.
Dec 03 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/3/13 7:56 AM, eles wrote:
 On Tuesday, 3 December 2013 at 15:07:36 UTC, Joseph Rushton Wakeling wrote:
 On 29/11/13 14:53, Jacob Carlborg wrote:
 The obvious solution to this is that the homepage should have a Big
 Friendly Button shouting "Get started with D!" that should take you to
 a page which auto-detects your system and makes available an
 appropriate installer.
At least let it be a *proeminent* link towards the "Downloads & Tools" page, which is so quietly hidden in the left menu.
Pull request please. Also does everybody like the graphics at the top of http://dconf.org/2014/index.html? Andrei
Dec 03 2013
next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu 
wrote:
 On 12/3/13 7:56 AM, eles wrote:
 On Tuesday, 3 December 2013 at 15:07:36 UTC, Joseph Rushton 
 Wakeling wrote:
 On 29/11/13 14:53, Jacob Carlborg wrote:
 The obvious solution to this is that the homepage should have 
 a Big
 Friendly Button shouting "Get started with D!" that should 
 take you to
 a page which auto-detects your system and makes available an
 appropriate installer.
At least let it be a *proeminent* link towards the "Downloads & Tools" page, which is so quietly hidden in the left menu.
Pull request please. Also does everybody like the graphics at the top of http://dconf.org/2014/index.html? Andrei
I do, nice and clean. If I had any criticism it would be that the lettering on "Menlo Park" etc. is just a tiny bit too heavy. If the letters could be made more distinct, that would be nice. However, I don't think it is a show-stopper. Of course, now the next person to respond is going to say how much they like that lettering. Craig
Dec 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/3/13 4:57 PM, Craig Dillabaugh wrote:
 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:
 On 12/3/13 7:56 AM, eles wrote:
 On Tuesday, 3 December 2013 at 15:07:36 UTC, Joseph Rushton Wakeling
 wrote:
 On 29/11/13 14:53, Jacob Carlborg wrote:
 The obvious solution to this is that the homepage should have a Big
 Friendly Button shouting "Get started with D!" that should take you to
 a page which auto-detects your system and makes available an
 appropriate installer.
At least let it be a *proeminent* link towards the "Downloads & Tools" page, which is so quietly hidden in the left menu.
Pull request please. Also does everybody like the graphics at the top of http://dconf.org/2014/index.html? Andrei
I do, nice and clean. If I had any criticism it would be that the lettering on "Menlo Park" etc. is just a tiny bit too heavy. If the letters could be made more distinct, that would be nice. However, I don't think it is a show-stopper. Of course, now the next person to respond is going to say how much they like that lettering. Craig
Thanks. I was asking mainly hoping that someone would say it's horrible and submit a fix :o). I adapted that from last year's logo with a free online image editor over my phone's 4G connection on a bus. True story. Andrei
Dec 03 2013
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu 
wrote:
 Pull request please. Also does everybody like the graphics at 
 the top of http://dconf.org/2014/index.html?

 Andrei
The space between the 0, 1 and 4 in 2014 is making me cringe.
Dec 03 2013
parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Wed, Dec 4, 2013 at 6:13 AM, Meta <jared771 gmail.com> wrote:
 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:
 Pull request please. Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?

 Andrei
The space between the 0, 1 and 4 in 2014 is making me cringe.
Compulsory XKCD link: http://xkcd.com/1015/
Dec 03 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-03 21:53, Andrei Alexandrescu wrote:

 Pull request please. Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?
Honestly, no. It's very, yellow. Although I'm no designer so I won't try to create an alternative. -- /Jacob Carlborg
Dec 03 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 03/12/13 21:53, Andrei Alexandrescu wrote:
 Pull request please.
I've no objection to that, but in this case I think I'd rather donate towards hiring a really good designer to modernize the website UI [*]. If we're not kickstarting the conference this year, how about a donation drive for the website + forums? [* Secondary worry: if we're going to have a big "Get Started With D!" notice on the front page, all those installers had better be well tested and guaranteed to Just Work.] [* Tertiary worry: I'm not convinced the website will benefit from one or two of us contributing what we think is a clearer "get started" message. User testing is really the only way to ensure that people get from the website what we want them to get.]
Dec 04 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu 
wrote:
 On 12/3/13 7:56 AM, eles wrote:
 On Tuesday, 3 December 2013 at 15:07:36 UTC, Joseph Rushton 
 Wakeling wrote:
 On 29/11/13 14:53, Jacob Carlborg wrote:
 The obvious solution to this is that the homepage should have 
 a Big
 Friendly Button shouting "Get started with D!" that should 
 take you to
 a page which auto-detects your system and makes available an
 appropriate installer.
At least let it be a *proeminent* link towards the "Downloads & Tools" page, which is so quietly hidden in the left menu.
Pull request please. Also does everybody like the graphics at the top of http://dconf.org/2014/index.html? Andrei
The yellow doesn't "stand" well on the dark gray background. It causes the eyes to focus and defocus. Plain white or a very light yellow would be better. Good idea to have a curvy font based on the letter "D". Only the "4" in 2014 seems to be a bit of an outlier, maybe it would help to give it some curves at the top (and on the left). It kind of breaks the overall curvy feeling. Maybe move the logo+text a bit more to the right and give the text a bit more padding-left to give it more room to "breathe". The content could do with a bit more line spacing in the bullet-point section. If I have time and there is demand I could attempt a design template for 2015. At the moment I'm too busy to come up with anything for 2014.
Dec 04 2013
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu 
wrote:
 Also does everybody like the graphics at the top of 
 http://dconf.org/2014/index.html?
Frankly, it's awful.
Dec 04 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/4/13 10:57 PM, Martin Nowak wrote:
 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:
 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?
Frankly, it's awful.
I agree!! Andrei
Dec 05 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, December 05, 2013 06:44:41 Andrei Alexandrescu wrote:
 On 12/4/13 10:57 PM, Martin Nowak wrote:
 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:
 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?
Frankly, it's awful.
I agree!!
As do I. The font is not particularly pretty, and the yellow is way to harsh. But unfortunately, I doubt that I could do much better. And it's pretty amazing that you managed to do that on your phone. Imagine how someone would have looked at you had you told them ten years ago that in the future, you'd be doing something like that on your phone... :) - Jonathan M Davis
Dec 06 2013
prev sibling parent reply "Tourist" <gravatar gravatar.com> writes:
On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei Alexandrescu 
wrote:
 On 12/4/13 10:57 PM, Martin Nowak wrote:
 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei 
 Alexandrescu wrote:
 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?
Frankly, it's awful.
I agree!! Andrei
I'm not a designer, but I think whatever alternative is better. My try: http://imgur.com/a/hCIPm Font: Sansus Webissimo
Dec 06 2013
next sibling parent reply "Tourist" <gravatar gravatar.com> writes:
On Friday, 6 December 2013 at 11:45:36 UTC, Tourist wrote:
 On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei 
 Alexandrescu wrote:
 On 12/4/13 10:57 PM, Martin Nowak wrote:
 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei 
 Alexandrescu wrote:
 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?
Frankly, it's awful.
I agree!! Andrei
I'm not a designer, but I think whatever alternative is better. My try: http://imgur.com/a/hCIPm Font: Sansus Webissimo
Oops, 2014 of course :) http://imgur.com/a/EkIPw
Dec 06 2013
parent "eles" <eles eles.com> writes:
On Friday, 6 December 2013 at 12:21:12 UTC, Tourist wrote:
 On Friday, 6 December 2013 at 11:45:36 UTC, Tourist wrote:
 On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei 
 Alexandrescu wrote:
 On 12/4/13 10:57 PM, Martin Nowak wrote:
 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei 
 Alexandrescu wrote:
 My try:
 http://imgur.com/a/hCIPm

 Font: Sansus Webissimo
Oops, 2014 of course :)
Too bad. I really loved the way that you rounded the 4 until it became a 3. People find 4 to be not as smooth as the D belly, so maybe they will take a 3 instead :)
Dec 06 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 6 December 2013 at 11:45:36 UTC, Tourist wrote:
 On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei 
 Alexandrescu wrote:
 On 12/4/13 10:57 PM, Martin Nowak wrote:
 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei 
 Alexandrescu wrote:
 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?
Frankly, it's awful.
I agree!! Andrei
I'm not a designer, but I think whatever alternative is better. My try: http://imgur.com/a/hCIPm Font: Sansus Webissimo
Just add some letter spacing and bin that effin yellow. It will work wonders. The font is not really the problem, cos it makes sense to base it on the belly of "D". But add letter-spacing and make the font slimmer. [ other suggestion] No drop shadows, please. In this context it don't make no sense to have drop shadows. Unless it's on a white or not grayish background.
Dec 06 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/6/13 3:45 AM, Tourist wrote:
 On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei Alexandrescu wrote:
 On 12/4/13 10:57 PM, Martin Nowak wrote:
 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:
 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?
Frankly, it's awful.
I agree!! Andrei
I'm not a designer, but I think whatever alternative is better. My try: http://imgur.com/a/hCIPm Font: Sansus Webissimo
s/2013/2014/ Andrei
Dec 06 2013
parent "Tourist" <gravatar gravatar.com> writes:
On Friday, 6 December 2013 at 20:35:10 UTC, Andrei Alexandrescu 
wrote:
 On 12/6/13 3:45 AM, Tourist wrote:
 On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei 
 Alexandrescu wrote:
 On 12/4/13 10:57 PM, Martin Nowak wrote:
 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei 
 Alexandrescu wrote:
 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?
Frankly, it's awful.
I agree!! Andrei
I'm not a designer, but I think whatever alternative is better. My try: http://imgur.com/a/hCIPm Font: Sansus Webissimo
s/2013/2014/ Andrei
lol, I saw you've pulled the 2013 one. http://forum.dlang.org/post/wtsohypsvefsabegidmy forum.dlang.org
Dec 06 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-03 16:07, Joseph Rushton Wakeling wrote:

 There is absolutely no point trying to complain about "unfair
 comparison" here.  The real question you have to ask is why there wasn't
 an obvious equivalent to Go's "install the default build for my platform".

 You can say, "Hey, D does have that equivalent, the .zip installer, or
 the .deb or .rpm files ...!" but that's not the point.  The point is why
 OP considered that the natural way to do things was to install from source.
I thought that was just what I asked. Sure I could have skipped the "unfair comparison". -- /Jacob Carlborg
Dec 03 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 29/11/13 06:14, brad clawsie wrote:
 First I tried installing dmd from source, which was fine but then I would get
 strange errors about referring to a file "object.d" when trying to build dub.
Had you created a dmd.conf file containing the right locations for runtime/Phobos and placed in the same directory as the dmd binary?
Dec 03 2013