www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Using D

reply "Chris" <wendlec tcd.ie> writes:
I have followed the recent discussions about D and I can see the 
usual pattern, to wit GC, Go (or whatever) is so much better, 
everyone blaming each other for not contributing, not being 
allowed to contribute blah.

First of all, I am in no position to criticize anyone who is 
contributing to the language. I don't contribute, because I don't 
have the time to do so. Indeed I have huge, massive respect for 
everyone who contributes to D. The only thing I do is to actually 
use the language and tell everyone about it. I have developed a 
screen reader plug in in D (using C libraries) that was 
ridiculously easy to integrate on Windows as a DLL. I used vibe.d 
to create a lightning fast online version of the screen reader. 
Believe me, D's supposed sluggishness as regards GC is not so 
important for most applications. I dare say 90% of all 
applications are fine with the current GC. I compiled both 
applications with dmd (testing phase) not with ldc or gdc and 
they are very fast.

Let's not forget that Go has millions and billions of dollars 
behind it and that it is inevitable that the whole internet will 
be full of zealots and professional posters who promote Go as 
"theeee best thing ever". People. Sheep. Meehhh.

Apart from the necessary discussions about language features / 
improvements we need to focus on the power of D. vibe.d is one 
example. I think the problem is that we don't bundle the various 
efforts that have been made independently well enough. 
Contribution to D is narrowly defined as "contributing to the 
library / core of the language". There has been mention of 
integrating vibe.d's fibers into the library. Even if it won't 
happen, we should set up an infrastructure that facilitates the 
use of the various, as of now independent, components and point 
users to it. I have to say that a lot of good things have escaped 
me simply because nobody told me about them. It's often by 
accident that I find out about a great library or framework in D.

Sometimes I have the feeling that we blow things out of 
proportion, because we walk right into the trap. The GC thing, 
although it is very important, is a good example. Let's not 
forget that zeolots and professional posters will always point 
out the flaws of D, and blow them out of proportion. "D doesn't 
have xyz, so it's shit!" Divide et impera (divide and rule).

Let's first make a list of things that have been achieved with D 
and that are on a par with or even bettar than in other languages 

have been made independently. We will soon have a powerful and 
impressive framework. And let's not forget, a language (be it a 
natural or a computer language) only lives and thrives, if people 
use it.

My 2 cents. At your service.
Jul 11 2014
next sibling parent reply simendsjo <simendsjo gmail.com> writes:
On 07/11/2014 05:30 PM, Chris wrote:
(...)

 Believe me, D's supposed sluggishness as regards GC is
 not so important for most applications. I dare say 90% of all
 applications are fine with the current GC.


(...)

I agree with this. The bottlenecks i my applications are MySQL and
Microsoft Office (Excel, Powerpoint, or even just plain COM). The same

you do, but for my use (and yours, and probably many others), the GC
performance is something you can probably safely ignore.

A little anecdote.. I once got a 20% speed increase in Python by
"moving" a variable instantiation outside a tight loop.
  i = 0

    i = something

rather than

    i = something

The compiler wasn't smart enough to do this.
Jul 11 2014
next sibling parent simendsjo <simendsjo gmail.com> writes:
On 07/11/2014 05:43 PM, simendsjo wrote:

 On 07/11/2014 05:30 PM, Chris wrote:
 (...)

 Believe me, D's supposed sluggishness as regards GC is
 not so important for most applications. I dare say 90% of all
 applications are fine with the current GC.


 (...)
 


(...)

Oh, and a little GC.disable()/GC.enable() goes a long way. Only had to
do this a couple of times though.
Jul 11 2014
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2014-07-11 at 17:43 +0200, simendsjo via Digitalmars-d wrote:
[=E2=80=A6]

 A little anecdote.. I once got a 20% speed increase in Python by
 "moving" a variable instantiation outside a tight loop.
   i =3D 0

     i =3D something
=20
 rather than

     i =3D something


This is interesting. I can believe there is some performance benefit,
but I am not sure I believe 20% improvement. If you can send me the code
you were using, I would like to do some benchmarking on this.


 The compiler wasn't smart enough to do this.


The Python compiler cannot and will never be able to do any such thing.
Indeed if it did any such thing, it would be an error since it
significantly changes the semantics of the program. Thus not doing this
is not the fault of the compiler.  The fact that you were able to do
this and it appeared to give you the same results just means that the
change in program semantics did not affect your computation. Which is
good, but not something the compiler could determine.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 11 2014
parent reply simendsjo <simendsjo gmail.com> writes:
On 07/11/2014 06:28 PM, Russel Winder via Digitalmars-d wrote:

 On Fri, 2014-07-11 at 17:43 +0200, simendsjo via Digitalmars-d wrote:
 […]

 A little anecdote.. I once got a 20% speed increase in Python by
 "moving" a variable instantiation outside a tight loop.
   i = 0

     i = something

 rather than

     i = something


 
 This is interesting. I can believe there is some performance benefit,
 but I am not sure I believe 20% improvement. If you can send me the code
 you were using, I would like to do some benchmarking on this.


Yes, I was very perplexed when I was profiling and finally found the
main offender. Unfortunately I don't have the code - it was a project
done for a past employer back in 2006/2007 (Python 2.4 IIRC).


 The compiler wasn't smart enough to do this.


 
 The Python compiler cannot and will never be able to do any such thing.
 Indeed if it did any such thing, it would be an error since it
 significantly changes the semantics of the program. Thus not doing this
 is not the fault of the compiler.  The fact that you were able to do
 this and it appeared to give you the same results just means that the
 change in program semantics did not affect your computation. Which is
 good, but not something the compiler could determine.


I think of this as a fault in the compiler. It was quite obvious (to me)
that nothing else relied on the value so the value didn't have to be
created on each iteration.
Jul 11 2014
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/11/2014 09:53 AM, simendsjo wrote:


 On 07/11/2014 06:28 PM, Russel Winder via Digitalmars-d wrote:

 On Fri, 2014-07-11 at 17:43 +0200, simendsjo via Digitalmars-d wrote:
 […]

 A little anecdote.. I once got a 20% speed increase in Python by
 "moving" a variable instantiation outside a tight loop.
    i = 0

      i = something

 rather than

      i = something


 This is interesting. I can believe there is some performance benefit,
 but I am not sure I believe 20% improvement. If you can send me the code
 you were using, I would like to do some benchmarking on this.


 Yes, I was very perplexed when I was profiling and finally found the
 main offender. Unfortunately I don't have the code - it was a project
 done for a past employer back in 2006/2007 (Python 2.4 IIRC).


 The compiler wasn't smart enough to do this.


 The Python compiler cannot and will never be able to do any such thing.
 Indeed if it did any such thing, it would be an error since it
 significantly changes the semantics of the program. Thus not doing this
 is not the fault of the compiler.  The fact that you were able to do
 this and it appeared to give you the same results just means that the
 change in program semantics did not affect your computation. Which is
 good, but not something the compiler could determine.


 I think of this as a fault in the compiler. It was quite obvious (to me)
 that nothing else relied on the value so the value didn't have to be
 created on each iteration.


Can that 'i = something' expression be monkey-patched in Python? If so, 
it could have side-effects to make the program change semantics like 
Russel Winder means.

Ali
Jul 11 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Ali Çehreli:


 Can that 'i = something' expression be monkey-patched in 
 Python? If so, it could have side-effects to make the program 
 change semantics like Russel Winder means.


Right. And even PyPy isn't a compiler. Python is interpreted. And 
at best JITted. In most cases you use Cpython, that is an 
interpreter. And in Python most optimizations are dangerous, 
because the language is very dynamic. If you look for performance 
it's better for you to look elsewhere (like Julia).

Bye,
bearophile
Jul 11 2014
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2014-07-11 at 18:53 +0200, simendsjo via Digitalmars-d wrote:
[=E2=80=A6]

 Yes, I was very perplexed when I was profiling and finally found the
 main offender. Unfortunately I don't have the code - it was a project
 done for a past employer back in 2006/2007 (Python 2.4 IIRC).


Ah. In which case the anecdote is only of historical interest since it
says nothing about Python as it is today. 2.7 is way faster than 2.4 and
has far more in it that would like make the code in need of a amendment
anyway =E2=80=93 also the way local variables are stored and manipulated ha=
s
been changed and improved massively over the intervening time. Moreover
3.4 is way, way better than 2.7 and has so much more in it that a
rewrite would definitely be needed if performance was a factor. Without
the code though there is no data point, so nothing to pursue. Sadly.

[=E2=80=A6]

 I think of this as a fault in the compiler. It was quite obvious (to me)
 that nothing else relied on the value so the value didn't have to be
 created on each iteration.


A new variable was not being created on each iteration. Python does not
have block scoping.

This cannot be seen as a fault with the compiler since all the compiler
does is to check syntax and indents and convert your source code into
bytecodes. The compiler does not and must not do any form of amending
the abstract syntax tree (AST). Manipulations of the AST must be in the
source code, cf. MacroPy.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 12 2014
prev sibling parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Friday, 11 July 2014 at 15:42:04 UTC, simendsjo wrote:

 On 07/11/2014 05:30 PM, Chris wrote:
 (...)

 Believe me, D's supposed sluggishness as regards GC is
 not so important for most applications. I dare say 90% of all
 applications are fine with the current GC.


 (...)

 I agree with this. The bottlenecks i my applications are MySQL 
 and
 Microsoft Office (Excel, Powerpoint, or even just plain COM). 
 The same

 on what
 you do, but for my use (and yours, and probably many others), 
 the GC
 performance is something you can probably safely ignore.



that don't use GC.  The big problem for D is that the market for 
programming languages has bifurcated since D was created, with 
the performant native-compiled languages like C/C++/Obj-C on one 
side and the much larger market for easier to use but much less 
performant, what used to be called "scripting," languages like 
ruby/python/java on the other.  Trying to be a better C++, by 
borrowing some ease of use features like GC or reflection from 
the scripting languages, leaves D stuck in the middle right now, 
neither here nor there.

Who still uses native-compiled languages?  Performance-sensitive 
games, server applications that squeeze out performance, like 
number-crunching or search engines, and desktop apps that need 
the performance, that's about it.  Everything else has either 
gone to the web with a scripting language backend or mobile.  I 
hear that even enterprise LOB desktop apps are mostly written in 

native language and can crank the code out quicker that way.

However, mobile could be D's saving grace, as native development 
is back on iOS and even Android is moving to Ahead-Of-Time 
compiling with the next release.  Too bad D doesn't work on 
mobile, even though some of us are working on getting it there.

D should focus on the native end of the market, by trying to be 
the easier way to get most of the performance.  You're not going 
to get the scripting guys now, because native is just too hard 
for them.  If D can assert itself in that smaller niche of native 
languages, it might have enough juice to go after the other end 
later.  I don't think either happens without a commercial 
implementation, community development doesn't cut it.  Linux 
didn't take off till long after it got commercial vendors on 
board, the same will be true here.

I don't mean to be pessimistic about D's goal of being usable by 
all, from scripting to systems, as D may actually be good enough 
to get there one day.  I just think you're not going to get there 
without focusing on taking over a niche at a time, particularly 
the niche best suited to D right now, mobile.
Jul 11 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 11 July 2014 at 19:00:30 UTC, Joakim wrote:

 On Friday, 11 July 2014 at 15:42:04 UTC, simendsjo wrote:

 On 07/11/2014 05:30 PM, Chris wrote:
 (...)

 Believe me, D's supposed sluggishness as regards GC is
 not so important for most applications. I dare say 90% of all
 applications are fine with the current GC.


 (...)

 I agree with this. The bottlenecks i my applications are MySQL 
 and
 Microsoft Office (Excel, Powerpoint, or even just plain COM). 
 The same

 lot on what
 you do, but for my use (and yours, and probably many others), 
 the GC
 performance is something you can probably safely ignore.



 that don't use GC.  The big problem for D is that the market 
 for programming languages has bifurcated since D was created, 
 with the performant native-compiled languages like C/C++/Obj-C 
 on one side and the much larger market for easier to use but 
 much less performant, what used to be called "scripting," 
 languages like ruby/python/java on the other.  Trying to be a 
 better C++, by borrowing some ease of use features like GC or 
 reflection from the scripting languages, leaves D stuck in the 
 middle right now, neither here nor there.

 Who still uses native-compiled languages?  
 Performance-sensitive games, server applications that squeeze 
 out performance, like number-crunching or search engines, and 
 desktop apps that need the performance, that's about it.  
 Everything else has either gone to the web with a scripting 
 language backend or mobile.  I hear that even enterprise LOB 

 they just don't need the speed of a native language and can 
 crank the code out quicker that way.

 However, mobile could be D's saving grace, as native 
 development is back on iOS and even Android is moving to 
 Ahead-Of-Time compiling with the next release.  Too bad D 
 doesn't work on mobile, even though some of us are working on 
 getting it there.


I agree. This is a big pain for me too.



 D should focus on the native end of the market, by trying to be 
 the easier way to get most of the performance.  You're not 
 going to get the scripting guys now, because native is just too 
 hard for them.  If D can assert itself in that smaller niche of 
 native languages, it might have enough juice to go after the 
 other end later.  I don't think either happens without a 
 commercial implementation, community development doesn't cut 
 it.  Linux didn't take off till long after it got commercial 
 vendors on board, the same will be true here.

 I don't mean to be pessimistic about D's goal of being usable 
 by all, from scripting to systems, as D may actually be good 
 enough to get there one day.  I just think you're not going to 
 get there without focusing on taking over a niche at a time, 
 particularly the niche best suited to D right now, mobile.


A niche for a general purpose language?
Jul 11 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Friday, 11 July 2014 at 19:56:20 UTC, Chris wrote:

 I don't mean to be pessimistic about D's goal of being usable 
 by all, from scripting to systems, as D may actually be good 
 enough to get there one day.  I just think you're not going to 
 get there without focusing on taking over a niche at a time, 
 particularly the niche best suited to D right now, mobile.


 A niche for a general purpose language?


Name one "general purpose language" that currently crosses the 
native->scripting divide and has good usage on both ends of the 
market.  It doesn't exist, because it's almost impossible to do.  
Even if your goal is to be general purpose, you have to do it by 
taking on one niche at a time, which is even harder because you 
have to have your eye on staying general purpose the whole time.  
It's an extremely difficult balancing act, with one hand tied 
behind your back.

I think D could do it someday, but not the way the market is 
today.  Right now, it's too easy for many developers to slap 
together a webapp on rails or django and then simply scale up 
their hardware when necessary.  Maybe that all changes in the 
future and efficiency becomes more of a concern on the server, 
perhaps when the market matures, but we're not there yet.

In the meantime, mobile is where most new native development has 
moved, so D has to really hit that fertile ground.  I also think 
big data could be big for D, Don mentioned D brought their costs 
down a lot in his DConf talk.
Jul 11 2014
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2014-07-11 at 20:25 +0000, Joakim via Digitalmars-d wrote:
[=E2=80=A6]

 Name one "general purpose language" that currently crosses the=20
 native->scripting divide and has good usage on both ends of the=20
 market.  It doesn't exist, because it's almost impossible to do. =20


[=E2=80=A6]

Go and D are really quite close to something useful though on this
front.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 12 2014
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2014-07-11 at 15:30 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]

 Let's not forget that Go has millions and billions of dollars=20
 behind it and that it is inevitable that the whole internet will=20
 be full of zealots and professional posters who promote Go as=20
 "theeee best thing ever". People. Sheep. Meehhh.


(I think I detect unintended irony in this post :-)

Go, via goroutines, promotes CSP as an approach to application
parallelism and is therefore a Good Thing=E2=84=A2. Don't underestimate the
power of single threaded processes communicating using channels and no
shared memory. It is true that any language has zealots, look at
Fortran, Java, Python, D, but a language should not be judged solely by
its zealotry level. Well except for JavaScript (aka ECMAScript) of
course.

[=E2=80=A6]

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 11 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 11 July 2014 at 16:22:27 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Fri, 2014-07-11 at 15:30 +0000, Chris via Digitalmars-d 
 wrote:
 […]

 Let's not forget that Go has millions and billions of dollars 
 behind it and that it is inevitable that the whole internet 
 will be full of zealots and professional posters who promote 
 Go as "theeee best thing ever". People. Sheep. Meehhh.


 (I think I detect unintended irony in this post :-)


I get the point :-)


 Go, via goroutines, promotes CSP as an approach to application
 parallelism and is therefore a Good Thing™. Don't underestimate 
 the
 power of single threaded processes communicating using channels 
 and no
 shared memory. It is true that any language has zealots, look at
 Fortran, Java, Python, D, but a language should not be judged 
 solely by
 its zealotry level. Well except for JavaScript (aka ECMAScript) 
 of
 course.

 […]


I remember Java used to be "theeee" best thing ever. After years 
of using it, however, I found out how restricted the language was 
/ is. Still, it's been a success, because people believed all the 
propaganda. What matters to me is not so much the odd fancy 
feature, it's how well the language performs in general purpose 
programming. Go was designed for servers and thus will always 
have one up on D or any other language at that matter. But could 
I use Go for what I have used D? Not so sure about that. Also, 
like Java Go is a closed thing. D isn't. Once I read about D that 
it shows what can be done "once you take a language out of the 
hands of a committee". Go, like Java, will finally end up in a 
cul de sac and will have a hard time trying to get out of it. Not 
because the language is inherently bad, because it's in the hand 
of a committee. Ideology kills a language. But it doesn't matter, 
because people will use Go or whatever anyway, will _have_ to use 
it.

What I'm taking issue with is that everybody focuses on the flaws 
of D (every language has flaws), which often gives the impression 
that it's an unfinished, stay-away business. It's not. D can be 
used, and I've used it, for production code. It's more mature 
than D or Rust and it is superior to other languages like Java 
(no OO-ideology for example). Mind you, D is a hindsight 
language, which makes it wiser. Does it have flaws? Yes. I come 
across them sometimes. Is there a language without flaws? If 
there is, tell me about it. Talking about hindsight, I've tried 
many different languages, I like D because of what it has to 
offer for general purpose programming, it compiles natively, 
interfaces with C at no cost at all, it has strong modelling 
power, features that users require are added. I may sound like a 
zealot (see "irony"), but I'm not. I'm very pragmatic, D is a 
good tool and, being community driven, there is a real chance of 
making it a fantastic tool. Individual features are not 
everything.
Jul 11 2014
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 11 July 2014 at 16:54:40 UTC, Chris wrote:

 On Friday, 11 July 2014 at 16:22:27 UTC, Russel Winder via 
 Digitalmars-d wrote:

 On Fri, 2014-07-11 at 15:30 +0000, Chris via Digitalmars-d 
 wrote:
 […]

 Let's not forget that Go has millions and billions of dollars 
 behind it and that it is inevitable that the whole internet 
 will be full of zealots and professional posters who promote 
 Go as "theeee best thing ever". People. Sheep. Meehhh.


 (I think I detect unintended irony in this post :-)


 I get the point :-)


 Go, via goroutines, promotes CSP as an approach to application
 parallelism and is therefore a Good Thing™. Don't 
 underestimate the
 power of single threaded processes communicating using 
 channels and no
 shared memory. It is true that any language has zealots, look 
 at
 Fortran, Java, Python, D, but a language should not be judged 
 solely by
 its zealotry level. Well except for JavaScript (aka 
 ECMAScript) of
 course.

 […]


 I remember Java used to be "theeee" best thing ever. After 
 years of using it, however, I found out how restricted the 
 language was / is. Still, it's been a success, because people 
 believed all the propaganda. What matters to me is not so much 
 the odd fancy feature, it's how well the language performs in 
 general purpose programming. Go was designed for servers and 
 thus will always have one up on D or any other language at that 
 matter. But could I use Go for what I have used D? Not so sure 
 about that. Also, like Java Go is a closed thing. D isn't. Once 
 I read about D that it shows what can be done "once you take a 
 language out of the hands of a committee". Go, like Java, will 
 finally end up in a cul de sac and will have a hard time trying 
 to get out of it. Not because the language is inherently bad, 
 because it's in the hand of a committee. Ideology kills a 
 language. But it doesn't matter, because people will use Go or 
 whatever anyway, will _have_ to use it.

 What I'm taking issue with is that everybody focuses on the 
 flaws of D (every language has flaws), which often gives the 
 impression that it's an unfinished, stay-away business. It's 
 not. D can be used, and I've used it, for production code. It's 
 more mature than D or Rust and it is superior to other 
 languages like Java (no OO-ideology for example). Mind you, D 
 is a hindsight language, which makes it wiser. Does it have 
 flaws? Yes. I come across them sometimes. Is there a language 
 without flaws? If there is, tell me about it. Talking about 
 hindsight, I've tried many different languages, I like D 
 because of what it has to offer for general purpose 
 programming, it compiles natively, interfaces with C at no cost 
 at all, it has strong modelling power, features that users 
 require are added. I may sound like a zealot (see "irony"), but 
 I'm not. I'm very pragmatic, D is a good tool and, being 
 community driven, there is a real chance of making it a 
 fantastic tool. Individual features are not everything.


It should read It's more mature than _Go_ or Rust, of course.
Jul 11 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jul 11, 2014 at 04:54:39PM +0000, Chris via Digitalmars-d wrote:
[...]

 I remember Java used to be "theeee" best thing ever. After years of
 using it, however, I found out how restricted the language was / is.
 Still, it's been a success, because people believed all the
 propaganda. What matters to me is not so much the odd fancy feature,
 it's how well the language performs in general purpose programming.


[...]

I remember how I was skeptical of Java from day 1. Call me a cynic, but
everytime I hear something being overhyped, I immediately assign
whatever it is being hyped about as a second class product, and regard
it with suspicion. Same goes with cloud computing, which, as Nick likes
to say, is just marketing propaganda for "the internet".

When I finally got past the hype and tried out the language for myself,
I found the same thing you did: it's totally straitjacketed, and shoves
the OO idealogy down your throat even when it obviously doesn't fit. The
infamous long-winded "class MyLousyApp { public static void main(blah
blah blah) ... }" is a prime example of shoehorning something obviously
non-OO into an OO paradigm, just because we want to.  Not to mention
Java's verbosity, which is only tolerable with IDE support -- total
fail, in my book. I mean, hello, we're talking about a *language*
intended for *humans* to communicate with the computer? If we need
*another* program to help us elucidate this communication, something's
gone very, very wrong with the language. A language that needs a machine
to help you write, is by definition a language for communication between
*machines*, not between humans and machines.

Then there's the lack of generics until the n'th revision, and when it
finally came, it was lackluster (google for issues caused by type
erasure in Java sometime). D totally beats Java in this area IMO.

That's not to say that Java, the language, (as opposed to the class
library or the marketing hype) isn't a pretty good language. In fact,
it's quite a beautiful language -- in the idealistic, ivory tower,
detached-from-real-life sense of being a perfect specimen suitable for a
museum piece. Its disconnect from the messy real world, unfortunately,
makes it rather painful to use in real-life. Well, except with the help
of automated tools like IDEs and what-not, which makes one wonder, if we
need a machine to help us communicate with a machine, why not just write
assembly language instead? But I digress. :-P


[...]

 Mind you, D is a hindsight language, which makes it wiser. Does it
 have flaws? Yes. I come across them sometimes. Is there a language
 without flaws? If there is, tell me about it.


When I was still using C/C++ for my personal projects, the problems I
keep running into drove me to dream about what I'd like in an ideal
language. I tried writing my own, but didn't get very far -- not
everyone is a Walter Bright, after all. ;-) So I searched online instead
-- and found that D is the one language that's closest to my idea of
what an ideal language should be. There are some things about it that
aren't quite up to my ideals, but there are also many other areas where
it *exceeded* my ideals. So in spite of whatever warts or wrinkles D may
have, it's still the best language out there IMO.



 I'm very pragmatic, D is a good tool and, being community driven,
 there is a real chance of making it a fantastic tool.  Individual
 features are not everything.


Agreed, it's the synergy of multiple complementary features coming
together, that really makes the language shine. Templates + CTFE +
static if, is one example I can think of. Together, they make a total
killer combination in the world of metaprogramming IMO. I'm sure you can
think of several other synergistic combinations in D.


T

-- 
Claiming that your operating system is the best in the world because
more people use it is like saying McDonalds makes the best food in the
world. -- Carl B. Constantine
Jul 11 2014
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 11 July 2014 at 17:41:41 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 [...]

 Mind you, D is a hindsight language, which makes it wiser. 
 Does it
 have flaws? Yes. I come across them sometimes. Is there a 
 language
 without flaws? If there is, tell me about it.


 When I was still using C/C++ for my personal projects, the 
 problems I
 keep running into drove me to dream about what I'd like in an 
 ideal
 language. I tried writing my own, but didn't get very far -- not
 everyone is a Walter Bright, after all. ;-) So I searched 
 online instead
 -- and found that D is the one language that's closest to my 
 idea of
 what an ideal language should be. There are some things about 
 it that
 aren't quite up to my ideals, but there are also many other 
 areas where
 it *exceeded* my ideals. So in spite of whatever warts or 
 wrinkles D may
 have, it's still the best language out there IMO.


I went down a similar path. Always frustrated with existing 
languages. Then I accidentally discovered D and I knew that was 
it! It killed so many birds with one stone. Unicode, 
C-interfaceable (if that's a word), native compilation to begin 
with, then I discovered all the nice features and I've become a 
better programmer simply by trying to understand D. It gives me 
more freedom to put human thought into a computer, to model our 
world in terms a computer can understand, and not the other way 
around.

I still don't get why people who put up with other languages like 
Java and C++, and patiently wait years for simple improvements, 
say, when they see D, "it doesn't have xyz*, it's shit!" I just 
don't get it.

*(usually GC or thread related)
Jul 11 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 7/11/2014 1:40 PM, H. S. Teoh via Digitalmars-d wrote:

 On Fri, Jul 11, 2014 at 04:54:39PM +0000, Chris via Digitalmars-d wrote:
 [...]

 I remember Java used to be "theeee" best thing ever. After years of
 using it, however, I found out how restricted the language was / is.
 Still, it's been a success, because people believed all the
 propaganda. What matters to me is not so much the odd fancy feature,
 it's how well the language performs in general purpose programming.


 [...]

 I remember how I was skeptical of Java from day 1. Call me a cynic, but
 everytime I hear something being overhyped, I immediately assign
 whatever it is being hyped about as a second class product, and regard
 it with suspicion.


I tend to be like that even for non-computer stuff too, viewing 
whatever's popular with skepticism. Once in a while it'll backfire and 
keep me away from something I later realize is actually pretty decent, 
but I've found *usually* it serves me well. But then, my tastes tend to 
be uncommon *anyway*, so maybe that's why it works for me ;)


 Same goes with cloud computing, which, as Nick likes
 to say, is just marketing propaganda for "the internet".


Yes!!

"Cloud" drives me crazy more than any other word! It's the hipster word 
for "Internet", and it's EVERYWHERE.


 When I finally got past the hype and tried out the language for myself,
 I found the same thing you did: it's totally straitjacketed, and shoves
 the OO idealogy down your throat even when it obviously doesn't fit. The
 infamous long-winded "class MyLousyApp { public static void main(blah
 blah blah) ... }" is a prime example of shoehorning something obviously
 non-OO into an OO paradigm, just because we want to.  Not to mention
 Java's verbosity, which is only tolerable with IDE support -- total
 fail, in my book. I mean, hello, we're talking about a *language*
 intended for *humans* to communicate with the computer? If we need
 *another* program to help us elucidate this communication, something's
 gone very, very wrong with the language. A language that needs a machine
 to help you write, is by definition a language for communication between
 *machines*, not between humans and machines.


While I agree with all of that, there are two things I've always had to 
give Java credit for: It's classes and module system are what originally 
taught me that C/C++ aren't ideal and...umm...have some notable downsides...


 That's not to say that Java, the language, (as opposed to the class
 library or the marketing hype) isn't a pretty good language. In fact,
 it's quite a beautiful language -- in the idealistic, ivory tower,
 detached-from-real-life sense of being a perfect specimen suitable for a
 museum piece. Its disconnect from the messy real world, unfortunately,
 makes it rather painful to use in real-life.


Yea, that's one of the things that drew me to D. It came around saying 
(quite literally) "pragmatic language design" at exactly the time I was 
noticing how much of a pain ideology-driven and minimalist languages can be.
Jul 11 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jul 11, 2014 at 03:08:39PM -0400, Nick Sabalausky via Digitalmars-d
wrote:

 On 7/11/2014 1:40 PM, H. S. Teoh via Digitalmars-d wrote:


[...]

That's not to say that Java, the language, (as opposed to the class
library or the marketing hype) isn't a pretty good language. In fact,
it's quite a beautiful language -- in the idealistic, ivory tower,
detached-from-real-life sense of being a perfect specimen suitable
for a museum piece. Its disconnect from the messy real world,
unfortunately, makes it rather painful to use in real-life.


 
 Yea, that's one of the things that drew me to D. It came around saying
 (quite literally) "pragmatic language design" at exactly the time I
 was noticing how much of a pain ideology-driven and minimalist
 languages can be.


If you really wanna go minimalist, there's BF... :-P

On the other extreme of pragmatism, Larry Wall claims that the reason
Perl is useful is because it's a mess, which maps well to the problem
space, which is also a mess, which we call reality. :-P  I *will* say
that at one point I was quite enamored of Perl, but nowadays I think it
goes a little *too* far in the pragmatism, and as a result is rather
messy to work with.

One of the big advantages of D was that it's so easy to use when what
you need is something simple, so I've been writing quite a lot of little
script-like helper programs nowadays in D where in the past I would have
used Perl. Unlike Perl, though, D also scales up nicely when what was
initially a simple problem grows into a more complex problem. In Perl,
there's this threshold of complexity below which it's pretty comfortable
to use, but once you pass that point, the seams start to burst and the
potholes start to appear, a common sign of which is the appearance of
deeply-nested data structures that leads to riddle-like code such as:

	${a{b}{c}}->{$d->{e}}->{f} = ${g[h]{i}->{j}}->{k}[l]->{m};

along with the programming-by-convention that comes along with it.
Abstractions in Perl tend to be quite leaky, which is OK with write-once
throwaway-after scripts, but as the complexity of the program increases,
it becomes a source of frustration and hiding places for bugs.

In D, you simply leave the original script-like core as-is, then bring
in the proverbial big guns on top of it to deal with the growing
complexity, and the miracle is that the result is all nicely integrated
and water-tight. It's quite unlike any other programming language that
I've used before, in this respect.


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius
Jul 11 2014
prev sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 11 July 2014 at 19:08:43 UTC, Nick Sabalausky wrote:

 Yea, that's one of the things that drew me to D. It came around 
 saying (quite literally) "pragmatic language design" at exactly 
 the time I was noticing how much of a pain ideology-driven and 
 minimalist languages can be.


+1000

---
Paolo
Jul 12 2014
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2014-07-11 at 16:54 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]

 I remember Java used to be "theeee" best thing ever. After years=20
 of using it, however, I found out how restricted the language was=20
 / is. Still, it's been a success, because people believed all the=20
 propaganda. What matters to me is not so much the odd fancy=20
 feature, it's how well the language performs in general purpose=20
 programming. Go was designed for servers and thus will always=20
 have one up on D or any other language at that matter. But could=20
 I use Go for what I have used D? Not so sure about that. Also,=20
 like Java Go is a closed thing. D isn't. Once I read about D that=20
 it shows what can be done "once you take a language out of the=20
 hands of a committee". Go, like Java, will finally end up in a=20
 cul de sac and will have a hard time trying to get out of it. Not=20
 because the language is inherently bad, because it's in the hand=20
 of a committee. Ideology kills a language. But it doesn't matter,=20
 because people will use Go or whatever anyway, will _have_ to use=20
 it.


People believed the FORTRAN propaganda, the COBOL propaganda, the Pascal
propaganda. I think we ought to distinguish good marketing from hype.
Java had good marketing, was in the right place at the right time, and
had a huge amount of hype as well.

If Go is better for server things than D then might as well stop trying
to use D at all.

Go was actually designed as a better C with CSP for concurrency and
parallelism.

Go, D, Rust, C++, C, Haskell,=E2=80=A6 are all just programming languages t=
hat
create native code executable. Thus they are all in the same category
regarding potential usage. Everything else is about whether the
programmer likes and uses well, the language.

If Go and Java are closed languages, so is D. All three have open source
repositories and people can submit changes via pull requests. All three
have committees comprising the people who have commit rights to the
mainline and they are the only people who can actually change the
language.

I think I have to repeat the point about irony here regarding
ideology :-)


 What I'm taking issue with is that everybody focuses on the flaws=20
 of D (every language has flaws), which often gives the impression=20
 that it's an unfinished, stay-away business. It's not. D can be=20
 used, and I've used it, for production code. It's more mature=20
 than D or Rust and it is superior to other languages like Java=20
 (no OO-ideology for example). Mind you, D is a hindsight=20
 language, which makes it wiser. Does it have flaws? Yes. I come=20
 across them sometimes. Is there a language without flaws? If=20
 there is, tell me about it. Talking about hindsight, I've tried=20
 many different languages, I like D because of what it has to=20
 offer for general purpose programming, it compiles natively,=20
 interfaces with C at no cost at all, it has strong modelling=20
 power, features that users require are added. I may sound like a=20
 zealot (see "irony"), but I'm not. I'm very pragmatic, D is a=20
 good tool and, being community driven, there is a real chance of=20
 making it a fantastic tool. Individual features are not=20
 everything.


Go folk have exactly the same view and argument regarding Go. Java folk
have exactly the same view and argument regarding Java =E2=80=93 well excep=
t for
the compiles to native code bit, obviously. ;-)

In the end it is about community rather than the programming language
per se. Java created a huge community that was evangelical. Go has
rapidly created an active community that is evangelical. Python has
rapidly created a large evangelical community. D has slowly created a
small community that hasn't as yet created the outward looking
evangelical aspect. Where are the user groups having local meetings is
my main metric. Java definitely, Go definitely, C++ sort of, D no. This
is the real problem for D I feel. Without local user groups meeting up
you don't get exposure and you don't get traction in the market.

If there were more D users in the London area than one in London and one
in Brighton maybe we could start a London D User Group (LonDUG).
SkillsMatter would host.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 12 2014
next sibling parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via 
Digitalmars-d wrote:

 In the end it is about community rather than the programming 
 language
 per se. Java created a huge community that was evangelical. Go 
 has
 rapidly created an active community that is evangelical. Python 
 has
 rapidly created a large evangelical community. D has slowly 
 created a
 small community that hasn't as yet created the outward looking
 evangelical aspect. Where are the user groups having local 
 meetings is
 my main metric. Java definitely, Go definitely, C++ sort of, D 
 no. This
 is the real problem for D I feel. Without local user groups 
 meeting up
 you don't get exposure and you don't get traction in the market.


This seems like an outdated way of looking at things.  I've never 
attended a user group in my life, yet I've picked up several 
technologies since I left college a while back.  When I found out 
that such user groups existed, I thought they were kind of 
quaint, a remnant of pre-internet times.

As for an evangelical community, did C and C++ have those?  I 
don't think anyone was ever really evangelical about Obj-C as it 
took off over the last couple years, riding on the coattails of 
the meteoric rise of iOS.  Evangelism can help, but it can be 
more a sign of the evangelist's enthusiasm than a tech worth 
using.  Maybe D isn't ready for evangelism yet, there's something 
to be said for getting the product in gear before advertising it.

Not saying there's anything wrong with DUGs, higher bandwidth 
interaction and all, but the current approach of D developers 
giving talks at outside gatherings or putting DConf talks online 
seems like a much better way to spread the gospel to me.  
Certainly both can be done, I just wouldn't use DUGs as the main 
metric.

I've said it a couple times before, but it bears repeating: what 
D needs is a killer app.  Rails showed the ease of use of ruby.  
iOS made Obj-C a star.  D needs to show its utility by spawning a 
similar killer app, that's what will prove its worth in the 
market.  We can't know what that will be, but if D is any good, 
it will probably happen at some point.
Jul 12 2014
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
.On 12 July 2014 20:55, Joakim via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via Digitalmars-d
 wrote:

 In the end it is about community rather than the programming language
 per se. Java created a huge community that was evangelical. Go has
 rapidly created an active community that is evangelical. Python has
 rapidly created a large evangelical community. D has slowly created a
 small community that hasn't as yet created the outward looking
 evangelical aspect. Where are the user groups having local meetings is
 my main metric. Java definitely, Go definitely, C++ sort of, D no. This
 is the real problem for D I feel. Without local user groups meeting up
 you don't get exposure and you don't get traction in the market.



 This seems like an outdated way of looking at things.  I've never attended a
 user group in my life, yet I've picked up several technologies since I left
 college a while back.  When I found out that such user groups existed, I
 thought they were kind of quaint, a remnant of pre-internet times.

 As for an evangelical community, did C and C++ have those?  I don't think
 anyone was ever really evangelical about Obj-C as it took off over the last
 couple years, riding on the coattails of the meteoric rise of iOS.
 Evangelism can help, but it can be more a sign of the evangelist's
 enthusiasm than a tech worth using.  Maybe D isn't ready for evangelism yet,
 there's something to be said for getting the product in gear before
 advertising it.

 Not saying there's anything wrong with DUGs, higher bandwidth interaction
 and all, but the current approach of D developers giving talks at outside
 gatherings or putting DConf talks online seems like a much better way to
 spread the gospel to me.  Certainly both can be done, I just wouldn't use
 DUGs as the main metric.


We are social creatures, and the fact is that people just get more
done when they are in a room together.  The beer probably helps more
in agreeing also. ;-)



 I've said it a couple times before, but it bears repeating: what D needs is
 a killer app.  Rails showed the ease of use of ruby.  iOS made Obj-C a star.
 D needs to show its utility by spawning a similar killer app, that's what
 will prove its worth in the market.  We can't know what that will be, but if
 D is any good, it will probably happen at some point.


Killer... app... ugh, how evangelical.
Jul 12 2014
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Fri, 2014-07-11 at 16:54 +0000, Chris via Digitalmars-d 
 wrote:
 […]

 I remember Java used to be "theeee" best thing ever. After 
 years of using it, however, I found out how restricted the 
 language was / is. Still, it's been a success, because people 
 believed all the propaganda. What matters to me is not so much 
 the odd fancy feature, it's how well the language performs in 
 general purpose programming. Go was designed for servers and 
 thus will always have one up on D or any other language at 
 that matter. But could I use Go for what I have used D? Not so 
 sure about that. Also, like Java Go is a closed thing. D 
 isn't. Once I read about D that it shows what can be done 
 "once you take a language out of the hands of a committee". 
 Go, like Java, will finally end up in a cul de sac and will 
 have a hard time trying to get out of it. Not because the 
 language is inherently bad, because it's in the hand of a 
 committee. Ideology kills a language. But it doesn't matter, 
 because people will use Go or whatever anyway, will _have_ to 
 use it.


 People believed the FORTRAN propaganda, the COBOL propaganda, 
 the Pascal
 propaganda. I think we ought to distinguish good marketing from 
 hype.
 Java had good marketing, was in the right place at the right 
 time, and
 had a huge amount of hype as well.

 If Go is better for server things than D then might as well 
 stop trying
 to use D at all.

 Go was actually designed as a better C with CSP for concurrency 
 and
 parallelism.

 Go, D, Rust, C++, C, Haskell,… are all just programming 
 languages that
 create native code executable. Thus they are all in the same 
 category
 regarding potential usage. Everything else is about whether the
 programmer likes and uses well, the language.

 If Go and Java are closed languages, so is D. All three have 
 open source
 repositories and people can submit changes via pull requests. 
 All three
 have committees comprising the people who have commit rights to 
 the
 mainline and they are the only people who can actually change 
 the
 language.


But D is much more open to discussion and features are 
implemented faster, as far as I see. If I think about Java, that 
it took them ages to implement useful features like enumerations. 
Go ruled out templates, if I remember correctly. It's this kind 
of ideological / dictatorial attitude I don't like. Of course, 
Walter has the veto of death, it's his child after all. But there 
is far more flexibility. In the D community people listen to each 
other and trust each other's judgements and user experiences (or 
we wisely shut up, if they have no expertise on a certain topic).


 I think I have to repeat the point about irony here regarding
 ideology :-)


 What I'm taking issue with is that everybody focuses on the 
 flaws of D (every language has flaws), which often gives the 
 impression that it's an unfinished, stay-away business. It's 
 not. D can be used, and I've used it, for production code. 
 It's more mature than D or Rust and it is superior to other 
 languages like Java (no OO-ideology for example). Mind you, D 
 is a hindsight language, which makes it wiser. Does it have 
 flaws? Yes. I come across them sometimes. Is there a language 
 without flaws? If there is, tell me about it. Talking about 
 hindsight, I've tried many different languages, I like D 
 because of what it has to offer for general purpose 
 programming, it compiles natively, interfaces with C at no 
 cost at all, it has strong modelling power, features that 
 users require are added. I may sound like a zealot (see 
 "irony"), but I'm not. I'm very pragmatic, D is a good tool 
 and, being community driven, there is a real chance of making 
 it a fantastic tool. Individual features are not everything.


 Go folk have exactly the same view and argument regarding Go. 
 Java folk
 have exactly the same view and argument regarding Java – well 
 except for
 the compiles to native code bit, obviously. ;-)

 In the end it is about community rather than the programming 
 language
 per se. Java created a huge community that was evangelical. Go 
 has
 rapidly created an active community that is evangelical. Python 
 has
 rapidly created a large evangelical community. D has slowly 
 created a
 small community that hasn't as yet created the outward looking
 evangelical aspect. Where are the user groups having local 
 meetings is
 my main metric. Java definitely, Go definitely, C++ sort of, D 
 no. This
 is the real problem for D I feel. Without local user groups 
 meeting up
 you don't get exposure and you don't get traction in the market.


[snip]

You are right of course, but that was not my point at all. My 
point was that we have to stop the constant D-bashing. One flaw 
(or perceived flaw) is blown out of proportion and used to 
discard the language as useless, which it is not. What H.S. Teoh 
described is true, you can start with script like stuff in D and 
it scales later. I've been doing the same thing for a while now. 
I no longer use Python or the like, I just use D, and if it's 
just for a regex filter.

There are three things involved here, one is that people opposed 
to D are willing to put up with whatever flaws in other 
languages, but have no mercy when they detect a flaw in D, which 
leads us to point two: I suppose people don't "trust" D, because 
it has no big company behind it (so it cannot be good, it's not 
"authoritative", in other words D doesn't wear suit an tie). 
Third, we don't emphasize the good things about D enough (see H. 
S. Teoh's list). I can imagine that people are (ironically 
enough!) put off by D, because they think it is too difficult, 
too nerdy (cf. templates, ranges). It's true, it takes time to 
grasp some of D's more advanced features. But D can be used in a 
simple way for simple things (cf. script like programs). If 
someone is thinking about writing a program that does some number 
crunching in C (say for signal processing), why not use D instead 
of C or Python (God forbid!)? It can later be extended or 
improved. You don't need to be a rocket scientist to use D, it 
offers the same ease of use as Python. I think people are 
sometimes a bit scared to leave the comfort and security of the 
well-trodden path that languages like Python and Java seem to 
offer.

I think we need to address these issues, because they are of a 
psychological nature and not really language issues. I'm sure 
that if we fixed GC and had the best implementation ever, people 
would find something else to complain about "D doesn't have blah, 
I don't like it!"

That's basically what my post was all about.
Jul 14 2014
parent reply "Vic" <vic.cvc gmx.com> writes:
On Monday, 14 July 2014 at 10:13:43 UTC, Chris wrote:

 On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via


<snip>


 I think we need to address these issues, because they are of a 
 psychological nature and not really language issues. I'm sure 
 that if we fixed GC and had the best implementation ever, 
 people would find something else to complain about "D doesn't 
 have blah, I don't like it!"


<snip>

I'm sort of getting the idea that D goal would to be a better 
Java.

I'm running away from Java (after 10 years). I hope that someone 
at D has power and can say NO to a feature the way Linus does as 
opposed to adding more 'JCP' features, pushing such stuff 
downstream. Adding more features to be good at everything, aka a 
submarine that is a law mover. It's all done w/ best intentions. 
But forcing GC into base library of a system programing language? 
Maybe D is not a system programing language, but a enterprise app 
productivity lang. At least give us a choice, to use D why do I 
have to re-write the base lib.

Cheers, Vic
Jul 16 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 16.07.2014 17:39, schrieb Vic:

 On Monday, 14 July 2014 at 10:13:43 UTC, Chris wrote:

 On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via


 <snip>


 I think we need to address these issues, because they are of a
 psychological nature and not really language issues. I'm sure that if
 we fixed GC and had the best implementation ever, people would find
 something else to complain about "D doesn't have blah, I don't like it!"


 <snip>

 I'm sort of getting the idea that D goal would to be a better Java.

 I'm running away from Java (after 10 years). I hope that someone at D
 has power and can say NO to a feature the way Linus does as opposed to
 adding more 'JCP' features, pushing such stuff downstream. Adding more
 features to be good at everything, aka a submarine that is a law mover.
 It's all done w/ best intentions. But forcing GC into base library of a
 system programing language? Maybe D is not a system programing language,
 but a enterprise app productivity lang. At least give us a choice, to
 use D why do I have to re-write the base lib.

 Cheers, Vic


Yes, it has been done many times before.

Starting at Xerox PARC, those beautiful systems were many ideas of the 
modern web were pioneered.

Interlisp-D, Smalltalk and Mesa/Cedar, all had a mix of RC/GC.

Olivetti was playing around with Modula-3 with the SPIN OS, before 
Digital closed their R&D unit.

Niklaus Wirth and his colleagues created Oberon at the Swiss Federal 
Institute of Technology, which was an workable desktop OS used by a few 
at the informatics department and OS research topics, specially version 
System 3 with its gadgest toolkit. This spunned quite a few derivatives 
namely EthOS and AOS. Active Oberon on AOS already offered a concurrent 
compiler before that was a theme.


cancelled, many of its outcomes live on WP8 native compiler and on the 
upcoming .NET Native.

Apple is stating that Swift is a C replacement ("Swift is a successor to 
the C and Objective-C languages." - https://developer.apple.com/swift/).

We just need a successful mainstream OS vendor to push a RC/GC enabled 
systems language to anyone targeting their OS, to finally break the 
stigma that GC enabled systems programming languages don't leave the 
research lab.

--
Paulo
Jul 16 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 16 July 2014 at 17:18:11 UTC, Paulo Pinto wrote:

 Apple is stating that Swift is a C replacement ("Swift is a 
 successor to the C and Objective-C languages." - 
 https://developer.apple.com/swift/).


"Swift is an innovative new programming language for Cocoa and 
Cocoa Touch." and "Swift is a successor to the C and Objective-C 
languages. It includes low-level primitives such as types, flow 
control, and operators." Yes, that's low level!

Swift is Objective-C in a new dress, but not a system level 
programming language (and neither is Objective-C IMHO). It is an 
application level language for Cocoa frameworks.
Jul 16 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 16.07.2014 21:26, schrieb "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>":

 On Wednesday, 16 July 2014 at 17:18:11 UTC, Paulo Pinto wrote:

 Apple is stating that Swift is a C replacement ("Swift is a successor
 to the C and Objective-C languages." -
 https://developer.apple.com/swift/).


 "Swift is an innovative new programming language for Cocoa and Cocoa
 Touch." and "Swift is a successor to the C and Objective-C languages. It
 includes low-level primitives such as types, flow control, and
 operators." Yes, that's low level!

 Swift is Objective-C in a new dress, but not a system level programming
 language (and neither is Objective-C IMHO). It is an application level
 language for Cocoa frameworks.


Just like ANSI C without the usual set of language extensions.

Having done system programming in Turbo Pascal and Oberon, I guess I 
don't seek C like features in system programming languages.

--
Paulo
Jul 16 2014
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2014-07-11 at 10:40 -0700, H. S. Teoh via Digitalmars-d wrote:
[=E2=80=A6]

 When I finally got past the hype and tried out the language for myself,
 I found the same thing you did: it's totally straitjacketed, and shoves
 the OO idealogy down your throat even when it obviously doesn't fit. The
 infamous long-winded "class MyLousyApp { public static void main(blah
 blah blah) ... }" is a prime example of shoehorning something obviously
 non-OO into an OO paradigm, just because we want to.  Not to mention
 Java's verbosity, which is only tolerable with IDE support -- total
 fail, in my book. I mean, hello, we're talking about a *language*
 intended for *humans* to communicate with the computer? If we need
 *another* program to help us elucidate this communication, something's
 gone very, very wrong with the language. A language that needs a machine
 to help you write, is by definition a language for communication between
 *machines*, not between humans and machines.


Java is not an object-oriented language in the Smalltalk, C++, Python
sense of object-oriented.=20

Picking out the main entry boilerplate is a wee bit unfair. Though
Groovy, Kotlin and Ceylon have added top-level functions again by
finding compilation strategies, and Scala has created the App class
which does something similar.

You comment about programming languages applies equally well to C++, Go,
Python, Rust, D, etc. as it does to Java.


 Then there's the lack of generics until the n'th revision, and when it
 finally came, it was lackluster (google for issues caused by type
 erasure in Java sometime). D totally beats Java in this area IMO.


I think it may just be Stockholm Syndrome, but some notable people whose
opinions I generally trust, are now saying that type erasure in Java is

and enforce reification of type parameters in the underlying machine,
JVM and CLR respectively.


 That's not to say that Java, the language, (as opposed to the class
 library or the marketing hype) isn't a pretty good language. In fact,
 it's quite a beautiful language -- in the idealistic, ivory tower,
 detached-from-real-life sense of being a perfect specimen suitable for a
 museum piece. Its disconnect from the messy real world, unfortunately,
 makes it rather painful to use in real-life. Well, except with the help
 of automated tools like IDEs and what-not, which makes one wonder, if we
 need a machine to help us communicate with a machine, why not just write
 assembly language instead? But I digress. :-P


Now this is mis-direction. Java is a real-world language in that it is
used in the real world. Whilst there are many using Java because they
know no better, many are using it out of choice. Java evolves with the
needs of the users prepared to get involved in evolving the language.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 12 2014
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 12 Jul 2014 11:38:08 +0100
schrieb Russel Winder via Digitalmars-d
<digitalmars-d puremagic.com>:


 That's not to say that Java, the language, (as opposed to the class
 library or the marketing hype) isn't a pretty good language. In fact,
 it's quite a beautiful language -- in the idealistic, ivory tower,
 detached-from-real-life sense of being a perfect specimen suitable for a
 museum piece. Its disconnect from the messy real world, unfortunately,
 makes it rather painful to use in real-life. Well, except with the help
 of automated tools like IDEs and what-not, which makes one wonder, if we
 need a machine to help us communicate with a machine, why not just write
 assembly language instead? But I digress. :-P


=20
 Now this is mis-direction. Java is a real-world language in that it is
 used in the real world. Whilst there are many using Java because they
 know no better, many are using it out of choice. Java evolves with the
 needs of the users prepared to get involved in evolving the language.


Yes, Java is verbose, but its modularity makes it very
flexible. The classic example is how you read lines of text
from a file. Instead of a special class for that, you take
use simple primitives with descriptive names and assemble
something that reads lines of UTF-8 text from a buffer that
has a file as its input. It actually acknowledges quite a bit
of real-world mess when you look at it, for example different
encodings on stdin and stdout.
Conventions like beans, where every property is implemented as
a pair of getter/setter or naming rules like ...Adapter,
...Comparator make it easy to reflect on unknown code.
On the one hand it is limiting to only have Java OOP in the
toolbox, on the other hand it is cheap to train someone on
Java and Java libraries and actually not a horror to try and
make sense of other people's code, because it wont be
implemented in any of 5 different paradigms + s.o.'s personal
naming conventions.
I've never been a fan of developing in vi or emacs and as far
as I am concerned, a programming language need not be designed
like a human language. There are many graphical programming
environments as well, for example for physics.
The simpler the language the more robust the refactoring tools
can become. The more conventions are in use, the better custom
tailored tools and IDEs can emerge. I.e. in Eclipse you only
type the capital letters of a long class name and have the
auto-completion figure out which class in scope or available
import paths matches these "initials". Heck, it even fills in
the parameters when you call a method using the available
variables in scope. If you were unaware that you need a third
argument, the IDE can generate a new variable with a name
based on the method parameter or place a constructor call for
the required type.
Sometimes you can just focus on the program logic and have the

expose properties of GUI objects in tables and generate the
code for event handlers on double-clicks. It saves time, you
cannot misspell anything... I like it.

--=20
Marco
Aug 25 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Monday, 25 August 2014 at 07:47:45 UTC, Marco Leise wrote:

 Am Sat, 12 Jul 2014 11:38:08 +0100
 schrieb Russel Winder via Digitalmars-d
 <digitalmars-d puremagic.com>:


 That's not to say that Java, the language, (as opposed to 
 the class
 library or the marketing hype) isn't a pretty good language. 
 In fact,
 it's quite a beautiful language -- in the idealistic, ivory 
 tower,
 detached-from-real-life sense of being a perfect specimen 
 suitable for a
 museum piece. Its disconnect from the messy real world, 
 unfortunately,
 makes it rather painful to use in real-life. Well, except 
 with the help
 of automated tools like IDEs and what-not, which makes one 
 wonder, if we
 need a machine to help us communicate with a machine, why 
 not just write
 assembly language instead? But I digress. :-P


 
 Now this is mis-direction. Java is a real-world language in 
 that it is
 used in the real world. Whilst there are many using Java 
 because they
 know no better, many are using it out of choice. Java evolves 
 with the
 needs of the users prepared to get involved in evolving the 
 language.


 Yes, Java is verbose, but its modularity makes it very
 flexible. The classic example is how you read lines of text
 from a file. Instead of a special class for that, you take
 use simple primitives with descriptive names and assemble
 something that reads lines of UTF-8 text from a buffer that
 has a file as its input. It actually acknowledges quite a bit
 of real-world mess when you look at it, for example different
 encodings on stdin and stdout.
 Conventions like beans, where every property is implemented as
 a pair of getter/setter or naming rules like ...Adapter,
 ...Comparator make it easy to reflect on unknown code.
 On the one hand it is limiting to only have Java OOP in the
 toolbox, on the other hand it is cheap to train someone on
 Java and Java libraries and actually not a horror to try and
 make sense of other people's code, because it wont be
 implemented in any of 5 different paradigms + s.o.'s personal
 naming conventions.
 I've never been a fan of developing in vi or emacs and as far
 as I am concerned, a programming language need not be designed
 like a human language. There are many graphical programming
 environments as well, for example for physics.
 The simpler the language the more robust the refactoring tools
 can become. The more conventions are in use, the better custom
 tailored tools and IDEs can emerge. I.e. in Eclipse you only
 type the capital letters of a long class name and have the
 auto-completion figure out which class in scope or available
 import paths matches these "initials". Heck, it even fills in
 the parameters when you call a method using the available
 variables in scope. If you were unaware that you need a third
 argument, the IDE can generate a new variable with a name
 based on the method parameter or place a constructor call for
 the required type.
 Sometimes you can just focus on the program logic and have the

 expose properties of GUI objects in tables and generate the
 code for event handlers on double-clicks. It saves time, you
 cannot misspell anything... I like it.


The main thing that put me off Java was not so much the fact that 
you're restricted to OOP and that it's verbose etc., but that it 
caused all sorts of problems when shipping the actual programs. 
"Write once run everywhere" is a myth, if you ask me. D is much 
closer to that than Java. In the end we encountered so many 
problems that I dumped Java for cross platform development (and 
for development in general). Nobody in the Java world ever talks 
about this, but cross platform doesn't really work (apart from 
running simple programs).

But the points you made about IDE's and naming conventions etc. 
are good points insofar as they explain why Java was embraced by 
the industry. It's a bit of a no-brainer, people just have to 
follow the same well trodden path, which in turn enables 
companies to train people fast (= cheap) and to hire loads of 
intermediate (and in some cases mediocre) programmers whom they 
pay less, of course.
Aug 25 2014
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2014-08-25 at 09:01 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]

 The main thing that put me off Java was not so much the fact that=20
 you're restricted to OOP and that it's verbose etc., but that it=20
 caused all sorts of problems when shipping the actual programs.=20
 "Write once run everywhere" is a myth, if you ask me. D is much=20
 closer to that than Java. In the end we encountered so many=20
 problems that I dumped Java for cross platform development (and=20
 for development in general). Nobody in the Java world ever talks=20
 about this, but cross platform doesn't really work (apart from=20
 running simple programs).


[=E2=80=A6]

Java is not really an object-oriented programming language. OK it has
classes, inheritance, and method calls, but it is not founded on message
passing. For example:

	a + b

is not a message in Java as it is in C++, Python, etc.

Write Once Run Anywhere (WORA) has been a known fallacy since about
1995 ;-) Versions of things really are a bit of a
dependency/configuration nightmare. Maven Central and Gradle help
somewhat for the JVM, but then there is the shared library nightmare for
all other platforms.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 25 2014
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/25/2014 12:53 PM, Russel Winder via Digitalmars-d wrote:

 For example:

 	a + b

 is not a message in Java as it is in C++,  ...


error: member reference base type 'int' is not a structure or union
int main(){ (1).operator+(2); }
             ~~~^~~~~~~~~
Aug 25 2014
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On 25.08.2014 13:53, Russel Winder via Digitalmars-d wrote:

 On Mon, 2014-08-25 at 09:01 +0000, Chris via Digitalmars-d wrote:
 […]

 The main thing that put me off Java was not so much the fact that
 you're restricted to OOP and that it's verbose etc., but that it
 caused all sorts of problems when shipping the actual programs.
 "Write once run everywhere" is a myth, if you ask me. D is much
 closer to that than Java. In the end we encountered so many
 problems that I dumped Java for cross platform development (and
 for development in general). Nobody in the Java world ever talks
 about this, but cross platform doesn't really work (apart from
 running simple programs).


 […]

 Java is not really an object-oriented programming language. OK it has
 classes, inheritance, and method calls, but it is not founded on message
 passing. For example:

 	a + b

 is not a message in Java as it is in C++, Python, etc.


Since when does C++ does support message passing?


 Write Once Run Anywhere (WORA) has been a known fallacy since about
 1995 ;-) Versions of things really are a bit of a
 dependency/configuration nightmare. Maven Central and Gradle help
 somewhat for the JVM, but then there is the shared library nightmare for
 all other platforms.


It is surely way better than the alternatives, specially if one 
remembers the chaos of writing portable code in C or C++ back when Java 
apperead.


On those days I was writing "portable" code across UNIX systems and 
discovering that POSIX isn't as portable as it gets sold by. The real 
fun was between the K&R C, ANSI C and pre-standard C++ support across 
compilers.

--
Paulo
Aug 25 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 25 August 2014 at 13:51:25 UTC, Paulo Pinto wrote:

 It is surely way better than the alternatives, specially if one 
 remembers the chaos of writing portable code in C or C++ back 
 when Java apperead.


Yeah, Flash and javascript are the kings of portable programming.
Then you have the scripting languages (python,perl,tcl/tk…).
Then you have Java.
Then you have Qt, etc

Compiled languages come far down on the list.

HTML5 will remain the king I believe, since OS upgrades can nuke 
any compiled program and HTML5 capable browsers are distributed 
with the OS.
Aug 25 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 25 Aug 2014 16:51:23 +0300
Paulo Pinto via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Since when does C++ does support message passing?


since people started to think that "OOP was invented in C++".
Aug 25 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 25 August 2014 at 14:05:35 UTC, ketmar via 
Digitalmars-d wrote:

 On Mon, 25 Aug 2014 16:51:23 +0300
 Paulo Pinto via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 Since when does C++ does support message passing?


 since people started to think that "OOP was invented in C++".


The terminology "message" for "method" comes from Smalltalk. It 
is used liberally.

C++ is using the OOP model of SIMULA, which did invent OOP! So 
I'd say the way C++ does OOP is how it was invented.

SIMULA was created by Kristen Nygaard and Ole-Johan Dahl. Nygaard 
was very much interested in object-oriented modelling and as a 
mode of thinking about problems. Not only in programming. Dahl 
went on to work on formal program verification. I had them as 
lecturers at the university. Very interesting people.
Aug 25 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 25 Aug 2014 14:15:09 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 C++ is using the OOP model of SIMULA, which did invent OOP! So=20
 I'd say the way C++ does OOP is how it was invented.


and Smalltalk does OOP the way it should be done. ;-)
Aug 25 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 25 August 2014 at 14:27:55 UTC, ketmar via 
Digitalmars-d wrote:

 On Mon, 25 Aug 2014 14:15:09 +0000
 via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 C++ is using the OOP model of SIMULA, which did invent OOP! So 
 I'd say the way C++ does OOP is how it was invented.


 and Smalltalk does OOP the way it should be done. ;-)


I haven't used Smalltalk, but can't say it looks pretty… But I 
probably shouldn't judge by looks, it is the personality that 
counts!

The SIMULA model was later refined in Beta which was minimalistic 
in the same vein as Self. In Beta everything is an object, even 
functions and blocks (which could be specialized). And virtual 
functions are evaluated from superclasses down to subclasses so 
that the superclass is encapsulating the subclass in a similar 
way to how the "with" statement works.

Beta had virtual class definitions and type variables so that you 
could let a subclass specialize the types that was instantiated 
in the superclass in a subclass.

D does seem to lack type variables? So it is quite static in 
comparison.
Aug 25 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 25 Aug 2014 14:41:46 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 D does seem to lack type variables? So it is quite static in=20
 comparison.


the problem with "overly dynamic" languages like Smalltalk (and
especially Self) is that it's insanely hard to write an efficient
compiler which generates fast machine code. JIT compilation,
polymorphic inline caching and alot of other techniques allows this
languages to work with "acceptable speed", but primitive C compiler with
peephole optimizer can beat 'em easily.

D is aimed to generate efficient machine code, so it must be "static".
we can emulate dynamic calls with AA and opDispatch, but this will
be... not fast. ;-)
Aug 25 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 25 August 2014 at 14:54:33 UTC, ketmar via 
Digitalmars-d wrote:

 D is aimed to generate efficient machine code, so it must be 
 "static".
 we can emulate dynamic calls with AA and opDispatch, but this 
 will
 be... not fast. ;-)


Beta was static and compiled directly to asm. That does not 
preclude dynamism such as type variables, hidden parent pointers 
(where the object instanced from) and a rich set of virtual 
bindings and the ability to specialize everwhere.

Examples:

- a type variable is essentially just a pointer to a 
typeinfo-block with constructors and meta information.

- a virtual type specification is just a type variable that is 
constrained to a class hierarchy.

- to have specialization everywhere you just add the capability 
to have unnamed types

Ola
Aug 25 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 25 Aug 2014 16:08:52 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Beta was static and compiled directly to asm.


it's not hard to compile dynamic language to native code. what is hard
is to make this code fast. this requires very sofisticated compiler
which can eliminate as much indirect calls as possible. that's why we
have the ability to create non-virtual methods in languages like D or
C++. "everything is object" is a nice concept, but it has it's price.
Aug 25 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 25 August 2014 at 16:26:19 UTC, ketmar via 
Digitalmars-d wrote:

 is to make this code fast. this requires very sofisticated 
 compiler
 which can eliminate as much indirect calls as possible. that's 
 why we
 have the ability to create non-virtual methods in languages 
 like D or
 C++. "everything is object" is a nice concept, but it has it's 
 price.


You need whole program analysis to get the most out of it. Just 
about everything can be replaced by LUTs or switches.

If you look at real code very little of the kind of dynamic 
programs you write in languages like Python and Ruby actually are 
dynamic in nature.

Sure, there are examples of the opposite, but I think that is 
more in the line of "eclectic programming" than "useful 
programming".

I think the whole separate compilation idea is going to be old 
fashioned real soon now. It makes little sense to not have the 
build system as a service run on a cluster and the program as a 
database with builtin versioning.

Why recompile the whole file when only a tiny function should be 
according to the dependencies?
Aug 25 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 25 Aug 2014 16:33:00 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I think the whole separate compilation idea is going to be old=20
 fashioned real soon now. It makes little sense to not have the=20
 build system as a service run on a cluster and the program as a=20
 database with builtin versioning.


but i don't want to buy and setup 42 servers in my room just to compile
"hello world"! ;-)

and no, i will not buy all that modern BS about "clouds".


 Why recompile the whole file when only a tiny function should be=20
 according to the dependencies?


i forgot the language, but i clearly seen something like that. database
demon which keeping either sources or AST (i don't remember) and
compiler which uses that info. it was... strange, but interesting.
Aug 25 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Tuesday, 26 August 2014 at 04:03:17 UTC, ketmar via 
Digitalmars-d wrote:

 On Mon, 25 Aug 2014 16:33:00 +0000
 via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I think the whole separate compilation idea is going to be old 
 fashioned real soon now. It makes little sense to not have the 
 build system as a service run on a cluster and the program as 
 a database with builtin versioning.


 but i don't want to buy and setup 42 servers in my room just to 
 compile
 "hello world"! ;-)


You won't, your single home computer will be enough for small 
programs.  But if your code ever grows large enough to benefit 
from a cluster, you'll just sign up for an account online and you 
tools will automatically start sending your diffs to the remote 
cluster and compiling the code there.


 and no, i will not buy all that modern BS about "clouds".


It is amazing that the "cloud" is being applied to a host of 
problems, but not really to speed up building software yet.  Of 
course, there's a bunch of giant corporations, like Facebook or 
Google, putting their own private "clouds" to such uses, but the 
vast majority of programmers just use a powerful workstation 
instead, the old '80s model of software development.  That will 
change.

It's not that you can't roll your own and do it on AWS right now, 
it just isn't dead simple to do it off the shelf, so most don't.  
And of course test runs have been increasingly pushed into these 
remote clusters.  Other than a few devs with privacy and security 
concerns, most will move to such a "cloud" model in the coming 
years.
Aug 25 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 26 Aug 2014 05:59:45 +0000
Joakim via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Other than a few devs with privacy and security concerns


it's about me. ;-)
Aug 25 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 8/25/14, 1:26 PM, ketmar via Digitalmars-d wrote:

 On Mon, 25 Aug 2014 16:08:52 +0000
 via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Beta was static and compiled directly to asm.


 it's not hard to compile dynamic language to native code. what is hard
 is to make this code fast. this requires very sofisticated compiler
 which can eliminate as much indirect calls as possible. that's why we
 have the ability to create non-virtual methods in languages like D or
 C++. "everything is object" is a nice concept, but it has it's price.


Not at all. In Crystal everything is an object, it compiles to native 
code and it's super fast. All methods are virtual (and there's actually 
no way to make a method non-virtual).

The trick is to not use virtual tables, but do multiple dispatch (or 
only use virtual tables when needed). If you have:

a = Foo.new
a.some_method

then it's obvious to the compiler that some_method belongs to Foo: no 
virtual call involved, no virtual table lookup, etc: just a direct call.

If you have:

x = 1.abs

1 is still an object, only it's memory representation is 32 bits, and 
the method turns out to be just like a function call.

To me, the real problem with OOP is to automatically relate it to 
virtual tables, interfaces, etc.
Aug 25 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 25 Aug 2014 14:36:21 -0300
Ary Borenszweig via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 The trick is to not use virtual tables, but do multiple dispatch (or=20
 only use virtual tables when needed). If you have:
=20
 a =3D Foo.new
 a.some_method


such simple code analysis easily confused by function calls. or we have
to analyse function body at each call and instantiate parameterised
functions. ah, hello, interprocedural analysis. and what if function is
in another module? ah, hello, full program analysis. and bye-bye,
compilation speed.


 To me, the real problem with OOP is to automatically relate it to=20
 virtual tables, interfaces, etc.


i myself thinking about message passing when i see OOP mentioned. ;-)
Aug 25 2014
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 25 August 2014 at 14:54:33 UTC, ketmar via 
Digitalmars-d wrote:

 On Mon, 25 Aug 2014 14:41:46 +0000
 via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 D does seem to lack type variables? So it is quite static in 
 comparison.


 the problem with "overly dynamic" languages like Smalltalk (and
 especially Self) is that it's insanely hard to write an 
 efficient
 compiler which generates fast machine code. JIT compilation,
 polymorphic inline caching and alot of other techniques allows 
 this
 languages to work with "acceptable speed", but primitive C 
 compiler with
 peephole optimizer can beat 'em easily.

 D is aimed to generate efficient machine code, so it must be 
 "static".
 we can emulate dynamic calls with AA and opDispatch, but this 
 will
 be... not fast. ;-)


May be, but JIT were created thanks to Lisp and Smalltalk.

In Smalltalk's case, the genesis to Java Hotspot JIT, lies in 
this paper,

http://dl.acm.org/citation.cfm?id=894616

--
Paulo
Aug 25 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 25 Aug 2014 17:50:35 +0000
Paulo Pinto via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 May be, but JIT were created thanks to Lisp and Smalltalk.


i know that. i'm interested in JIT developement and know about Self,
Strongtalk and other strange words. ;-)

and i really hate SUN for practically killing Strongtalk. Java sux and
Strongtalk is dead. loose-loose.
Aug 25 2014
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 25 August 2014 at 14:41:48 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 25 August 2014 at 14:27:55 UTC, ketmar via 
 Digitalmars-d wrote:

 On Mon, 25 Aug 2014 14:15:09 +0000
 via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 C++ is using the OOP model of SIMULA, which did invent OOP! 
 So I'd say the way C++ does OOP is how it was invented.


 and Smalltalk does OOP the way it should be done. ;-)


 I haven't used Smalltalk, but can't say it looks pretty… But I 
 probably shouldn't judge by looks, it is the personality that 
 counts!


Smalltalk is great, specially as operating system.

I used SmalltalkWorks, before Java was concieved.

It was the closest I ever been of the Xerox PARC OS experience.

The UNIX CLI experience is nothing, compared to the possibility 
to touch the whole system and use any public class/method on your 
scripts (transcript).

My second experience with such enviroments was with Oberon, Wirth 
based his work on Mesa/Cedar. Imagine just having dynamic 
loadable modules as executables. All exported functions could be 
used in the REPL, applied to OS widgets or user selections, 
depending on the signature.

--
Paulo
Aug 25 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/25/2014 2:01 AM, Chris wrote:

 The main thing that put me off Java was not so much the fact that you're
 restricted to OOP and that it's verbose etc., but that it caused all sorts of
 problems when shipping the actual programs. "Write once run everywhere" is a
 myth, if you ask me. D is much closer to that than Java. In the end we
 encountered so many problems that I dumped Java for cross platform development
 (and for development in general). Nobody in the Java world ever talks about
 this, but cross platform doesn't really work (apart from running simple
programs).


I haven't ported much Java code, but I have found D code to be significantly 
easier to port than C++.

The varying sizes of basic types in C++ is what causes most of the problems.
Aug 25 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 26 August 2014 at 05:58:36 UTC, Walter Bright wrote:

 On 8/25/2014 2:01 AM, Chris wrote:

 The main thing that put me off Java was not so much the fact 
 that you're
 restricted to OOP and that it's verbose etc., but that it 
 caused all sorts of
 problems when shipping the actual programs. "Write once run 
 everywhere" is a
 myth, if you ask me. D is much closer to that than Java. In 
 the end we
 encountered so many problems that I dumped Java for cross 
 platform development
 (and for development in general). Nobody in the Java world 
 ever talks about
 this, but cross platform doesn't really work (apart from 
 running simple programs).


 I haven't ported much Java code, but I have found D code to be 
 significantly easier to port than C++.

 The varying sizes of basic types in C++ is what causes most of 
 the problems.


The problem was that Java didn't behave as expected on Windows. 
Things that worked fine on Linux and OS X didn't work on Windows 
(even simple things like deleting files). User reported all sorts 
of problems, one of them being that the Java Access Bridge didn't 
work. Why, nobody knows. The lack of a proper sound API / 
library. Then there was the versioning hell with JRE/JVM and 
having to tell users what version they had to download (the non 
tech savvy crowd). I know that MS doesn't make it easy for Java 
either. Well, I could have sorted the problems out with Java web 
start, SWT and all that kind of stuff. Instead, I learned D which 
I can compile and run on each platform without a problem.

In my opinion, if a technology like Java needs so many crutches 
to make it work on different platforms, then it's useless for 
cross-platform development. Also, once you need interaction with 
the system or other (native) applications, then it becomes 
frustrating pretty soon. D solved all these problems for me and 
more, in fact it helped me to design a better product, because it 
opened doors for me as regards both programming patterns and 
interaction with the system and various libraries. That there are 
other languages with which I could have achieved similar things, 
I do not doubt. But I do doubt that it would have been so easy, 
and the fact that new languages that aim for what D already 
stands for are still being invented (cf. Nimrod) shows that 

programmers' demands yet.
Aug 26 2014
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-08-26 at 08:46 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]

 The problem was that Java didn't behave as expected on Windows.=20
 Things that worked fine on Linux and OS X didn't work on Windows=20
 (even simple things like deleting files). User reported all sorts=20
 of problems, one of them being that the Java Access Bridge didn't=20
 work. Why, nobody knows. The lack of a proper sound API /=20
 library. Then there was the versioning hell with JRE/JVM and=20
 having to tell users what version they had to download (the non=20
 tech savvy crowd). I know that MS doesn't make it easy for Java=20
 either. Well, I could have sorted the problems out with Java web=20
 start, SWT and all that kind of stuff. Instead, I learned D which=20
 I can compile and run on each platform without a problem.


If your users are having to install things then the problem is your
deployment mechanism not the JVM dependency hell system. Java
deployments are actually really quite easy. Either you package a total
system with all dependencies and provide entry scripts, or you use Maven
Central (or increasingly BinTray) for accessing dependencies. This is
not to say there are not portability and dependency problems, there are,
but it is good to blame the right reason at the right time.

I am surprised by the platform dependency problem you cite. Yes there
are platform issues with the Java Platform but I had thought all the
ones you are alluding to were fixed by Java 1.4.2.

Media APIs for Java have always been a bit of a pain. With any luck
JavaFX, and the far more important GroovyFX, will cause a resurgence of
interest in media APIs on the Java Platform, and this time get them
right.


 In my opinion, if a technology like Java needs so many crutches=20
 to make it work on different platforms, then it's useless for=20
 cross-platform development. Also, once you need interaction with=20
 the system or other (native) applications, then it becomes=20
 frustrating pretty soon. D solved all these problems for me and=20
 more, in fact it helped me to design a better product, because it=20
 opened doors for me as regards both programming patterns and=20
 interaction with the system and various libraries. That there are=20
 other languages with which I could have achieved similar things,=20
 I do not doubt. But I do doubt that it would have been so easy,=20
 and the fact that new languages that aim for what D already=20
 stands for are still being invented (cf. Nimrod) shows that=20

 programmers' demands yet.


I am pleased D is working for you when you feel Java didn't at that
time. Things move on though: what may have been true about Java then may
not be now. Decisions must always be being reassessed after a while. All
languages have some platform dependent issues unless they are only
working on only a single platform. Java, Python, Ruby, etc. generally
depend on the virtual machine and support libraries to get things right,
but allowing platform dependent application code as well. C, C++, etc.
put essentially all of the portability issues into the programmers hands
and hence lots of build sophistication or #if.

Then there is the dynamic link library problem creating a mass of pain.

D and Go ran away from this by having statically linked code only, at
the expense of 2=E2=80=9310MB executables!

With shared libraries becoming an issue in D again, that set of
dependency and platform problems will raise their heads.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 26 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 26 August 2014 at 09:45:15 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Tue, 2014-08-26 at 08:46 +0000, Chris via Digitalmars-d 
 wrote:
 […]

 The problem was that Java didn't behave as expected on 
 Windows. Things that worked fine on Linux and OS X didn't work 
 on Windows (even simple things like deleting files). User 
 reported all sorts of problems, one of them being that the 
 Java Access Bridge didn't work. Why, nobody knows. The lack of 
 a proper sound API / library. Then there was the versioning 
 hell with JRE/JVM and having to tell users what version they 
 had to download (the non tech savvy crowd). I know that MS 
 doesn't make it easy for Java either. Well, I could have 
 sorted the problems out with Java web start, SWT and all that 
 kind of stuff. Instead, I learned D which I can compile and 
 run on each platform without a problem.


 If your users are having to install things then the problem is 
 your
 deployment mechanism not the JVM dependency hell system. Java
 deployments are actually really quite easy. Either you package 
 a total
 system with all dependencies and provide entry scripts, or you 
 use Maven
 Central (or increasingly BinTray) for accessing dependencies.


If I need deployment mechanisms like the ones above, then there's 
something wrong with the language. All these crutches and 
patches. To set up and test a deployment mechanism takes as long 
as writing the program. No thank you.


 This is
 not to say there are not portability and dependency problems, 
 there are,
 but it is good to blame the right reason at the right time.


See answer above.


 I am surprised by the platform dependency problem you cite. Yes 
 there
 are platform issues with the Java Platform but I had thought 
 all the
 ones you are alluding to were fixed by Java 1.4.2.


It was long after 1.4.2.


 Media APIs for Java have always been a bit of a pain. With any 
 luck
 JavaFX, and the far more important GroovyFX, will cause a 
 resurgence of
 interest in media APIs on the Java Platform, and this time get 
 them
 right.


"With some luck". I can't wait that long. That's exactly what I 
mean: you have to wait ages and hope and pray that you can write 
a useful program someday. No thanks. With D I grabbed existing 
C/C++ audio frameworks and moved on to more important issues.


 In my opinion, if a technology like Java needs so many 
 crutches to make it work on different platforms, then it's 
 useless for cross-platform development. Also, once you need 
 interaction with the system or other (native) applications, 
 then it becomes frustrating pretty soon. D solved all these 
 problems for me and more, in fact it helped me to design a 
 better product, because it opened doors for me as regards both 
 programming patterns and interaction with the system and 
 various libraries. That there are other languages with which I 
 could have achieved similar things, I do not doubt. But I do 
 doubt that it would have been so easy, and the fact that new 
 languages that aim for what D already stands for are still 
 being invented (cf. Nimrod) shows that existing mainstream 

 demands yet.


 I am pleased D is working for you when you feel Java didn't at 
 that
 time. Things move on though: what may have been true about Java 
 then may
 not be now. Decisions must always be being reassessed after a 
 while.


Why on earth should I reassess this decision now? D works for 
_me_ (maybe not for everybody). Why should I rewrite the whole 
thing in Java or use Java for new projects, when I know there are 
still issues that are absolute deal breakers for me (like the 
sound API)? Java is just not a good language to write 
cross-platform programs that have to be integrated into the 
system or (native) 3rd party applications. So why bother?


 All
 languages have some platform dependent issues unless they are 
 only
 working on only a single platform. Java, Python, Ruby, etc. 
 generally
 depend on the virtual machine and support libraries to get 
 things right,
 but allowing platform dependent application code as well. C, 
 C++, etc.
 put essentially all of the portability issues into the 
 programmers hands
 and hence lots of build sophistication or #if.


At least you have control over it.


 Then there is the dynamic link library problem creating a mass 
 of pain.

 D and Go ran away from this by having statically linked code 
 only, at
 the expense of 2–10MB executables!


I have no problem with that, still better than delivering a 40 MB 
Java package for an otherwise tiny plug-in. The DLL I have in D 
is 855.6 kB, the whole package with libs and various resource 
files is ~4.2 MB download size as zip and ~8 MB when installed.


 With shared libraries becoming an issue in D again, that set of
 dependency and platform problems will raise their heads.
Aug 26 2014
parent reply Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com> writes:
 If your users are having to install things then the problem is your
 deployment mechanism not the JVM dependency hell system. Java
 deployments are actually really quite easy. Either you package a total
 system with all dependencies and provide entry scripts, or you use Maven
 Central (or increasingly BinTray) for accessing dependencies.


 If I need deployment mechanisms like the ones above, then there's
 something wrong with the language. All these crutches and patches. To set
 up and test a deployment mechanism takes as long as writing the program. No
 thank you.




This is what you get with shared libraries.  If you don't want to deal with
dependencies, either A) ship a static-linked binary or B) cross your
fingers and pray.

I've found the java ecosystem to be quite well fleshed out and mature in
handling lib/jar dependencies, such that it was an unpleasant shock dealing
with C++ after years away.  Using maven, for instance, is a quick and easy
way to abstract the problems away (though it is better suited for builds
than deployments).


As D gets more support for dynamic libraries, it would be good to take
lessons from how Java and others have dealt with dependency management.
Aug 26 2014
parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 26 August 2014 at 22:07:49 UTC, Jeremy Powers via 
Digitalmars-d wrote:

 If your users are having to install things then the problem 
 is your
 deployment mechanism not the JVM dependency hell system. Java
 deployments are actually really quite easy. Either you 
 package a total
 system with all dependencies and provide entry scripts, or 
 you use Maven
 Central (or increasingly BinTray) for accessing dependencies.


 If I need deployment mechanisms like the ones above, then 
 there's
 something wrong with the language. All these crutches and 
 patches. To set
 up and test a deployment mechanism takes as long as writing 
 the program. No
 thank you.




 This is what you get with shared libraries.  If you don't want 
 to deal with
 dependencies, either A) ship a static-linked binary or B) cross 
 your
 fingers and pray.


Statically linked binaries are still the best option, if you want 
to make sure things will work for the user (and you don't have 
time for customer service). It's also a good strategy for 
cross-platform development, this or you have to use an approach 
similar to Textadept that ships everything in one package. I 
usually ship all the additional dlls / libs, if there are any.

Relying on system wide dynamic linking is more for cases when you 
develop for one particular environment or when you're 90% sure 
that a certain library exists on most systems you develop for. 
The C standard library comes to mind, but even there are 
differences between Linux and Windows. And don't forget that, 
unlike Linux users, people who use Windows are usually not tech 
savvy in the sense that they can deal with downloading additional 
libraries.

It all depends on the products you're developing. But for our 
stuff it's better to go static or ship everything.


 I've found the java ecosystem to be quite well fleshed out and 
 mature in
 handling lib/jar dependencies, such that it was an unpleasant 
 shock dealing
 with C++ after years away.  Using maven, for instance, is a 
 quick and easy
 way to abstract the problems away (though it is better suited 
 for builds
 than deployments).


 As D gets more support for dynamic libraries, it would be good 
 to take
 lessons from how Java and others have dealt with dependency 
 management.


Yes, only better. :-)
Aug 27 2014
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 26/08/2014 09:46, Chris wrote:

 The problem was that Java didn't behave as expected on Windows. Things
 that worked fine on Linux and OS X didn't work on Windows (even simple
 things like deleting files). User reported all sorts of problems, one of
 them being that the Java Access Bridge didn't work. Why, nobody knows.
 The lack of a proper sound API / library. Then there was the versioning
 hell with JRE/JVM and having to tell users what version they had to
 download (the non tech savvy crowd). I know that MS doesn't make it easy
 for Java either. Well, I could have sorted the problems out with Java
 web start, SWT and all that kind of stuff. Instead, I learned D which I
 can compile and run on each platform without a problem.


The promise of "Write once run everywhere" is still pretty much accurate 
if you stick to core Java code and libraries. Of course once you start 
using OS/implementation specific code you will have to code more 
carefully, and are more likely to encounter cross-platform problems. 
That's just the nature of things, you can't say it's a failure of Java.
It's like coding in D using lots of malloc/free in your code, and then 
when your program breaks, you complain that "the D GC doesn't work!". Of 
course the GC only is only guaranteed to work if you stick to GC-managed 
memory.

To be honest I smell a load of Java-biased *BS* here, especially because 
of this sentence:
"Instead, I learned D which I can compile and run on each platform 
without a problem."

Actually virtually all other languages, including D, are just as bad as 
Java (if not worse) in the aspects mentioned above. For example, if you 
write code which heavily interacts with the filesystem, you are bound to 
encounter platform/OS-specific problems no matter what language. I'd bet 
money those "even simple things like deleting files", you'd have in D as 
well. At least in Java the APIs they are usually careful to specify 
which aspects of behavior are implementation-specific.

In other cases, such as the sound library or accessibility library, most 
other cross-platform language don't even have those!, so how can you be 
saying that D runs better on each platform that Java?..
(Does a non-existent library run perfectly on every conceivable 
platform? one could say yes...)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 04 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno Medeiros 
wrote:

 On 26/08/2014 09:46, Chris wrote:

 The problem was that Java didn't behave as expected on 
 Windows. Things
 that worked fine on Linux and OS X didn't work on Windows 
 (even simple
 things like deleting files). User reported all sorts of 
 problems, one of
 them being that the Java Access Bridge didn't work. Why, 
 nobody knows.
 The lack of a proper sound API / library. Then there was the 
 versioning
 hell with JRE/JVM and having to tell users what version they 
 had to
 download (the non tech savvy crowd). I know that MS doesn't 
 make it easy
 for Java either. Well, I could have sorted the problems out 
 with Java
 web start, SWT and all that kind of stuff. Instead, I learned 
 D which I
 can compile and run on each platform without a problem.


 The promise of "Write once run everywhere" is still pretty much 
 accurate if you stick to core Java code and libraries. Of 
 course once you start using OS/implementation specific code you 
 will have to code more carefully, and are more likely to 
 encounter cross-platform problems. That's just the nature of 
 things, you can't say it's a failure of Java.
 It's like coding in D using lots of malloc/free in your code, 
 and then when your program breaks, you complain that "the D GC 
 doesn't work!". Of course the GC only is only guaranteed to 
 work if you stick to GC-managed memory.


I can expect the Java Access Bridge to work, because Java offers 
it as a built-in technology. If it does not work, it's a broken 
promise. Simple as that.


 To be honest I smell a load of Java-biased *BS* here, 
 especially because of this sentence:
 "Instead, I learned D which I can compile and run on each 
 platform without a problem."


Which is true. I could compile it on Linux, OS X and Windows. It 
was almost trivial to write a DLL that third party software can 
use. Try that with Java and tell me if it's trivially easy. I 
think what you meant was _anti_-Java *BS*. I'm only writing about 
my experience with the two languages. The one worked for me, the 
other didn't.


 Actually virtually all other languages, including D, are just 
 as bad as Java (if not worse) in the aspects mentioned above. 
 For example, if you write code which heavily interacts with the 
 filesystem, you are bound to encounter platform/OS-specific 
 problems no matter what language. I'd bet money those "even 
 simple things like deleting files", you'd have in D as well. At 
 least in Java the APIs they are usually careful to specify 
 which aspects of behavior are implementation-specific.


Well, my statement refered to the fact that Java f**ked up big 
time there, which clearly breaks the promise "write once, run 
everywhere", especially because dealing with files is a feature 
one would expect to be part and parcel of a programming language. 
Deleting files should not give you a headache. Basically what 
you're saying is "Java is cross-platform but it's not, but hey, 
other languages are just as bad!". Well, then they should stop 
using the word "cross-platform" when advertising their language.


 In other cases, such as the sound library or accessibility 
 library, most other cross-platform language don't even have 
 those!, so how can you be saying that D runs better on each 
 platform that Java?..
 (Does a non-existent library run perfectly on every conceivable 
 platform? one could say yes...)


D interfaces to existing audio / sound libraries in C 
(libsndfile, portaudio). All you have to do is to include those 
libs and call the functions you need. Doing this with Java is a 
bit more complicated (you'll probably need tools).

You are welcome to report on any serious issues you've 
encountered when porting D programs to various platforms. Maybe 
it can be fixed in the core of the language and it would help to 
make D even more portable. A lot of cross-platform issues can be 
dealt with by including "version(Windows/Posix ...)" in your code.
Sep 04 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 04/09/2014 16:21, Chris wrote:

 On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno Medeiros wrote:

 On 26/08/2014 09:46, Chris wrote:

 The problem was that Java didn't behave as expected on Windows. Things
 that worked fine on Linux and OS X didn't work on Windows (even simple
 things like deleting files). User reported all sorts of problems, one of
 them being that the Java Access Bridge didn't work. Why, nobody knows.
 The lack of a proper sound API / library. Then there was the versioning
 hell with JRE/JVM and having to tell users what version they had to
 download (the non tech savvy crowd). I know that MS doesn't make it easy
 for Java either. Well, I could have sorted the problems out with Java
 web start, SWT and all that kind of stuff. Instead, I learned D which I
 can compile and run on each platform without a problem.


 The promise of "Write once run everywhere" is still pretty much
 accurate if you stick to core Java code and libraries. Of course once
 you start using OS/implementation specific code you will have to code
 more carefully, and are more likely to encounter cross-platform
 problems. That's just the nature of things, you can't say it's a
 failure of Java.
 It's like coding in D using lots of malloc/free in your code, and then
 when your program breaks, you complain that "the D GC doesn't work!".
 Of course the GC only is only guaranteed to work if you stick to
 GC-managed memory.


 I can expect the Java Access Bridge to work, because Java offers it as a
 built-in technology. If it does not work, it's a broken promise. Simple
 as that.


Does Java Access Bridge really not work, or you just didn't use it 
right? Or are you trying to use in for a purpose it's aimed to be used? 
Unfortunately, I'm not familiar with JAB, so I can't comment further on it..


 To be honest I smell a load of Java-biased *BS* here, especially
 because of this sentence:
 "Instead, I learned D which I can compile and run on each platform
 without a problem."


 Which is true. I could compile it on Linux, OS X and Windows. It was
 almost trivial to write a DLL that third party software can use. Try
 that with Java and tell me if it's trivially easy. I think what you
 meant was _anti_-Java *BS*. I'm only writing about my experience with
 the two languages. The one worked for me, the other didn't.


When you say DLL, do you mean a shared library in general, or really an 
actual Windows DLL? I'm assuming it's the former, otherwise that doesn't 
make sense. Well In Java you can create them quite easily: jars. They 
are trivial to be used by other Java programs! I don't see your point.


 Actually virtually all other languages, including D, are just as bad
 as Java (if not worse) in the aspects mentioned above. For example, if
 you write code which heavily interacts with the filesystem, you are
 bound to encounter platform/OS-specific problems no matter what
 language. I'd bet money those "even simple things like deleting
 files", you'd have in D as well. At least in Java the APIs they are
 usually careful to specify which aspects of behavior are
 implementation-specific.


 Well, my statement refered to the fact that Java f**ked up big time
 there, which clearly breaks the promise "write once, run everywhere",
 especially because dealing with files is a feature one would expect to
 be part and parcel of a programming language. Deleting files should not
 give you a headache. Basically what you're saying is "Java is
 cross-platform but it's not, but hey, other languages are just as bad!".
 Well, then they should stop using the word "cross-platform" when
 advertising their language.


If the core of the language was "working with with filesystem", then 
yeah, they should not advertise it as cross-platform. But it's not the 
core of language (even if it's part of the standard library), it's just 
a minor library component, one amongst many (the vast majority of it 
being fully cross-platform).


 In other cases, such as the sound library or accessibility library,
 most other cross-platform language don't even have those!, so how can
 you be saying that D runs better on each platform that Java?..
 (Does a non-existent library run perfectly on every conceivable
 platform? one could say yes...)


 D interfaces to existing audio / sound libraries in C (libsndfile,
 portaudio). All you have to do is to include those libs and call the
 functions you need. Doing this with Java is a bit more complicated
 (you'll probably need tools).

 You are welcome to report on any serious issues you've encountered when
 porting D programs to various platforms. Maybe it can be fixed in the
 core of the language and it would help to make D even more portable. A
 lot of cross-platform issues can be dealt with by including
 "version(Windows/Posix ...)" in your code.



-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 05 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 5 September 2014 at 11:27:17 UTC, Bruno Medeiros wrote:

 On 04/09/2014 16:21, Chris wrote:

 On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno Medeiros 
 wrote:

 On 26/08/2014 09:46, Chris wrote:

 The problem was that Java didn't behave as expected on 
 Windows. Things
 that worked fine on Linux and OS X didn't work on Windows 
 (even simple
 things like deleting files). User reported all sorts of 
 problems, one of
 them being that the Java Access Bridge didn't work. Why, 
 nobody knows.
 The lack of a proper sound API / library. Then there was the 
 versioning
 hell with JRE/JVM and having to tell users what version they 
 had to
 download (the non tech savvy crowd). I know that MS doesn't 
 make it easy
 for Java either. Well, I could have sorted the problems out 
 with Java
 web start, SWT and all that kind of stuff. Instead, I 
 learned D which I
 can compile and run on each platform without a problem.


 The promise of "Write once run everywhere" is still pretty 
 much
 accurate if you stick to core Java code and libraries. Of 
 course once
 you start using OS/implementation specific code you will have 
 to code
 more carefully, and are more likely to encounter 
 cross-platform
 problems. That's just the nature of things, you can't say 
 it's a
 failure of Java.
 It's like coding in D using lots of malloc/free in your code, 
 and then
 when your program breaks, you complain that "the D GC doesn't 
 work!".
 Of course the GC only is only guaranteed to work if you stick 
 to
 GC-managed memory.


 I can expect the Java Access Bridge to work, because Java 
 offers it as a
 built-in technology. If it does not work, it's a broken 
 promise. Simple
 as that.


 Does Java Access Bridge really not work, or you just didn't use 
 it right? Or are you trying to use in for a purpose it's aimed 
 to be used? Unfortunately, I'm not familiar with JAB, so I 
 can't comment further on it..


I used it with Swing. It was ignored by all the screen readers.


 To be honest I smell a load of Java-biased *BS* here, 
 especially
 because of this sentence:
 "Instead, I learned D which I can compile and run on each 
 platform
 without a problem."


 Which is true. I could compile it on Linux, OS X and Windows. 
 It was
 almost trivial to write a DLL that third party software can 
 use. Try
 that with Java and tell me if it's trivially easy. I think 
 what you
 meant was _anti_-Java *BS*. I'm only writing about my 
 experience with
 the two languages. The one worked for me, the other didn't.


 When you say DLL, do you mean a shared library in general, or 
 really an actual Windows DLL? I'm assuming it's the former, 
 otherwise that doesn't make sense. Well In Java you can create 
 them quite easily: jars. They are trivial to be used by other 
 Java programs! I don't see your point.


I mean a DLL that can be loaded by say a Python program (as in my 
case) or any other software that wants to use my plug-in[1]. A 
jar can only be used by another Java program. Making a Java 
program accessible to 3rd party software via a DLL is not so 
simple, and the JVM has to be up and running all the time. Java 
is cross-platform as long as you stay within the safe and cosy 
Java bubble that floats on top of the JVM. But once you step 
outside of the JVM, gravity kicks in.

Don't get me wrong. I like the concept of a VM. Only Java has 
been screwed up over the years by bad and wrong decisions, partly 
due to ideology and partly due to strategic / marketing 
decisions. It's a pity really. It started out as a very promising 
language but got caught under the wheels of corporate decisions 
and OOP evangelists.

[1] Have a look at this. It was really just as simple:

http://wiki.dlang.org/Win32_DLLs_in_D


 Actually virtually all other languages, including D, are just 
 as bad
 as Java (if not worse) in the aspects mentioned above. For 
 example, if
 you write code which heavily interacts with the filesystem, 
 you are
 bound to encounter platform/OS-specific problems no matter 
 what
 language. I'd bet money those "even simple things like 
 deleting
 files", you'd have in D as well. At least in Java the APIs 
 they are
 usually careful to specify which aspects of behavior are
 implementation-specific.


 Well, my statement refered to the fact that Java f**ked up big 
 time
 there, which clearly breaks the promise "write once, run 
 everywhere",
 especially because dealing with files is a feature one would 
 expect to
 be part and parcel of a programming language. Deleting files 
 should not
 give you a headache. Basically what you're saying is "Java is
 cross-platform but it's not, but hey, other languages are just 
 as bad!".
 Well, then they should stop using the word "cross-platform" 
 when
 advertising their language.


 If the core of the language was "working with with filesystem", 
 then yeah, they should not advertise it as cross-platform. But 
 it's not the core of language (even if it's part of the 
 standard library), it's just a minor library component, one 
 amongst many (the vast majority of it being fully 
 cross-platform).


 In other cases, such as the sound library or accessibility 
 library,
 most other cross-platform language don't even have those!, so 
 how can
 you be saying that D runs better on each platform that Java?..
 (Does a non-existent library run perfectly on every 
 conceivable
 platform? one could say yes...)


 D interfaces to existing audio / sound libraries in C 
 (libsndfile,
 portaudio). All you have to do is to include those libs and 
 call the
 functions you need. Doing this with Java is a bit more 
 complicated
 (you'll probably need tools).

 You are welcome to report on any serious issues you've 
 encountered when
 porting D programs to various platforms. Maybe it can be fixed 
 in the
 core of the language and it would help to make D even more 
 portable. A
 lot of cross-platform issues can be dealt with by including
 "version(Windows/Posix ...)" in your code.
Sep 05 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 5 September 2014 at 13:42:56 UTC, Chris wrote:

 On Friday, 5 September 2014 at 11:27:17 UTC, Bruno Medeiros 
 wrote:

 On 04/09/2014 16:21, Chris wrote:

 On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno Medeiros 
 wrote:

 On 26/08/2014 09:46, Chris wrote:

 The problem was that Java didn't behave as expected on 
 Windows. Things
 that worked fine on Linux and OS X didn't work on Windows 
 (even simple
 things like deleting files). User reported all sorts of 
 problems, one of
 them being that the Java Access Bridge didn't work. Why, 
 nobody knows.
 The lack of a proper sound API / library. Then there was 
 the versioning
 hell with JRE/JVM and having to tell users what version 
 they had to
 download (the non tech savvy crowd). I know that MS doesn't 
 make it easy
 for Java either. Well, I could have sorted the problems out 
 with Java
 web start, SWT and all that kind of stuff. Instead, I 
 learned D which I
 can compile and run on each platform without a problem.


 The promise of "Write once run everywhere" is still pretty 
 much
 accurate if you stick to core Java code and libraries. Of 
 course once
 you start using OS/implementation specific code you will 
 have to code
 more carefully, and are more likely to encounter 
 cross-platform
 problems. That's just the nature of things, you can't say 
 it's a
 failure of Java.
 It's like coding in D using lots of malloc/free in your 
 code, and then
 when your program breaks, you complain that "the D GC 
 doesn't work!".
 Of course the GC only is only guaranteed to work if you 
 stick to
 GC-managed memory.


 I can expect the Java Access Bridge to work, because Java 
 offers it as a
 built-in technology. If it does not work, it's a broken 
 promise. Simple
 as that.


 Does Java Access Bridge really not work, or you just didn't 
 use it right? Or are you trying to use in for a purpose it's 
 aimed to be used? Unfortunately, I'm not familiar with JAB, so 
 I can't comment further on it..


 I used it with Swing. It was ignored by all the screen readers.


 To be honest I smell a load of Java-biased *BS* here, 
 especially
 because of this sentence:
 "Instead, I learned D which I can compile and run on each 
 platform
 without a problem."


 Which is true. I could compile it on Linux, OS X and Windows. 
 It was
 almost trivial to write a DLL that third party software can 
 use. Try
 that with Java and tell me if it's trivially easy. I think 
 what you
 meant was _anti_-Java *BS*. I'm only writing about my 
 experience with
 the two languages. The one worked for me, the other didn't.


 When you say DLL, do you mean a shared library in general, or 
 really an actual Windows DLL? I'm assuming it's the former, 
 otherwise that doesn't make sense. Well In Java you can create 
 them quite easily: jars. They are trivial to be used by other 
 Java programs! I don't see your point.


 I mean a DLL that can be loaded by say a Python program (as in 
 my case) or any other software that wants to use my plug-in[1]. 
 A jar can only be used by another Java program. Making a Java 
 program accessible to 3rd party software via a DLL is not so 
 simple, and the JVM has to be up and running all the time. Java 
 is cross-platform as long as you stay within the safe and cosy 
 Java bubble that floats on top of the JVM. But once you step 
 outside of the JVM, gravity kicks in.

 Don't get me wrong. I like the concept of a VM. Only Java has 
 been screwed up over the years by bad and wrong decisions, 
 partly due to ideology and partly due to strategic / marketing 
 decisions. It's a pity really. It started out as a very 
 promising language but got caught under the wheels of corporate 
 decisions and OOP evangelists.


You can write DLLs in Java, for example with 
http://www.excelsiorjet.com/.

The fact that the Java reference implementation is a VM, doesn't 
tie the language to a VM.

There are quite a few commercial compilers and JVMs with AOT 
support to choose from.

Oracle is finally thinking about adding a AOT compilation mode to 
the standard toolchain in the Java 9+ release.

http://www.oracle.com/technetwork/java/jvmls2014goetzrose-2265201.pdf


As for OOP evangelists, had Java not happened, probably your rant 
would be now be about Smalltalk and Eiffel. The two OO languages 
getting an enterprise foothold at the time Sun started pushing 
Java.

--
Paulo
Sep 05 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:

 On Friday, 5 September 2014 at 13:42:56 UTC, Chris wrote:

 On Friday, 5 September 2014 at 11:27:17 UTC, Bruno Medeiros 
 wrote:

 On 04/09/2014 16:21, Chris wrote:

 On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno 
 Medeiros wrote:

 On 26/08/2014 09:46, Chris wrote:

 The problem was that Java didn't behave as expected on 
 Windows. Things
 that worked fine on Linux and OS X didn't work on Windows 
 (even simple
 things like deleting files). User reported all sorts of 
 problems, one of
 them being that the Java Access Bridge didn't work. Why, 
 nobody knows.
 The lack of a proper sound API / library. Then there was 
 the versioning
 hell with JRE/JVM and having to tell users what version 
 they had to
 download (the non tech savvy crowd). I know that MS 
 doesn't make it easy
 for Java either. Well, I could have sorted the problems 
 out with Java
 web start, SWT and all that kind of stuff. Instead, I 
 learned D which I
 can compile and run on each platform without a problem.


 The promise of "Write once run everywhere" is still pretty 
 much
 accurate if you stick to core Java code and libraries. Of 
 course once
 you start using OS/implementation specific code you will 
 have to code
 more carefully, and are more likely to encounter 
 cross-platform
 problems. That's just the nature of things, you can't say 
 it's a
 failure of Java.
 It's like coding in D using lots of malloc/free in your 
 code, and then
 when your program breaks, you complain that "the D GC 
 doesn't work!".
 Of course the GC only is only guaranteed to work if you 
 stick to
 GC-managed memory.


 I can expect the Java Access Bridge to work, because Java 
 offers it as a
 built-in technology. If it does not work, it's a broken 
 promise. Simple
 as that.


 Does Java Access Bridge really not work, or you just didn't 
 use it right? Or are you trying to use in for a purpose it's 
 aimed to be used? Unfortunately, I'm not familiar with JAB, 
 so I can't comment further on it..


 I used it with Swing. It was ignored by all the screen readers.


 To be honest I smell a load of Java-biased *BS* here, 
 especially
 because of this sentence:
 "Instead, I learned D which I can compile and run on each 
 platform
 without a problem."


 Which is true. I could compile it on Linux, OS X and 
 Windows. It was
 almost trivial to write a DLL that third party software can 
 use. Try
 that with Java and tell me if it's trivially easy. I think 
 what you
 meant was _anti_-Java *BS*. I'm only writing about my 
 experience with
 the two languages. The one worked for me, the other didn't.


 When you say DLL, do you mean a shared library in general, or 
 really an actual Windows DLL? I'm assuming it's the former, 
 otherwise that doesn't make sense. Well In Java you can 
 create them quite easily: jars. They are trivial to be used 
 by other Java programs! I don't see your point.


 I mean a DLL that can be loaded by say a Python program (as in 
 my case) or any other software that wants to use my 
 plug-in[1]. A jar can only be used by another Java program. 
 Making a Java program accessible to 3rd party software via a 
 DLL is not so simple, and the JVM has to be up and running all 
 the time. Java is cross-platform as long as you stay within 
 the safe and cosy Java bubble that floats on top of the JVM. 
 But once you step outside of the JVM, gravity kicks in.

 Don't get me wrong. I like the concept of a VM. Only Java has 
 been screwed up over the years by bad and wrong decisions, 
 partly due to ideology and partly due to strategic / marketing 
 decisions. It's a pity really. It started out as a very 
 promising language but got caught under the wheels of 
 corporate decisions and OOP evangelists.


 You can write DLLs in Java, for example with 
 http://www.excelsiorjet.com/.


I know, I know, but in D it comes for free. This would have 
broken the bank.


 The fact that the Java reference implementation is a VM, 
 doesn't tie the language to a VM.

 There are quite a few commercial compilers and JVMs with AOT 
 support to choose from.

 Oracle is finally thinking about adding a AOT compilation mode 
 to the standard toolchain in the Java 9+ release.

 http://www.oracle.com/technetwork/java/jvmls2014goetzrose-2265201.pdf


Finally, I've been waiting for this since forever. I always 
wondered why they didn't do it. Then again it was all about the 
"write once ..." ideology and they thought AOT would undermine 
this (which is not true). Why shouldn't programmers be able to 
make the decision (VM / AOT where it makes sense)?


 As for OOP evangelists, had Java not happened, probably your 
 rant would be now be about Smalltalk and Eiffel. The two OO 
 languages getting an enterprise foothold at the time Sun 
 started pushing Java.

 --
 Paulo


It's not a rant. I'm happier in the D world than in the Java 
world, that's all. It's only when you step outside of the Java 
world that you realize who restricted and restrictive it is. For 
what it's worth, Java is a safe enough technology for companies. 
Middle of the road type of thing.
Sep 05 2014
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 9/5/2014 11:42 PM, Chris wrote:

 On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:



 It's not a rant. I'm happier in the D world than in the Java world,
 that's all. It's only when you step outside of the Java world that you
 realize who restricted and restrictive it is. For what it's worth, Java
 is a safe enough technology for companies. Middle of the road type of
 thing.


Java has its place. I would say that Python plugins isn't it. Right tool 
for the job and all that. Like you, I'm happier in the D world, but I 
don't see it as a silver bullet. I'd still choose Java for particular 
projects for the same reasons I'd choose Java over C++ for those same 
projects. I don't find it restrictive at all (I actually enjoy it; I 
also enjoy C). As long as you work within its boundaries and use it as 
it's meant to be used, it works perfectly well.

That holds true for any language and, IMO, is what trips people up the 
most when moving from one language to another. This is very clear when 
you take, say, a Java programmer who actually likes it and one who uses 
it for the day job but prefers C++ and compare their list of gripes. 
Eckel's books are called "Thinking in..." for a reason.


---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
Sep 05 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 5 September 2014 at 15:13:02 UTC, Mike Parker wrote:

 On 9/5/2014 11:42 PM, Chris wrote:

 On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto 
 wrote:



 It's not a rant. I'm happier in the D world than in the Java 
 world,
 that's all. It's only when you step outside of the Java world 
 that you
 realize who restricted and restrictive it is. For what it's 
 worth, Java
 is a safe enough technology for companies. Middle of the road 
 type of
 thing.


 Java has its place. I would say that Python plugins isn't it. 
 Right tool for the job and all that. Like you, I'm happier in 
 the D world, but I don't see it as a silver bullet. I'd still 
 choose Java for particular projects for the same reasons I'd 
 choose Java over C++ for those same projects. I don't find it 
 restrictive at all (I actually enjoy it; I also enjoy C). As 
 long as you work within its boundaries and use it as it's meant 
 to be used, it works perfectly well.


The plugin had to be for Python, and for other languages to be 
able to plug into native MSAPI, OS X etc. Among other things, 
Java's unpluginability (if that's a word :) kicked it out of the 
race. Atm, I don't see any reason to start a project in Java. 
Even server side programming can be done by D.

Maybe I'll consider Java again when they have AOT compilation. I 
really liked Java, but it became more and more useless for my 
purposes. And once you have the freedom that D offers, it's hard 
to go back.

"I don't find it  restrictive at all (I actually enjoy it; I also 
enjoy C). As long as you work within its boundaries and use it as 
it's meant to be used, it works perfectly well."

Isn't this statement a bit contradictory :) It's not restrictive 
as long as you stay within its boundaries. In D you can stretch 
the boundaries a bit.


 That holds true for any language and, IMO, is what trips people 
 up the most when moving from one language to another. This is 
 very clear when you take, say, a Java programmer who actually 
 likes it and one who uses it for the day job but prefers C++ 
 and compare their list of gripes. Eckel's books are called 
 "Thinking in..." for a reason.


 ---
 This email is free from viruses and malware because avast! 
 Antivirus protection is active.
 http://www.avast.com
Sep 05 2014
parent reply Mike Parker <aldacron gmail.com> writes:
On 9/6/2014 12:32 AM, Chris wrote:


 "I don't find it  restrictive at all (I actually enjoy it; I also enjoy
 C). As long as you work within its boundaries and use it as it's meant
 to be used, it works perfectly well."

 Isn't this statement a bit contradictory :) It's not restrictive as long
 as you stay within its boundaries. In D you can stretch the boundaries a
 bit.


Not contradictory, no. Every language has boundaries and you can stretch 
them in any language. My point is that when you do so you are then in 
the wild frontier and are more likely to be frustrated in your efforts.


---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
Sep 05 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Saturday, 6 September 2014 at 02:24:35 UTC, Mike Parker wrote:

 On 9/6/2014 12:32 AM, Chris wrote:


 "I don't find it  restrictive at all (I actually enjoy it; I 
 also enjoy
 C). As long as you work within its boundaries and use it as 
 it's meant
 to be used, it works perfectly well."

 Isn't this statement a bit contradictory :) It's not 
 restrictive as long
 as you stay within its boundaries. In D you can stretch the 
 boundaries a
 bit.


 Not contradictory, no. Every language has boundaries and you 
 can stretch them in any language. My point is that when you do 
 so you are then in the wild frontier and are more likely to be 
 frustrated in your efforts.


But in D you have to walk quite a bit to reach the boundaries. In 
Java they're around every corner. It's like a lunatic asylum 
where you're allowed to do anything you want, except for going 
out into the real world.

The most frustrating thing is that programmers have to wait for 
years to get this or that feature. Then there are weird things 
like auto-boxing etc. that are down to OOP ideology. If people 
increasingly use static methods to work around OO, well, then why 
not get rid of the rigid OOP regime altogether? OO is a pattern 
that helps to deal with certain problems, not a cure for 
everything. It should never have become a religion, a belief one 
would base a whole language on. The hello world program shows how 
absurd this is, and one absurdity begets another one ...

public class MyClass {

     public static void main(String[] args) {
         System.out.println("Hello, World!");
     }

}

1. Write a class
2. Use a static method to work around OO.
3. Hm. WTF?


 ---
 This email is free from viruses and malware because avast! 
 Antivirus protection is active.
 http://www.avast.com
Sep 08 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 8 September 2014 at 08:50:54 UTC, Chris wrote:

 On Saturday, 6 September 2014 at 02:24:35 UTC, Mike Parker 
 wrote:

 On 9/6/2014 12:32 AM, Chris wrote:


 "I don't find it  restrictive at all (I actually enjoy it; I 
 also enjoy
 C). As long as you work within its boundaries and use it as 
 it's meant
 to be used, it works perfectly well."

 Isn't this statement a bit contradictory :) It's not 
 restrictive as long
 as you stay within its boundaries. In D you can stretch the 
 boundaries a
 bit.


 Not contradictory, no. Every language has boundaries and you 
 can stretch them in any language. My point is that when you do 
 so you are then in the wild frontier and are more likely to be 
 frustrated in your efforts.


 But in D you have to walk quite a bit to reach the boundaries. 
 In Java they're around every corner. It's like a lunatic asylum 
 where you're allowed to do anything you want, except for going 
 out into the real world.

 The most frustrating thing is that programmers have to wait for 
 years to get this or that feature. Then there are weird things 
 like auto-boxing etc. that are down to OOP ideology. If people 
 increasingly use static methods to work around OO, well, then 
 why not get rid of the rigid OOP regime altogether? OO is a 
 pattern that helps to deal with certain problems, not a cure 
 for everything. It should never have become a religion, a 
 belief one would base a whole language on. The hello world 
 program shows how absurd this is, and one absurdity begets 
 another one ...

 public class MyClass {

     public static void main(String[] args) {
         System.out.println("Hello, World!");
     }

 }

 1. Write a class
 2. Use a static method to work around OO.
 3. Hm. WTF?


1. Write a class
2. Use a class method in OO terminology
3. Just like any other pure OOP language (Smalltalk, Eiffel, 
Sather, ...)

This is not Java specific.

Autoboxing is already present in Lisp and Smalltalk with their 
type tagging.

--
Paulo
Sep 08 2014
parent "Chris" <wendlec tcd.ie> writes:
On Monday, 8 September 2014 at 14:48:15 UTC, Paulo  Pinto wrote:

 On Monday, 8 September 2014 at 08:50:54 UTC, Chris wrote:

 On Saturday, 6 September 2014 at 02:24:35 UTC, Mike Parker 
 wrote:

 On 9/6/2014 12:32 AM, Chris wrote:


 "I don't find it  restrictive at all (I actually enjoy it; I 
 also enjoy
 C). As long as you work within its boundaries and use it as 
 it's meant
 to be used, it works perfectly well."

 Isn't this statement a bit contradictory :) It's not 
 restrictive as long
 as you stay within its boundaries. In D you can stretch the 
 boundaries a
 bit.


 Not contradictory, no. Every language has boundaries and you 
 can stretch them in any language. My point is that when you 
 do so you are then in the wild frontier and are more likely 
 to be frustrated in your efforts.


 But in D you have to walk quite a bit to reach the boundaries. 
 In Java they're around every corner. It's like a lunatic 
 asylum where you're allowed to do anything you want, except 
 for going out into the real world.

 The most frustrating thing is that programmers have to wait 
 for years to get this or that feature. Then there are weird 
 things like auto-boxing etc. that are down to OOP ideology. If 
 people increasingly use static methods to work around OO, 
 well, then why not get rid of the rigid OOP regime altogether? 
 OO is a pattern that helps to deal with certain problems, not 
 a cure for everything. It should never have become a religion, 
 a belief one would base a whole language on. The hello world 
 program shows how absurd this is, and one absurdity begets 
 another one ...

 public class MyClass {

    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }

 }

 1. Write a class
 2. Use a static method to work around OO.
 3. Hm. WTF?


 1. Write a class
 2. Use a class method in OO terminology
 3. Just like any other pure OOP language (Smalltalk, Eiffel, 
 Sather, ...)

 This is not Java specific.


Still, it's a bit OTT, isn't it?


 Autoboxing is already present in Lisp and Smalltalk with their 
 type tagging.

 --
 Paulo


Yes, and that's what happens, when you build a language on 
ideology. There's no need for a 100% OO approach.
Sep 08 2014
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 5 September 2014 at 14:42:05 UTC, Chris wrote:

 On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:

 On Friday, 5 September 2014 at 13:42:56 UTC, Chris wrote:

 On Friday, 5 September 2014 at 11:27:17 UTC, Bruno Medeiros 
 wrote:

 On 04/09/2014 16:21, Chris wrote:

 On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno 
 Medeiros wrote:

 On 26/08/2014 09:46, Chris wrote:

 The problem was that Java didn't behave as expected on 
 Windows. Things
 that worked fine on Linux and OS X didn't work on Windows 
 (even simple
 things like deleting files). User reported all sorts of 
 problems, one of
 them being that the Java Access Bridge didn't work. Why, 
 nobody knows.
 The lack of a proper sound API / library. Then there was 
 the versioning
 hell with JRE/JVM and having to tell users what version 
 they had to
 download (the non tech savvy crowd). I know that MS 
 doesn't make it easy
 for Java either. Well, I could have sorted the problems 
 out with Java
 web start, SWT and all that kind of stuff. Instead, I 
 learned D which I
 can compile and run on each platform without a problem.


 The promise of "Write once run everywhere" is still pretty 
 much
 accurate if you stick to core Java code and libraries. Of 
 course once
 you start using OS/implementation specific code you will 
 have to code
 more carefully, and are more likely to encounter 
 cross-platform
 problems. That's just the nature of things, you can't say 
 it's a
 failure of Java.
 It's like coding in D using lots of malloc/free in your 
 code, and then
 when your program breaks, you complain that "the D GC 
 doesn't work!".
 Of course the GC only is only guaranteed to work if you 
 stick to
 GC-managed memory.


 I can expect the Java Access Bridge to work, because Java 
 offers it as a
 built-in technology. If it does not work, it's a broken 
 promise. Simple
 as that.


 Does Java Access Bridge really not work, or you just didn't 
 use it right? Or are you trying to use in for a purpose it's 
 aimed to be used? Unfortunately, I'm not familiar with JAB, 
 so I can't comment further on it..


 I used it with Swing. It was ignored by all the screen 
 readers.


 To be honest I smell a load of Java-biased *BS* here, 
 especially
 because of this sentence:
 "Instead, I learned D which I can compile and run on each 
 platform
 without a problem."


 Which is true. I could compile it on Linux, OS X and 
 Windows. It was
 almost trivial to write a DLL that third party software can 
 use. Try
 that with Java and tell me if it's trivially easy. I think 
 what you
 meant was _anti_-Java *BS*. I'm only writing about my 
 experience with
 the two languages. The one worked for me, the other didn't.


 When you say DLL, do you mean a shared library in general, 
 or really an actual Windows DLL? I'm assuming it's the 
 former, otherwise that doesn't make sense. Well In Java you 
 can create them quite easily: jars. They are trivial to be 
 used by other Java programs! I don't see your point.


 I mean a DLL that can be loaded by say a Python program (as 
 in my case) or any other software that wants to use my 
 plug-in[1]. A jar can only be used by another Java program. 
 Making a Java program accessible to 3rd party software via a 
 DLL is not so simple, and the JVM has to be up and running 
 all the time. Java is cross-platform as long as you stay 
 within the safe and cosy Java bubble that floats on top of 
 the JVM. But once you step outside of the JVM, gravity kicks 
 in.

 Don't get me wrong. I like the concept of a VM. Only Java has 
 been screwed up over the years by bad and wrong decisions, 
 partly due to ideology and partly due to strategic / 
 marketing decisions. It's a pity really. It started out as a 
 very promising language but got caught under the wheels of 
 corporate decisions and OOP evangelists.


 You can write DLLs in Java, for example with 
 http://www.excelsiorjet.com/.


 I know, I know, but in D it comes for free. This would have 
 broken the bank.


 The fact that the Java reference implementation is a VM, 
 doesn't tie the language to a VM.

 There are quite a few commercial compilers and JVMs with AOT 
 support to choose from.

 Oracle is finally thinking about adding a AOT compilation mode 
 to the standard toolchain in the Java 9+ release.

 http://www.oracle.com/technetwork/java/jvmls2014goetzrose-2265201.pdf


 Finally, I've been waiting for this since forever. I always 
 wondered why they didn't do it. Then again it was all about the 
 "write once ..." ideology and they thought AOT would undermine 
 this (which is not true). Why shouldn't programmers be able to 
 make the decision (VM / AOT where it makes sense)?


I once read in a forum, shortly after the Oracle/Sun acquisition 
aftermath that there was a strong political position inside Sun 
against AOT.

The post was arguably from an ex-Sun employee, but I cannot say 
s/he was really telling the truth.

Actually, I think it was a bad decision to have gone fully VM, 
without any optional AOT options in the standard toolchain.

At least in the ML, Lisp, .NET, Oberon, AS/400 worlds ..., you 
get to choose.

--
Paulo
Sep 05 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:

 You can write DLLs in Java, for example with 
 http://www.excelsiorjet.com/.

 The fact that the Java reference implementation is a VM, 
 doesn't tie the language to a VM.


True, but it is VERY hard to get performance out of it outside a
VM. Java is tailored for a VM.
Sep 05 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:

 You can write DLLs in Java, for example with 
 http://www.excelsiorjet.com/.

 The fact that the Java reference implementation is a VM, 
 doesn't tie the language to a VM.


Why pick Java if not for JVM? It is mediocre language at most, 
very limited and poor feature-wise, lacking expressive power even 
compared to C++ (you can at least abuse templates in the latter). 
JVM, however, may be the best VM environment implementation out 
there and that can be useful.
Sep 05 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 05.09.2014 23:56, schrieb Dicebot:

 On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:

 You can write DLLs in Java, for example with
 http://www.excelsiorjet.com/.

 The fact that the Java reference implementation is a VM, doesn't tie
 the language to a VM.


 Why pick Java if not for JVM? It is mediocre language at most, very
 limited and poor feature-wise, lacking expressive power even compared to
 C++ (you can at least abuse templates in the latter). JVM, however, may
 be the best VM environment implementation out there and that can be useful.


Enterprise answer:

- lots of libraries to chose from;
- lots of easy to find (replacable) programmers;

--
Paulo
Sep 05 2014
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
06-Sep-2014 04:50, Paulo Pinto пишет:

 Am 05.09.2014 23:56, schrieb Dicebot:

 On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:

 You can write DLLs in Java, for example with
 http://www.excelsiorjet.com/.

 The fact that the Java reference implementation is a VM, doesn't tie
 the language to a VM.


 Why pick Java if not for JVM? It is mediocre language at most, very
 limited and poor feature-wise, lacking expressive power even compared to
 C++ (you can at least abuse templates in the latter). JVM, however, may
 be the best VM environment implementation out there and that can be
 useful.


 Enterprise answer:

 - lots of libraries to chose from;


Any JVM language has that.


 - lots of easy to find (replacable) programmers;


That is both blessing and the curse.

 --
 Paulo



-- 
Dmitry Olshansky
Sep 07 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Saturday, 6 September 2014 at 00:50:26 UTC, Paulo Pinto wrote:

 Am 05.09.2014 23:56, schrieb Dicebot:

 On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto 
 wrote:

 You can write DLLs in Java, for example with
 http://www.excelsiorjet.com/.

 The fact that the Java reference implementation is a VM, 
 doesn't tie
 the language to a VM.


 Why pick Java if not for JVM? It is mediocre language at most, 
 very
 limited and poor feature-wise, lacking expressive power even 
 compared to
 C++ (you can at least abuse templates in the latter). JVM, 
 however, may
 be the best VM environment implementation out there and that 
 can be useful.


 Enterprise answer:

 - lots of libraries to chose from;
 - lots of easy to find (replacable) programmers;

 --
 Paulo


That's exactly it, I mean the second point. This is why it's the 
preferred choice of companies and that's why they hold on to it 
(and they can pay less, based on "a dime a dozen"). Also, it's 
the safe middle ground. If a manager uses Java, s/he's sound. If 
s/he used D or something else, s/he'd have a hard time justifying 
his/her choice. Java: no questions asked.
Sep 08 2014
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 06/09/2014 01:50, Paulo Pinto wrote:

 Am 05.09.2014 23:56, schrieb Dicebot:

 On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:

 You can write DLLs in Java, for example with
 http://www.excelsiorjet.com/.

 The fact that the Java reference implementation is a VM, doesn't tie
 the language to a VM.


 Why pick Java if not for JVM? It is mediocre language at most, very
 limited and poor feature-wise, lacking expressive power even compared to
 C++ (you can at least abuse templates in the latter). JVM, however, may
 be the best VM environment implementation out there and that can be
 useful.


 Enterprise answer:

 - lots of libraries to chose from;
 - lots of easy to find (replacable) programmers;

 --
 Paulo


Also, superior development-time tools: IDEs, debuggers. (the debugging 
support could be considered part of the JVM though, depending on how you 
look at it.)

Also, me and a lot others don't agree Java is a mediocre language. It is 
basic language, yes. But a lot of good software can be written 
comfortably with just a basic language.
C++ is more *powerful* than Java, but it doesn't mean its better. I 
would rather be programming in Java over C++, any time.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 18 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 18.09.2014 17:44, schrieb Bruno Medeiros:

 On 06/09/2014 01:50, Paulo Pinto wrote:

 Am 05.09.2014 23:56, schrieb Dicebot:

 On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:

 You can write DLLs in Java, for example with
 http://www.excelsiorjet.com/.

 The fact that the Java reference implementation is a VM, doesn't tie
 the language to a VM.


 Why pick Java if not for JVM? It is mediocre language at most, very
 limited and poor feature-wise, lacking expressive power even compared to
 C++ (you can at least abuse templates in the latter). JVM, however, may
 be the best VM environment implementation out there and that can be
 useful.


 Enterprise answer:

 - lots of libraries to chose from;
 - lots of easy to find (replacable) programmers;

 --
 Paulo


 Also, superior development-time tools: IDEs, debuggers. (the debugging
 support could be considered part of the JVM though, depending on how you
 look at it.)

 Also, me and a lot others don't agree Java is a mediocre language. It is
 basic language, yes. But a lot of good software can be written
 comfortably with just a basic language.
 C++ is more *powerful* than Java, but it doesn't mean its better. I
 would rather be programming in Java over C++, any time.


I do like it, started playing with it around 1996 while at the 
university and our teachers made it right away the language for
distributed systems (remember Jini?), software architecture and compiler
design lectures (JavaCC ruled any day over yacc).

My employer very seldom does C++, mainly JVM and .NET since that is what 
our enterprise customers ask us to do.

However, thanks to Oracle disregard for the mobile space and the way 
Google tried to avoid paying for licenses, I am now forced to use C++ 
for portable native code across devices for hobby coding.

Looking to see if Java One will bring any update on this regard as 
Oracle's current proposal of JSF on the server side for mobile 
development is a joke for any native developer.

--
Paulo
Sep 18 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 18 September 2014 at 15:44:57 UTC, Bruno Medeiros 
wrote:

 Also, me and a lot others don't agree Java is a mediocre 
 language. It is basic language, yes. But a lot of good software 
 can be written comfortably with just a basic language.
 C++ is more *powerful* than Java, but it doesn't mean its 
 better. I would rather be programming in Java over C++, any 
 time.


I simply can't write any reasonable code when being restricted by 
language / VM that hard. Simply get stuck every few minutes 
realizing it is incapable of expressing models I have in mind. 
Will prefer C++ debugging madness over that 10 times out of 10.
Sep 19 2014
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 05/09/2014 14:42, Chris wrote:

 A jar can only be used by another Java program. Making a Java program
 accessible to 3rd party software via a DLL is not so simple, and the JVM
 has to be up and running all the time. Java is cross-platform as long as
 you stay within the safe and cosy Java bubble that floats on top of the
 JVM. But once you step outside of the JVM, gravity kicks in.


Exactly. But the promise of "Write once run everywhere" had always been 
if you stayed within the confines of Java/JVM. There was never a 
promise, or implication, that it would cross-platform once you started 
mixing in with foreign code.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 18 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 18 September 2014 at 15:48:46 UTC, Bruno Medeiros
wrote:

 On 05/09/2014 14:42, Chris wrote:

 A jar can only be used by another Java program. Making a Java 
 program
 accessible to 3rd party software via a DLL is not so simple, 
 and the JVM
 has to be up and running all the time. Java is cross-platform 
 as long as
 you stay within the safe and cosy Java bubble that floats on 
 top of the
 JVM. But once you step outside of the JVM, gravity kicks in.


 Exactly. But the promise of "Write once run everywhere" had 
 always been if you stayed within the confines of Java/JVM. 
 There was never a promise, or implication, that it would 
 cross-platform once you started mixing in with foreign code.


Write once, debug everywhere is more accurate.

Still prefers coding in java rather than C++ .
Sep 18 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 18 September 2014 at 22:24:14 UTC, deadalnix wrote:

 On Thursday, 18 September 2014 at 15:48:46 UTC, Bruno Medeiros
 wrote:

 On 05/09/2014 14:42, Chris wrote:

 A jar can only be used by another Java program. Making a Java 
 program
 accessible to 3rd party software via a DLL is not so simple, 
 and the JVM
 has to be up and running all the time. Java is cross-platform 
 as long as
 you stay within the safe and cosy Java bubble that floats on 
 top of the
 JVM. But once you step outside of the JVM, gravity kicks in.


 Exactly. But the promise of "Write once run everywhere" had 
 always been if you stayed within the confines of Java/JVM. 
 There was never a promise, or implication, that it would 
 cross-platform once you started mixing in with foreign code.


 Write once, debug everywhere is more accurate.


That's exactly my experience. It is inevitable that when you 
write a real program (not some Java tutorial shite) you will have 
to communicate in some way with the underlying OS. And that's 
when you have to leave the JVM, which is like entering a jungle 
full of wild animals after getting up from your cosy middle class 
armchair.


 Still prefers coding in java rather than C++ .


I jumped from Java and Objective-C to D (well, there were other 
languages, but none of them would do). And as Dicebot said, the 
modelling power of D is just amazing. Every time I code and 
recode I'm surprised at what you can do in D. Java wouldn't allow 
you to do all those things without numerous hacks. It keeps you 
in a straight jacket (which is why the industry loves it, nobody 
steps out of line, well defined rules, no place for mad hackers 
and other geniuses, keep the salaries low, a dime a dozen, but I 
degress as usual).
Sep 19 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 19/09/2014 12:34, Chris wrote:

 keep the salaries low


HAHAHAHAHAHAHA......
Man, that was so funny, good one, bro!

Java salaries low, lol...

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 23 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Sep 2014 14:42:39 +0100
Bruno Medeiros via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Java salaries low, lol...


yes, they are. but java programmers believe that they are somehow
"high-payed professionals". it helps alot when hiring new java
codemonkey.
Sep 23 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 23 September 2014 at 17:59:33 UTC, ketmar via 
Digitalmars-d wrote:

 On Tue, 23 Sep 2014 14:42:39 +0100
 Bruno Medeiros via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 Java salaries low, lol...


 yes, they are. but java programmers believe that they are 
 somehow
 "high-payed professionals". it helps alot when hiring new java
 codemonkey.


Of course, the more Java programmers you have (and you have a 
lot), the less you need to pay. A dime a dozen. These are the 
rules of the same market that hypes languages like Java. Ain't no 
rocket sciences. Sure, if you've managed to become a 
software-architecture-project-manager guru somewhere, you'll get 
a good salary. But all the coders from entry to mid level don't 
get that much, because they are "replaceable", as they say.

Another thing about Java (a social aspect) is that everybody, not 
just programmers, have heard of it somehow. So to be a "Java 
developer" sounds good and acceptable. People can vaguely imagine 
some sort of programming / IT thing. It's the perfect job to 
mention to your future in-laws, ha ha ha.
Sep 23 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 23.09.2014 21:23, schrieb Chris:

 On Tuesday, 23 September 2014 at 17:59:33 UTC, ketmar via Digitalmars-d
 wrote:

 On Tue, 23 Sep 2014 14:42:39 +0100
 Bruno Medeiros via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Java salaries low, lol...


 yes, they are. but java programmers believe that they are somehow
 "high-payed professionals". it helps alot when hiring new java
 codemonkey.


 Of course, the more Java programmers you have (and you have a lot), the
 less you need to pay. A dime a dozen. These are the rules of the same
 market that hypes languages like Java. Ain't no rocket sciences. Sure,
 if you've managed to become a software-architecture-project-manager guru
 somewhere, you'll get a good salary. But all the coders from entry to
 mid level don't get that much, because they are "replaceable", as they say.

 Another thing about Java (a social aspect) is that everybody, not just
 programmers, have heard of it somehow. So to be a "Java developer"
 sounds good and acceptable. People can vaguely imagine some sort of
 programming / IT thing. It's the perfect job to mention to your future
 in-laws, ha ha ha.


Lets just say my employer consulting fees and what I get from them, keep 
my accountant very very very happy.

--
Paulo
Sep 23 2014
parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 23 September 2014 at 22:05:35 UTC, Paulo Pinto wrote:

 Am 23.09.2014 21:23, schrieb Chris:

 On Tuesday, 23 September 2014 at 17:59:33 UTC, ketmar via 
 Digitalmars-d
 wrote:

 On Tue, 23 Sep 2014 14:42:39 +0100
 Bruno Medeiros via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:


 Java salaries low, lol...


 yes, they are. but java programmers believe that they are 
 somehow
 "high-payed professionals". it helps alot when hiring new java
 codemonkey.


 Of course, the more Java programmers you have (and you have a 
 lot), the
 less you need to pay. A dime a dozen. These are the rules of 
 the same
 market that hypes languages like Java. Ain't no rocket 
 sciences. Sure,
 if you've managed to become a 
 software-architecture-project-manager guru
 somewhere, you'll get a good salary. But all the coders from 
 entry to
 mid level don't get that much, because they are "replaceable", 
 as they say.

 Another thing about Java (a social aspect) is that everybody, 
 not just
 programmers, have heard of it somehow. So to be a "Java 
 developer"
 sounds good and acceptable. People can vaguely imagine some 
 sort of
 programming / IT thing. It's the perfect job to mention to 
 your future
 in-laws, ha ha ha.


 Lets just say my employer consulting fees and what I get from 
 them, keep my accountant very very very happy.

 --
 Paulo


Let's just say that you've been in that game for a long time now. 
Ask someone who is looking for a job with Java right now. An 
entry level job. Different story. But maybe things are different 
in different countries.
Sep 24 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2014-08-25 at 09:55 +0200, Marco Leise via Digitalmars-d wrote:
[=E2=80=A6]

 Yes, Java is verbose, but its modularity makes it very
 flexible. The classic example is how you read lines of text
 from a file. Instead of a special class for that, you take
 use simple primitives with descriptive names and assemble
 something that reads lines of UTF-8 text from a buffer that
 has a file as its input. It actually acknowledges quite a bit
 of real-world mess when you look at it, for example different
 encodings on stdin and stdout.


Groovy makes it even easier. I avoid using Java if I can use Groovy,
which is about 100% of the time now with  CompileStatic.


 Conventions like beans, where every property is implemented as
 a pair of getter/setter or naming rules like ...Adapter,


The Bean Protocol is about the worst offence committed by the Java
Platform. It destroys encapsulation and any thought of object-oriented
programming.


 ...Comparator make it easy to reflect on unknown code.


Java reflection is really a bit of a mess. Another reason for using
Groovy it makes working with the JVM reflection system much easier.


 On the one hand it is limiting to only have Java OOP in the
 toolbox, on the other hand it is cheap to train someone on
 Java and Java libraries and actually not a horror to try and
 make sense of other people's code, because it wont be
 implemented in any of 5 different paradigms + s.o.'s personal
 naming conventions.


Java "OOP" isn't really OOP.=20


 I've never been a fan of developing in vi or emacs and as far
 as I am concerned, a programming language need not be designed
 like a human language. There are many graphical programming
 environments as well, for example for physics.


Emacs is the One True Editor, not using it is clearly a declaration of
war :-)


 The simpler the language the more robust the refactoring tools
 can become. The more conventions are in use, the better custom
 tailored tools and IDEs can emerge. I.e. in Eclipse you only
 type the capital letters of a long class name and have the
 auto-completion figure out which class in scope or available
 import paths matches these "initials". Heck, it even fills in
 the parameters when you call a method using the available
 variables in scope. If you were unaware that you need a third
 argument, the IDE can generate a new variable with a name
 based on the method parameter or place a constructor call for
 the required type.
 Sometimes you can just focus on the program logic and have the

 expose properties of GUI objects in tables and generate the
 code for event handlers on double-clicks. It saves time, you
 cannot misspell anything... I like it.


I switch between Emacs, Vi, Eclipse, IntelliJ IDEA, PyCharm, Wing IDE,
depending on programming language and activity. None of the tools work
for all situations. It would be nice if they did, but there is always
something wrong for a given activity.

IDE popups can be a useful tool, the problem with over-reliance,
particularly for the weaker programmers is that they create code they do
not understand. In the Eclipse/Java context, I see far too much in the
way of "form filling of template" type programming by people who are
working under the impression that because they are using a template
nothing can go wrong.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 25 2014
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On 25.08.2014 10:55, Marco Leise wrote:

 Am Sat, 12 Jul 2014 11:38:08 +0100
 schrieb Russel Winder via Digitalmars-d
 <digitalmars-d puremagic.com>:


 That's not to say that Java, the language, (as opposed to the class
 library or the marketing hype) isn't a pretty good language. In fact,
 it's quite a beautiful language -- in the idealistic, ivory tower,
 detached-from-real-life sense of being a perfect specimen suitable for a
 museum piece. Its disconnect from the messy real world, unfortunately,
 makes it rather painful to use in real-life. Well, except with the help
 of automated tools like IDEs and what-not, which makes one wonder, if we
 need a machine to help us communicate with a machine, why not just write
 assembly language instead? But I digress. :-P


 Now this is mis-direction. Java is a real-world language in that it is
 used in the real world. Whilst there are many using Java because they
 know no better, many are using it out of choice. Java evolves with the
 needs of the users prepared to get involved in evolving the language.


 Yes, Java is verbose, but its modularity makes it very
 flexible. The classic example is how you read lines of text
 from a file. Instead of a special class for that, you take
 use simple primitives with descriptive names and assemble
 something that reads lines of UTF-8 text from a buffer that
 has a file as its input. It actually acknowledges quite a bit
 of real-world mess when you look at it, for example different
 encodings on stdin and stdout.
 Conventions like beans, where every property is implemented as
 a pair of getter/setter or naming rules like ...Adapter,
 ...Comparator make it easy to reflect on unknown code.
 On the one hand it is limiting to only have Java OOP in the
 toolbox, on the other hand it is cheap to train someone on
 Java and Java libraries and actually not a horror to try and
 make sense of other people's code, because it wont be
 implemented in any of 5 different paradigms + s.o.'s personal
 naming conventions.
 I've never been a fan of developing in vi or emacs and as far
 as I am concerned, a programming language need not be designed
 like a human language. There are many graphical programming
 environments as well, for example for physics.
 The simpler the language the more robust the refactoring tools
 can become. The more conventions are in use, the better custom
 tailored tools and IDEs can emerge. I.e. in Eclipse you only
 type the capital letters of a long class name and have the
 auto-completion figure out which class in scope or available
 import paths matches these "initials". Heck, it even fills in
 the parameters when you call a method using the available
 variables in scope. If you were unaware that you need a third
 argument, the IDE can generate a new variable with a name
 based on the method parameter or place a constructor call for
 the required type.
 Sometimes you can just focus on the program logic and have the

 expose properties of GUI objects in tables and generate the
 code for event handlers on double-clicks. It saves time, you
 cannot misspell anything... I like it.



Agree, follows my experience in the industry as well. Although sometimes
I am a bit dismayed by the skill level of certain programmers we get in 
our projects.

I am also an IDE fan. Can master Emacs and dabble in VI, but IDE are the
way to go, since my MS-DOS/Amiga days.

--
Paulo
Aug 25 2014
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12 July 2014 11:27, Russel Winder via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Fri, 2014-07-11 at 16:54 +0000, Chris via Digitalmars-d wrote:
 […]

 I remember Java used to be "theeee" best thing ever. After years
 of using it, however, I found out how restricted the language was
 / is. Still, it's been a success, because people believed all the
 propaganda. What matters to me is not so much the odd fancy
 feature, it's how well the language performs in general purpose
 programming. Go was designed for servers and thus will always
 have one up on D or any other language at that matter. But could
 I use Go for what I have used D? Not so sure about that. Also,
 like Java Go is a closed thing. D isn't. Once I read about D that
 it shows what can be done "once you take a language out of the
 hands of a committee". Go, like Java, will finally end up in a
 cul de sac and will have a hard time trying to get out of it. Not
 because the language is inherently bad, because it's in the hand
 of a committee. Ideology kills a language. But it doesn't matter,
 because people will use Go or whatever anyway, will _have_ to use
 it.


 People believed the FORTRAN propaganda, the COBOL propaganda, the Pascal
 propaganda. I think we ought to distinguish good marketing from hype.
 Java had good marketing, was in the right place at the right time, and
 had a huge amount of hype as well.

 If Go is better for server things than D then might as well stop trying
 to use D at all.

 Go was actually designed as a better C with CSP for concurrency and
 parallelism.


Or a better Oberon, I haven't quite decided which yet... :)


 If there were more D users in the London area than one in London and one
 in Brighton maybe we could start a London D User Group (LonDUG).
 SkillsMatter would host.


And I say Hello! from sunny Brighton.


I do believe there are a few people around the London area who either
have worked in, work in, or have a vested interest in D.  I'll give
Dejan a poke and find out some more numbers.

Regards
Iain.
Jul 12 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 12.07.2014 14:54, schrieb Iain Buclaw via Digitalmars-d:

 On 12 July 2014 11:27, Russel Winder via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Fri, 2014-07-11 at 16:54 +0000, Chris via Digitalmars-d wrote:
 […]

 I remember Java used to be "theeee" best thing ever. After years
 of using it, however, I found out how restricted the language was
 / is. Still, it's been a success, because people believed all the
 propaganda. What matters to me is not so much the odd fancy
 feature, it's how well the language performs in general purpose
 programming. Go was designed for servers and thus will always
 have one up on D or any other language at that matter. But could
 I use Go for what I have used D? Not so sure about that. Also,
 like Java Go is a closed thing. D isn't. Once I read about D that
 it shows what can be done "once you take a language out of the
 hands of a committee". Go, like Java, will finally end up in a
 cul de sac and will have a hard time trying to get out of it. Not
 because the language is inherently bad, because it's in the hand
 of a committee. Ideology kills a language. But it doesn't matter,
 because people will use Go or whatever anyway, will _have_ to use
 it.


 People believed the FORTRAN propaganda, the COBOL propaganda, the Pascal
 propaganda. I think we ought to distinguish good marketing from hype.
 Java had good marketing, was in the right place at the right time, and
 had a huge amount of hype as well.

 If Go is better for server things than D then might as well stop trying
 to use D at all.

 Go was actually designed as a better C with CSP for concurrency and
 parallelism.


 Or a better Oberon, I haven't quite decided which yet... :)



No, Oberon is still better.

Active Oberon has concurrency support via active objects and contrary to 
Go, has first class support for systems programming. Oh and the last 
versions even had a primitive version of generics.

Only thing I dislike in Wirth's languages is the need of uppercase 
keywords, but all modern editors can do a "replace as you type" kind of 
thing anyway.


--
Paulo
Jul 12 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2014-07-12 at 13:54 +0100, Iain Buclaw via Digitalmars-d wrote:
[=E2=80=A6]

 Or a better Oberon, I haven't quite decided which yet... :)


Whatever the reality initially, it is definitely now marketed as a
modernized C. Echoes of C++ then.


 If there were more D users in the London area than one in London and on=




e

 in Brighton maybe we could start a London D User Group (LonDUG).
 SkillsMatter would host.


=20
 And I say Hello! from sunny Brighton.


Aha the Brighton dwelling D user of note ;-)

I have lived in Brighton, but it was a long time ago, it is probably
very different now. No West Pier for a start!


 I do believe there are a few people around the London area who either
 have worked in, work in, or have a vested interest in D.  I'll give
 Dejan a poke and find out some more numbers.


We could start a code dojo to build up an initial activity and then
spawn off public meetings with tutorial style material to attract people
new to D. "D for C++ programmers", "D for C programmers", "D for Python
programmers", "D for JavaScript kiddies",=E2=80=A6

We might initially draw on the ACCU London people to gauge interest.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 12 2014
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12 July 2014 15:11, Russel Winder via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sat, 2014-07-12 at 13:54 +0100, Iain Buclaw via Digitalmars-d wrote:
 […]

 Or a better Oberon, I haven't quite decided which yet... :)


 Whatever the reality initially, it is definitely now marketed as a
 modernized C. Echoes of C++ then.


 If there were more D users in the London area than one in London and one
 in Brighton maybe we could start a London D User Group (LonDUG).
 SkillsMatter would host.


 And I say Hello! from sunny Brighton.


 Aha the Brighton dwelling D user of note ;-)

 I have lived in Brighton, but it was a long time ago, it is probably
 very different now. No West Pier for a start!


I live literally 400 yards away from the burnt down west pier.  Its a
beautiful sight in the morning, come sun, rain, or fog.  I hear they
are building a 100 metre high elevator-to-nowhere in its place.  Sad
times...



 I do believe there are a few people around the London area who either
 have worked in, work in, or have a vested interest in D.  I'll give
 Dejan a poke and find out some more numbers.


 We could start a code dojo to build up an initial activity and then
 spawn off public meetings with tutorial style material to attract people
 new to D. "D for C++ programmers", "D for C programmers", "D for Python
 programmers", "D for JavaScript kiddies",…

 We might initially draw on the ACCU London people to gauge interest.


I can give you my details, and can see where things go from there.

Regards
Iain.
Jul 12 2014
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2014-07-12 at 15:37 +0100, Iain Buclaw via Digitalmars-d wrote:
[=E2=80=A6]

 I live literally 400 yards away from the burnt down west pier.  Its a
 beautiful sight in the morning, come sun, rain, or fog.  I hear they
 are building a 100 metre high elevator-to-nowhere in its place.  Sad
 times...


We lived for a while in Little Western Street. Even then the West Pier
was crumbling and was closed a short while after we wandered up and down
it one afternoon in glorious (very un-English) sun.=20

[=E2=80=A6]

=20
 I can give you my details, and can see where things go from there.


Is evening meetings in London something you might be up for?

Depending on who is involved and what constitutes the "centre of mass",
there is always the option of meeting in a pub in Clapham Junction =E2=80=
=93
saves the extra haul across Central London.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 12 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/12/2014 7:53 AM, Russel Winder via Digitalmars-d wrote:

 Is evening meetings in London something you might be up for?

 Depending on who is involved and what constitutes the "centre of mass",
 there is always the option of meeting in a pub in Clapham Junction –
 saves the extra haul across Central London.



Wish I could be there!
Jul 13 2014
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12 July 2014 15:53, Russel Winder via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sat, 2014-07-12 at 15:37 +0100, Iain Buclaw via Digitalmars-d wrote:
 […]

 I live literally 400 yards away from the burnt down west pier.  Its a
 beautiful sight in the morning, come sun, rain, or fog.  I hear they
 are building a 100 metre high elevator-to-nowhere in its place.  Sad
 times...


 We lived for a while in Little Western Street. Even then the West Pier
 was crumbling and was closed a short while after we wandered up and down
 it one afternoon in glorious (very un-English) sun.

 […]

 I can give you my details, and can see where things go from there.


 Is evening meetings in London something you might be up for?

 Depending on who is involved and what constitutes the "centre of mass",
 there is always the option of meeting in a pub in Clapham Junction –
 saves the extra haul across Central London.


That sounds like at least the beginnings of a plan to me.  My only way
of getting around would be train due to lack of a car, or license.
Jul 12 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/12/2014 8:03 AM, Iain Buclaw via Digitalmars-d wrote:

 My only way
 of getting around would be train due to lack of a car, or license.


A lack of a car would be an advantage in London. I've touristed around there a 
bit, and never felt the need for a car, nor would I have ever wanted to try and 
find a parking space.
Jul 13 2014
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 July 2014 08:21, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 7/12/2014 8:03 AM, Iain Buclaw via Digitalmars-d wrote:

 My only way
 of getting around would be train due to lack of a car, or license.



 A lack of a car would be an advantage in London. I've touristed around there
 a bit, and never felt the need for a car, nor would I have ever wanted to
 try and find a parking space.


This I find is England in general.
Jul 16 2014
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12 Jul 2014 16:03, "Iain Buclaw" <ibuclaw gdcproject.org> wrote:

 On 12 July 2014 15:53, Russel Winder via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sat, 2014-07-12 at 15:37 +0100, Iain Buclaw via Digitalmars-d wrote:
 [=E2=80=A6]

 I live literally 400 yards away from the burnt down west pier.  Its a
 beautiful sight in the morning, come sun, rain, or fog.  I hear they
 are building a 100 metre high elevator-to-nowhere in its place.  Sad
 times...


 We lived for a while in Little Western Street. Even then the West Pier
 was crumbling and was closed a short while after we wandered up and dow=




n

 it one afternoon in glorious (very un-English) sun.

 [=E2=80=A6]

 I can give you my details, and can see where things go from there.


 Is evening meetings in London something you might be up for?

 Depending on who is involved and what constitutes the "centre of mass",
 there is always the option of meeting in a pub in Clapham Junction =E2=




=80=93

 saves the extra haul across Central London.


 That sounds like at least the beginnings of a plan to me.  My only way
 of getting around would be train due to lack of a car, or license.


Hey Russel,

Have you got anywhere with planning this?  I'd be happy to help out with
anything.

Iain.
Aug 21 2014
parent reply "Colin" <grogan.colin gmail.com> writes:
On Thursday, 21 August 2014 at 10:06:25 UTC, Iain Buclaw via 
Digitalmars-d wrote:

 On 12 Jul 2014 16:03, "Iain Buclaw" <ibuclaw gdcproject.org> 
 wrote:

 On 12 July 2014 15:53, Russel Winder via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sat, 2014-07-12 at 15:37 +0100, Iain Buclaw via 
 Digitalmars-d wrote:
 […]

 I live literally 400 yards away from the burnt down west 
 pier.  Its a
 beautiful sight in the morning, come sun, rain, or fog.  I 
 hear they
 are building a 100 metre high elevator-to-nowhere in its 
 place.  Sad
 times...


 We lived for a while in Little Western Street. Even then the 
 West Pier
 was crumbling and was closed a short while after we wandered 
 up and down
 it one afternoon in glorious (very un-English) sun.

 […]

 I can give you my details, and can see where things go from 
 there.


 Is evening meetings in London something you might be up for?

 Depending on who is involved and what constitutes the 
 "centre of mass",
 there is always the option of meeting in a pub in Clapham 
 Junction –
 saves the extra haul across Central London.


 That sounds like at least the beginnings of a plan to me.  My 
 only way
 of getting around would be train due to lack of a car, or 
 license.


 Hey Russel,

 Have you got anywhere with planning this?  I'd be happy to help 
 out with
 anything.

 Iain.


Is this the beginnings of a London based DConf?
(Note: That'd be great!)
Aug 25 2014
next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2014-08-25 at 08:40 +0000, Colin via Digitalmars-d wrote:
[=E2=80=A6]

=20
 Is this the beginnings of a London based DConf?
 (Note: That'd be great!)


Whilst it would be good for DConf to come to London for 2015 (*) this
was about having a London D User Group meeting, hopefully on a regular
basis (**).


(*) I am sure we could get Skills Matter to run it.

(**) Skills Matter would definitely host this for us.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 25 2014
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 25 August 2014 12:19, Russel Winder via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Mon, 2014-08-25 at 08:40 +0000, Colin via Digitalmars-d wrote:
 […]

 Is this the beginnings of a London based DConf?
 (Note: That'd be great!)


 Whilst it would be good for DConf to come to London for 2015 (*) this
 was about having a London D User Group meeting, hopefully on a regular
 basis (**).


 (*) I am sure we could get Skills Matter to run it.

 (**) Skills Matter would definitely host this for us.


Perhaps we should send a probe out ot see how many people would be:

[ ] Interested  [ ] Undecided  [ ] Not Interested

in wanting to come down to such a meeting.  Also topics for discussion. :)

Iain.
Aug 26 2014
parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 26 August 2014 at 10:27:47 UTC, Iain Buclaw via 
Digitalmars-d wrote:

 Perhaps we should send a probe out ot see how many people would 
 be:

 [ ] Interested  [ ] Undecided  [ ] Not Interested

 in wanting to come down to such a meeting.  Also topics for 
 discussion. :)

 Iain.


I totally hope to see you all in Brussels if FOSDEM proposal will 
fly ;)
Aug 26 2014
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-08-26 at 11:27 +0100, Iain Buclaw via Digitalmars-d wrote:

 On 25 August 2014 12:19, Russel Winder via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Mon, 2014-08-25 at 08:40 +0000, Colin via Digitalmars-d wrote:
 [=E2=80=A6]

 Is this the beginnings of a London based DConf?
 (Note: That'd be great!)


 Whilst it would be good for DConf to come to London for 2015 (*) this
 was about having a London D User Group meeting, hopefully on a regular
 basis (**).


 (*) I am sure we could get Skills Matter to run it.

 (**) Skills Matter would definitely host this for us.


=20
 Perhaps we should send a probe out ot see how many people would be:
=20
 [ ] Interested  [ ] Undecided  [ ] Not Interested


I am definitely Interested.


 in wanting to come down to such a meeting.  Also topics for discussion. :=


)

We could also mix and match as many other user groups do. So for example
some have a presentation session one month, drinks session the next.
Others are entirely code dojo oriented. I see no reason not to embrace
all things that can be done when people get together. So some
presentation sessions, possibly with longer and lightning talks mixed,
some short hackergarten events, etc.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 26 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jul 11, 2014 at 03:30:15PM +0000, Chris via Digitalmars-d wrote:

 I have followed the recent discussions about D and I can see the usual
 pattern, to wit GC, Go (or whatever) is so much better, everyone
 blaming each other for not contributing, not being allowed to
 contribute blah.


Well, this forum *is* for discussing ways of improving D, so it
shouldn't be surprising that we constantly find things to nitpick about.
:-) It doesn't mean at all that D is lousy or the community is bad, 'cos
if it were so, we wouldn't even be here to begin with. We're here 'cos
we care, and we complain 'cos we care enough to want things to improve.



 First of all, I am in no position to criticize anyone who is
 contributing to the language. I don't contribute, because I don't have
 the time to do so.  Indeed I have huge, massive respect for everyone
 who contributes to D. The only thing I do is to actually use the
 language and tell everyone about it.  I have developed a screen reader
 plug in in D (using C libraries) that was ridiculously easy to
 integrate on Windows as a DLL. I used vibe.d to create a lightning
 fast online version of the screen reader. Believe me, D's supposed
 sluggishness as regards GC is not so important for most applications.
 I dare say 90% of all applications are fine with the current GC. I
 compiled both applications with dmd (testing phase) not with ldc or
 gdc and they are very fast.


I agree. I'm still convinced that GC phobia is blown out of proportion
-- I used to be in that camp, so I totally sympathize with where they're
coming from -- but as you say, only a small percentage of applications
actually need to squeeze every last cycle out of the CPU such that the
GC actually starts to make a significant difference in performance. Most
applications work just fine with the GC, and in fact, I'd argue that
they work *better* with the GC, because manual memory management is
*hard* (just look at how many security exploits are caused by memory
management mistakes) and tedious (look at how often the same memory bugs
are repeated over and over).  GC-supported code is cleaner to read,
easier to write, and in many cases, the simpler design of the code
reduces the likelihood of bugs and eliminates a whole class of bugs.
Sure you pay for that by short pauses every now and then, but seriously,
90% of applications don't even *care* about such pauses.

For applications with slightly higher performance demands, gdc -O3 (or
whatever the LDC equivalent is) generally improves performance by about
20% or so above dmd. In my own compute-intensive projects, I have
consistently noted about a 20-30% performance improvement when compiling
with gdc, compared to dmd. That's pretty significant, because GC pauses
are generally nowhere near that percentage, so just by recompiling with
gdc already eliminates the perceived GC performance issue for 95% of
applications. Besides, avoiding frequent small allocations also reduces
most of the workload of the GC, so you can still get pretty far without
totally turning it off.

So it's really only the remaining 5% of applications that really,
absolutely, *have* to go GC-less (or control it very tightly). They do
happen to have supporters of the rather vocal kind, so we tend to hear
from them a lot more, but that by no means is representative of the
grand scheme of things as far as the GC is concerned!


[...]

 Let's first make a list of things that have been achieved with D and
 that are on a par with or even bettar than in other languages (C, C++,




but at least as far as C/C++ are concerned, D totally beats them flat in
the following points IMO:

- Metaprogramming. Templates in C++ scarred many for life. Templates in
  D are actually a pleasure to use.

- CTFE. Coupled with metaprogramming, this is a total killer combination
  that I've yet to see another language beat.

- Slices. Finally, a systems-level language whose string support isn't
  crippled (C), maimed (C++), or otherwise handicapped (Java). And this
  extends to arrays in general. While there *are* other language with
  nice string/array manipulation support, D is the only one I know of
  that does it without sacrificing performance.

- Ranges. It can totally revolutionize the way you approach programming.
  And, with metaprogramming/CTFE, they can still perform as fast as
  non-range-based code. Total win!

- Extended meaning of purity: IMO it's a total stroke of genius to
  define "weak purity" that allows you to implement pure functions (in
  the Haskell sense) using mutating primitives (loops and assignments,
  etc.). While the current compilers don't really do that much with this
  presently, there is a lot of potential here that may turn this into a
  killer feature.

- Built-in unittests. Sounds trivial, but I can testify to its value in
  dramatically improving the quality of my code. I've worked with large
  C/C++ codebases, and most of them don't even bother with any kind of
  unit testing -- it's up to the programmer to test everything, and we
  just take his word for it -- and simply accept the countless stream of
  bugs that come thereafter as a fact of life. Of the rare few that
  actually do have tests, the tests are usually (1) outdated, (2)
  commented out 'cos nobody cares to update them, (3) ignored by the
  coders anyway 'cos they can't be bothered to switch to another
  language in another framework just to write tests that nobody will run
  while having their hands tied behind their back. D's built-in unittest
  blocks is a total game changer in this area, in spite of its
  simplicity (which some people have complained about).

   - Along these lines, static assert totally rawkz. It ensures, at
     *compile-time*, that assumptions in your code haven't been violated
     by a careless code change, forcing the person who made the change
     to fix it (rather than introducing a possibly subtle error that
     will only be uncovered months down the road on the customer's
     production site).

- The fastest regex library known on the planet (thanks to, guess what?
  metaprogramming and CTFE!). I'm a regex aficionado, and this is a
  total big deal in my book.

- Built-in Unicode support. Compiler-level support for Unicode is
  something C/C++ sorely lacks, and that immediately puts them in the
  "legacy" category. LibICU is a nightmare to use. D, however, lets you
  treat Unicode directly in the language. (Full Unicode compliance isn't
  quite there yet, but we're getting pretty close.) Modern languages

  par with them. C/C++ is definitely behind in this category, though.

These are just language-level cool stuff. At a higher level, we also
have:

- rdmd: run your D programs like scripts, yet with native compiled
  performance. Rawkage!

- Dustmite: a totally revolutionary tool IMO, that changes finding
  heisenbugs from an impossible game of chance to something that
  actually has hope of being fixed within reasonable amounts of time.

- vibe.d: I haven't used it myself, but from what I hear, it's extremely
  awesome.

I'm sure there are many other items that can be added, but this should
be a good start. :)


T

-- 
If it breaks, you get to keep both pieces. -- Software disclaimer notice
Jul 11 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Fri, Jul 11, 2014 at 03:30:15PM +0000, Chris via 
 Digitalmars-d wrote:

 I have followed the recent discussions about D and I can see 
 the usual
 pattern, to wit GC, Go (or whatever) is so much better, 
 everyone
 blaming each other for not contributing, not being allowed to
 contribute blah.


 Well, this forum *is* for discussing ways of improving D, so it
 shouldn't be surprising that we constantly find things to 
 nitpick about.
 :-) It doesn't mean at all that D is lousy or the community is 
 bad, 'cos
 if it were so, we wouldn't even be here to begin with. We're 
 here 'cos
 we care, and we complain 'cos we care enough to want things to 
 improve.



 First of all, I am in no position to criticize anyone who is
 contributing to the language. I don't contribute, because I 
 don't have
 the time to do so.  Indeed I have huge, massive respect for 
 everyone
 who contributes to D. The only thing I do is to actually use 
 the
 language and tell everyone about it.  I have developed a 
 screen reader
 plug in in D (using C libraries) that was ridiculously easy to
 integrate on Windows as a DLL. I used vibe.d to create a 
 lightning
 fast online version of the screen reader. Believe me, D's 
 supposed
 sluggishness as regards GC is not so important for most 
 applications.
 I dare say 90% of all applications are fine with the current 
 GC. I
 compiled both applications with dmd (testing phase) not with 
 ldc or
 gdc and they are very fast.


 I agree. I'm still convinced that GC phobia is blown out of 
 proportion
 -- I used to be in that camp, so I totally sympathize with 
 where they're
 coming from -- but as you say, only a small percentage of 
 applications
 actually need to squeeze every last cycle out of the CPU such 
 that the
 GC actually starts to make a significant difference in 
 performance. Most
 applications work just fine with the GC, and in fact, I'd argue 
 that
 they work *better* with the GC, because manual memory 
 management is
 *hard* (just look at how many security exploits are caused by 
 memory
 management mistakes) and tedious (look at how often the same 
 memory bugs
 are repeated over and over).  GC-supported code is cleaner to 
 read,
 easier to write, and in many cases, the simpler design of the 
 code
 reduces the likelihood of bugs and eliminates a whole class of 
 bugs.
 Sure you pay for that by short pauses every now and then, but 
 seriously,
 90% of applications don't even *care* about such pauses.

 For applications with slightly higher performance demands, gdc 
 -O3 (or
 whatever the LDC equivalent is) generally improves performance 
 by about
 20% or so above dmd. In my own compute-intensive projects, I 
 have
 consistently noted about a 20-30% performance improvement when 
 compiling
 with gdc, compared to dmd. That's pretty significant, because 
 GC pauses
 are generally nowhere near that percentage, so just by 
 recompiling with
 gdc already eliminates the perceived GC performance issue for 
 95% of
 applications. Besides, avoiding frequent small allocations also 
 reduces
 most of the workload of the GC, so you can still get pretty far 
 without
 totally turning it off.

 So it's really only the remaining 5% of applications that 
 really,
 absolutely, *have* to go GC-less (or control it very tightly). 
 They do
 happen to have supporters of the rather vocal kind, so we tend 
 to hear
 from them a lot more, but that by no means is representative of 
 the
 grand scheme of things as far as the GC is concerned!


 [...]

 Let's first make a list of things that have been achieved with 
 D and
 that are on a par with or even bettar than in other languages 
 (C, C++,




 that front,
 but at least as far as C/C++ are concerned, D totally beats 
 them flat in
 the following points IMO:

 - Metaprogramming. Templates in C++ scarred many for life. 
 Templates in
   D are actually a pleasure to use.

 - CTFE. Coupled with metaprogramming, this is a total killer 
 combination
   that I've yet to see another language beat.

 - Slices. Finally, a systems-level language whose string 
 support isn't
   crippled (C), maimed (C++), or otherwise handicapped (Java). 
 And this
   extends to arrays in general. While there *are* other 
 language with
   nice string/array manipulation support, D is the only one I 
 know of
   that does it without sacrificing performance.

 - Ranges. It can totally revolutionize the way you approach 
 programming.
   And, with metaprogramming/CTFE, they can still perform as 
 fast as
   non-range-based code. Total win!

 - Extended meaning of purity: IMO it's a total stroke of genius 
 to
   define "weak purity" that allows you to implement pure 
 functions (in
   the Haskell sense) using mutating primitives (loops and 
 assignments,
   etc.). While the current compilers don't really do that much 
 with this
   presently, there is a lot of potential here that may turn 
 this into a
   killer feature.

 - Built-in unittests. Sounds trivial, but I can testify to its 
 value in
   dramatically improving the quality of my code. I've worked 
 with large
   C/C++ codebases, and most of them don't even bother with any 
 kind of
   unit testing -- it's up to the programmer to test everything, 
 and we
   just take his word for it -- and simply accept the countless 
 stream of
   bugs that come thereafter as a fact of life. Of the rare few 
 that
   actually do have tests, the tests are usually (1) outdated, 
 (2)
   commented out 'cos nobody cares to update them, (3) ignored 
 by the
   coders anyway 'cos they can't be bothered to switch to another
   language in another framework just to write tests that nobody 
 will run
   while having their hands tied behind their back. D's built-in 
 unittest
   blocks is a total game changer in this area, in spite of its
   simplicity (which some people have complained about).

    - Along these lines, static assert totally rawkz. It 
 ensures, at
      *compile-time*, that assumptions in your code haven't been 
 violated
      by a careless code change, forcing the person who made the 
 change
      to fix it (rather than introducing a possibly subtle error 
 that
      will only be uncovered months down the road on the 
 customer's
      production site).

 - The fastest regex library known on the planet (thanks to, 
 guess what?
   metaprogramming and CTFE!). I'm a regex aficionado, and this 
 is a
   total big deal in my book.

 - Built-in Unicode support. Compiler-level support for Unicode 
 is
   something C/C++ sorely lacks, and that immediately puts them 
 in the
   "legacy" category. LibICU is a nightmare to use. D, however, 
 lets you
   treat Unicode directly in the language. (Full Unicode 
 compliance isn't
   quite there yet, but we're getting pretty close.) Modern 
 languages

 least on
   par with them. C/C++ is definitely behind in this category, 
 though.

 These are just language-level cool stuff. At a higher level, we 
 also
 have:

 - rdmd: run your D programs like scripts, yet with native 
 compiled
   performance. Rawkage!

 - Dustmite: a totally revolutionary tool IMO, that changes 
 finding
   heisenbugs from an impossible game of chance to something that
   actually has hope of being fixed within reasonable amounts of 
 time.

 - vibe.d: I haven't used it myself, but from what I hear, it's 
 extremely
   awesome.

 I'm sure there are many other items that can be added, but this 
 should
 be a good start. :)


 T


Thanks. That's a nice list. This is what I was talking about, the 
experience with D, what you can achieve with it and how it 
compares with other languages. We need more of this. I have the 
feeling sometimes that to an outsider D might look like an 
eternally unfinished business. A nice playground for programmers, 
but not for production, which is absolutely not true. The GC 
issue is sometimes presented as "the language will stand or fall 
with this". As you noted and which is also my experience, the GC 
issue ain't that big. 90-95% of all applications can live with it.
Jul 11 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jul 11, 2014 at 05:39:30PM +0000, Chris via Digitalmars-d wrote:
[...]

 Thanks. That's a nice list. This is what I was talking about, the
 experience with D, what you can achieve with it and how it compares
 with other languages. We need more of this. I have the feeling
 sometimes that to an outsider D might look like an eternally
 unfinished business. A nice playground for programmers, but not for
 production, which is absolutely not true. The GC issue is sometimes
 presented as "the language will stand or fall with this". As you noted
 and which is also my experience, the GC issue ain't that big. 90-95%
 of all applications can live with it.


Oh, and how did I forget UFCS? I think some of us were a bit hesitant
about this at first, but coupled with ranges, it has opened up a whole
new way of writing (and thinking about) your program:

	// UFCS FTW! ;-)
	auto formatYear(int year, int monthsPerRow)
	{
		return datesInYear(year)
			.byMonth()
			.chunks(monthsPerRow)
			.map!(row => row.formatMonths()
					.array()
					.pasteBlocks(colSpacing)
					.join("\n"))
			.join("\n\n");
	}

(Shamelessly quoted from my article:

	http://wiki.dlang.org/Component_programming_with_ranges

;-))


T

-- 
Don't modify spaghetti code unless you can eat the consequences.
Jul 11 2014
prev sibling next sibling parent "Remo" <remo4d gmail.com> writes:
On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Fri, Jul 11, 2014 at 03:30:15PM +0000, Chris via 
 Digitalmars-d wrote:

 I have followed the recent discussions about D and I can see 
 the usual
 pattern, to wit GC, Go (or whatever) is so much better, 
 everyone
 blaming each other for not contributing, not being allowed to
 contribute blah.


 Well, this forum *is* for discussing ways of improving D, so it
 shouldn't be surprising that we constantly find things to 
 nitpick about.
 :-) It doesn't mean at all that D is lousy or the community is 
 bad, 'cos
 if it were so, we wouldn't even be here to begin with. We're 
 here 'cos
 we care, and we complain 'cos we care enough to want things to 
 improve.



 First of all, I am in no position to criticize anyone who is
 contributing to the language. I don't contribute, because I 
 don't have
 the time to do so.  Indeed I have huge, massive respect for 
 everyone
 who contributes to D. The only thing I do is to actually use 
 the
 language and tell everyone about it.  I have developed a 
 screen reader
 plug in in D (using C libraries) that was ridiculously easy to
 integrate on Windows as a DLL. I used vibe.d to create a 
 lightning
 fast online version of the screen reader. Believe me, D's 
 supposed
 sluggishness as regards GC is not so important for most 
 applications.
 I dare say 90% of all applications are fine with the current 
 GC. I
 compiled both applications with dmd (testing phase) not with 
 ldc or
 gdc and they are very fast.


 I agree. I'm still convinced that GC phobia is blown out of 
 proportion
 -- I used to be in that camp, so I totally sympathize with 
 where they're
 coming from -- but as you say, only a small percentage of 
 applications
 actually need to squeeze every last cycle out of the CPU such 
 that the
 GC actually starts to make a significant difference in 
 performance. Most
 applications work just fine with the GC, and in fact, I'd argue 
 that
 they work *better* with the GC, because manual memory 
 management is
 *hard* (just look at how many security exploits are caused by 
 memory
 management mistakes) and tedious (look at how often the same 
 memory bugs
 are repeated over and over).  GC-supported code is cleaner to 
 read,
 easier to write, and in many cases, the simpler design of the 
 code
 reduces the likelihood of bugs and eliminates a whole class of 
 bugs.
 Sure you pay for that by short pauses every now and then, but 
 seriously,
 90% of applications don't even *care* about such pauses.

 For applications with slightly higher performance demands, gdc 
 -O3 (or
 whatever the LDC equivalent is) generally improves performance 
 by about
 20% or so above dmd. In my own compute-intensive projects, I 
 have
 consistently noted about a 20-30% performance improvement when 
 compiling
 with gdc, compared to dmd. That's pretty significant, because 
 GC pauses
 are generally nowhere near that percentage, so just by 
 recompiling with
 gdc already eliminates the perceived GC performance issue for 
 95% of
 applications. Besides, avoiding frequent small allocations also 
 reduces
 most of the workload of the GC, so you can still get pretty far 
 without
 totally turning it off.

 So it's really only the remaining 5% of applications that 
 really,
 absolutely, *have* to go GC-less (or control it very tightly). 
 They do
 happen to have supporters of the rather vocal kind, so we tend 
 to hear
 from them a lot more, but that by no means is representative of 
 the
 grand scheme of things as far as the GC is concerned!


 [...]

 Let's first make a list of things that have been achieved with 
 D and
 that are on a par with or even bettar than in other languages 
 (C, C++,




 that front,
 but at least as far as C/C++ are concerned, D totally beats 
 them flat in
 the following points IMO:

 - Metaprogramming. Templates in C++ scarred many for life. 
 Templates in
   D are actually a pleasure to use.

 - CTFE. Coupled with metaprogramming, this is a total killer 
 combination
   that I've yet to see another language beat.

 - Slices. Finally, a systems-level language whose string 
 support isn't
   crippled (C), maimed (C++), or otherwise handicapped (Java). 
 And this
   extends to arrays in general. While there *are* other 
 language with
   nice string/array manipulation support, D is the only one I 
 know of
   that does it without sacrificing performance.

 - Ranges. It can totally revolutionize the way you approach 
 programming.
   And, with metaprogramming/CTFE, they can still perform as 
 fast as
   non-range-based code. Total win!

 - Extended meaning of purity: IMO it's a total stroke of genius 
 to
   define "weak purity" that allows you to implement pure 
 functions (in
   the Haskell sense) using mutating primitives (loops and 
 assignments,
   etc.). While the current compilers don't really do that much 
 with this
   presently, there is a lot of potential here that may turn 
 this into a
   killer feature.

 - Built-in unittests. Sounds trivial, but I can testify to its 
 value in
   dramatically improving the quality of my code. I've worked 
 with large
   C/C++ codebases, and most of them don't even bother with any 
 kind of
   unit testing -- it's up to the programmer to test everything, 
 and we
   just take his word for it -- and simply accept the countless 
 stream of
   bugs that come thereafter as a fact of life. Of the rare few 
 that
   actually do have tests, the tests are usually (1) outdated, 
 (2)
   commented out 'cos nobody cares to update them, (3) ignored 
 by the
   coders anyway 'cos they can't be bothered to switch to another
   language in another framework just to write tests that nobody 
 will run
   while having their hands tied behind their back. D's built-in 
 unittest
   blocks is a total game changer in this area, in spite of its
   simplicity (which some people have complained about).

    - Along these lines, static assert totally rawkz. It 
 ensures, at
      *compile-time*, that assumptions in your code haven't been 
 violated
      by a careless code change, forcing the person who made the 
 change
      to fix it (rather than introducing a possibly subtle error 
 that
      will only be uncovered months down the road on the 
 customer's
      production site).

 - The fastest regex library known on the planet (thanks to, 
 guess what?
   metaprogramming and CTFE!). I'm a regex aficionado, and this 
 is a
   total big deal in my book.

 - Built-in Unicode support. Compiler-level support for Unicode 
 is
   something C/C++ sorely lacks, and that immediately puts them 
 in the
   "legacy" category. LibICU is a nightmare to use. D, however, 
 lets you
   treat Unicode directly in the language. (Full Unicode 
 compliance isn't
   quite there yet, but we're getting pretty close.) Modern 
 languages

 least on
   par with them. C/C++ is definitely behind in this category, 
 though.

 These are just language-level cool stuff. At a higher level, we 
 also
 have:

 - rdmd: run your D programs like scripts, yet with native 
 compiled
   performance. Rawkage!

 - Dustmite: a totally revolutionary tool IMO, that changes 
 finding
   heisenbugs from an impossible game of chance to something that
   actually has hope of being fixed within reasonable amounts of 
 time.

 - vibe.d: I haven't used it myself, but from what I hear, it's 
 extremely
   awesome.

 I'm sure there are many other items that can be added, but this 
 should
 be a good start. :)


 T


Great description! Even if I do not agree to everything 
especially C++ related :)

I think all this advantages should visible for everyone why is 
new to D!
For example here:

http://www.slant.co/topics/25/viewpoints/11/~what-is-the-best-programming-language-to-learn-first~d
Jul 11 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
This is an awesome list, it's almost exactly what I would have written!
Jul 11 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via 
Digitalmars-d wrote:


 - Metaprogramming. Templates in C++ scarred many for life. 
 Templates in
   D are actually a pleasure to use.

 - CTFE. Coupled with metaprogramming, this is a total killer 
 combination
   that I've yet to see another language beat.

 - Slices. Finally, a systems-level language whose string 
 support isn't
   crippled (C), maimed (C++), or otherwise handicapped (Java). 
 And this
   extends to arrays in general. While there *are* other 
 language with
   nice string/array manipulation support, D is the only one I 
 know of
   that does it without sacrificing performance.

 - Ranges. It can totally revolutionize the way you approach 
 programming.
   And, with metaprogramming/CTFE, they can still perform as 
 fast as
   non-range-based code. Total win!

 - Extended meaning of purity: IMO it's a total stroke of genius 
 to
   define "weak purity" that allows you to implement pure 
 functions (in
   the Haskell sense) using mutating primitives (loops and 
 assignments,
   etc.). While the current compilers don't really do that much 
 with this
   presently, there is a lot of potential here that may turn 
 this into a
   killer feature.

 - Built-in unittests. Sounds trivial, but I can testify to its 
 value in
   dramatically improving the quality of my code. I've worked 
 with large
   C/C++ codebases, and most of them don't even bother with any 
 kind of
   unit testing -- it's up to the programmer to test everything, 
 and we
   just take his word for it -- and simply accept the countless 
 stream of
   bugs that come thereafter as a fact of life. Of the rare few 
 that
   actually do have tests, the tests are usually (1) outdated, 
 (2)
   commented out 'cos nobody cares to update them, (3) ignored 
 by the
   coders anyway 'cos they can't be bothered to switch to another
   language in another framework just to write tests that nobody 
 will run
   while having their hands tied behind their back. D's built-in 
 unittest
   blocks is a total game changer in this area, in spite of its
   simplicity (which some people have complained about).

    - Along these lines, static assert totally rawkz. It 
 ensures, at
      *compile-time*, that assumptions in your code haven't been 
 violated
      by a careless code change, forcing the person who made the 
 change
      to fix it (rather than introducing a possibly subtle error 
 that
      will only be uncovered months down the road on the 
 customer's
      production site).

 - The fastest regex library known on the planet (thanks to, 
 guess what?
   metaprogramming and CTFE!). I'm a regex aficionado, and this 
 is a
   total big deal in my book.

 - Built-in Unicode support. Compiler-level support for Unicode 
 is
   something C/C++ sorely lacks, and that immediately puts them 
 in the
   "legacy" category. LibICU is a nightmare to use. D, however, 
 lets you
   treat Unicode directly in the language. (Full Unicode 
 compliance isn't
   quite there yet, but we're getting pretty close.) Modern 
 languages

 least on
   par with them. C/C++ is definitely behind in this category, 
 though.

 These are just language-level cool stuff. At a higher level, we 
 also
 have:

 - rdmd: run your D programs like scripts, yet with native 
 compiled
   performance. Rawkage!

 - Dustmite: a totally revolutionary tool IMO, that changes 
 finding
   heisenbugs from an impossible game of chance to something that
   actually has hope of being fixed within reasonable amounts of 
 time.

 - vibe.d: I haven't used it myself, but from what I hear, it's 
 extremely
   awesome.


Great list,  I'll add a couple more:

  - GDC & LDC - D on ARM and other platforms is possible thanks to 
talent donated to these efforts.

  - D is universal -  I don't know how to articulate this, but I'm 
sick of learning so many languages for different purposes and 
different platforms.  I'm beginning to use D for just about 
everything, and I don't have to worry so much about whether I'm 
on Windows or Linux.  I'm even using D to write low-level drivers 
for my micrcontroller.  I use it for my build scripts, automating 
my builds in the same language I'm building.  D, one language to 
rule them all.


Mike
Jul 11 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Jul 12, 2014 at 01:18:05AM +0000, Mike via Digitalmars-d wrote:
[...]

  - D is universal -  I don't know how to articulate this, but I'm sick
 of learning so many languages for different purposes and different
 platforms.  I'm beginning to use D for just about everything, and I
 don't have to worry so much about whether I'm on Windows or Linux.


One of the things I eventually hope to get to, is to write D apps that
work on both Windows and Linux.  I'm pretty sure my code can already run
on Windows, but I just haven't setup the dev environment yet.



 I'm even using D to write low-level drivers for my micrcontroller.  I
 use it for my build scripts, automating my builds in the same language
 I'm building.  D, one language to rule them all.


[...]

Whoa. That's a pretty cool idea: use D to build D!  I think I'm going to
start doing that too. Right now I'm using SCons (Python-based), which is
pretty great for what I need, but the thought of using D to build D
sounds so appealing to me that I'm gonna hafta do just that. :) Thanks
for the idea!


T

-- 
"Outlook not so good." That magic 8-ball knows everything! I'll ask about
Exchange Server next. -- (Stolen from the net)
Jul 11 2014
prev sibling parent "AsmMan" <lol.themask gmail.com> writes:
On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Fri, Jul 11, 2014 at 03:30:15PM +0000, Chris via 
 Digitalmars-d wrote:

 I have followed the recent discussions about D and I can see 
 the usual
 pattern, to wit GC, Go (or whatever) is so much better, 
 everyone
 blaming each other for not contributing, not being allowed to
 contribute blah.


 Well, this forum *is* for discussing ways of improving D, so it
 shouldn't be surprising that we constantly find things to 
 nitpick about.
 :-) It doesn't mean at all that D is lousy or the community is 
 bad, 'cos
 if it were so, we wouldn't even be here to begin with. We're 
 here 'cos
 we care, and we complain 'cos we care enough to want things to 
 improve.



 First of all, I am in no position to criticize anyone who is
 contributing to the language. I don't contribute, because I 
 don't have
 the time to do so.  Indeed I have huge, massive respect for 
 everyone
 who contributes to D. The only thing I do is to actually use 
 the
 language and tell everyone about it.  I have developed a 
 screen reader
 plug in in D (using C libraries) that was ridiculously easy to
 integrate on Windows as a DLL. I used vibe.d to create a 
 lightning
 fast online version of the screen reader. Believe me, D's 
 supposed
 sluggishness as regards GC is not so important for most 
 applications.
 I dare say 90% of all applications are fine with the current 
 GC. I
 compiled both applications with dmd (testing phase) not with 
 ldc or
 gdc and they are very fast.


 I agree. I'm still convinced that GC phobia is blown out of 
 proportion
 -- I used to be in that camp, so I totally sympathize with 
 where they're
 coming from -- but as you say, only a small percentage of 
 applications
 actually need to squeeze every last cycle out of the CPU such 
 that the
 GC actually starts to make a significant difference in 
 performance. Most
 applications work just fine with the GC, and in fact, I'd argue 
 that
 they work *better* with the GC, because manual memory 
 management is
 *hard* (just look at how many security exploits are caused by 
 memory
 management mistakes) and tedious (look at how often the same 
 memory bugs
 are repeated over and over).  GC-supported code is cleaner to 
 read,
 easier to write, and in many cases, the simpler design of the 
 code
 reduces the likelihood of bugs and eliminates a whole class of 
 bugs.
 Sure you pay for that by short pauses every now and then, but 
 seriously,
 90% of applications don't even *care* about such pauses.

 For applications with slightly higher performance demands, gdc 
 -O3 (or
 whatever the LDC equivalent is) generally improves performance 
 by about
 20% or so above dmd. In my own compute-intensive projects, I 
 have
 consistently noted about a 20-30% performance improvement when 
 compiling
 with gdc, compared to dmd. That's pretty significant, because 
 GC pauses
 are generally nowhere near that percentage, so just by 
 recompiling with
 gdc already eliminates the perceived GC performance issue for 
 95% of
 applications. Besides, avoiding frequent small allocations also 
 reduces
 most of the workload of the GC, so you can still get pretty far 
 without
 totally turning it off.

 So it's really only the remaining 5% of applications that 
 really,
 absolutely, *have* to go GC-less (or control it very tightly). 
 They do
 happen to have supporters of the rather vocal kind, so we tend 
 to hear
 from them a lot more, but that by no means is representative of 
 the
 grand scheme of things as far as the GC is concerned!


 [...]

 Let's first make a list of things that have been achieved with 
 D and
 that are on a par with or even bettar than in other languages 
 (C, C++,




 that front,
 but at least as far as C/C++ are concerned, D totally beats 
 them flat in
 the following points IMO:

 - Metaprogramming. Templates in C++ scarred many for life. 
 Templates in
   D are actually a pleasure to use.

 - CTFE. Coupled with metaprogramming, this is a total killer 
 combination
   that I've yet to see another language beat.

 - Slices. Finally, a systems-level language whose string 
 support isn't
   crippled (C), maimed (C++), or otherwise handicapped (Java). 
 And this
   extends to arrays in general. While there *are* other 
 language with
   nice string/array manipulation support, D is the only one I 
 know of
   that does it without sacrificing performance.

 - Ranges. It can totally revolutionize the way you approach 
 programming.
   And, with metaprogramming/CTFE, they can still perform as 
 fast as
   non-range-based code. Total win!

 - Extended meaning of purity: IMO it's a total stroke of genius 
 to
   define "weak purity" that allows you to implement pure 
 functions (in
   the Haskell sense) using mutating primitives (loops and 
 assignments,
   etc.). While the current compilers don't really do that much 
 with this
   presently, there is a lot of potential here that may turn 
 this into a
   killer feature.

 - Built-in unittests. Sounds trivial, but I can testify to its 
 value in
   dramatically improving the quality of my code. I've worked 
 with large
   C/C++ codebases, and most of them don't even bother with any 
 kind of
   unit testing -- it's up to the programmer to test everything, 
 and we
   just take his word for it -- and simply accept the countless 
 stream of
   bugs that come thereafter as a fact of life. Of the rare few 
 that
   actually do have tests, the tests are usually (1) outdated, 
 (2)
   commented out 'cos nobody cares to update them, (3) ignored 
 by the
   coders anyway 'cos they can't be bothered to switch to another
   language in another framework just to write tests that nobody 
 will run
   while having their hands tied behind their back. D's built-in 
 unittest
   blocks is a total game changer in this area, in spite of its
   simplicity (which some people have complained about).

    - Along these lines, static assert totally rawkz. It 
 ensures, at
      *compile-time*, that assumptions in your code haven't been 
 violated
      by a careless code change, forcing the person who made the 
 change
      to fix it (rather than introducing a possibly subtle error 
 that
      will only be uncovered months down the road on the 
 customer's
      production site).

 - The fastest regex library known on the planet (thanks to, 
 guess what?
   metaprogramming and CTFE!). I'm a regex aficionado, and this 
 is a
   total big deal in my book.

 - Built-in Unicode support. Compiler-level support for Unicode 
 is
   something C/C++ sorely lacks, and that immediately puts them 
 in the
   "legacy" category. LibICU is a nightmare to use. D, however, 
 lets you
   treat Unicode directly in the language. (Full Unicode 
 compliance isn't
   quite there yet, but we're getting pretty close.) Modern 
 languages

 least on
   par with them. C/C++ is definitely behind in this category, 
 though.

 These are just language-level cool stuff. At a higher level, we 
 also
 have:

 - rdmd: run your D programs like scripts, yet with native 
 compiled
   performance. Rawkage!

 - Dustmite: a totally revolutionary tool IMO, that changes 
 finding
   heisenbugs from an impossible game of chance to something that
   actually has hope of being fixed within reasonable amounts of 
 time.

 - vibe.d: I haven't used it myself, but from what I hear, it's 
 extremely
   awesome.

 I'm sure there are many other items that can be added, but this 
 should
 be a good start. :)


 T


I think you could write an article of kind "why use D"
Jul 11 2014
prev sibling next sibling parent reply "Israel Rodriguez" <tl12000 live.com> writes:
On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote:
Let's not

 forget that zeolots and professional posters will always point 
 out the flaws of D, and blow them out of proportion. "D doesn't 
 have xyz, so it's shit!" Divide et impera (divide and rule).



Lol, this one made me laugh.

It is true though. I have only been keeping up with D for like 
the last year or so and have found that its missing many things 
that i would like it to do by itself, without the help of C/C++. 
Multimedia and graphics for example. D ALWAYS has to rely on 
C/C++ libraries for this. OpenGL is an exception 
because...well...every OS out there has OpenGL...

Apart from that GC is a concern to many. I can see why GC would 
not be needed for a systems language but i see D primarily as a 
General Software Programming language where GC is most needed.
Jul 11 2014
next sibling parent "Israel Rodriguez" <tl12000 live.com> writes:
On Friday, 11 July 2014 at 17:54:38 UTC, Israel Rodriguez wrote:

 Lol, this one made me laugh.

 It is true though. I have only been keeping up with D for like 
 the last year or so and have found that its missing many things 
 that i would like it to do by itself, without the help of 
 C/C++. Multimedia and graphics for example. D ALWAYS has to 
 rely on C/C++ libraries for this. OpenGL is an exception 
 because...well...every OS out there has OpenGL...

 Apart from that GC is a concern to many. I can see why GC would 
 not be needed for a systems language but i see D primarily as a 
 General Software Programming language where GC is most needed.




everything and anything i need but thats only because the .NET 
framework provides nearly everything i need without the help of 
C/C++. The only thing i need is win32 APIs.
Jul 11 2014
prev sibling next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 11 July 2014 at 17:54:38 UTC, Israel Rodriguez wrote:

 On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote:
 Let's not

 forget that zeolots and professional posters will always point 
 out the flaws of D, and blow them out of proportion. "D 
 doesn't have xyz, so it's shit!" Divide et impera (divide and 
 rule).



 Lol, this one made me laugh.

 It is true though. I have only been keeping up with D for like 
 the last year or so and have found that its missing many things 
 that i would like it to do by itself, without the help of 
 C/C++. Multimedia and graphics for example.



 D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an 
 exception because...well...every OS out there has OpenGL...


Why reinvent the wheel, when D can interface to the wheel. A lot 
of things are programmed in C/C++. Other languages use modules 
(Python, Java) to access existing C libraries. D can do it 
straight away. I cannot tell you how much it has helped me. I 
depend on C libraries not because I use D, but because the 
libraries are useful and well established / tested / sound.


 Apart from that GC is a concern to many. I can see why GC would 
 not be needed for a systems language but i see D primarily as a 
 General Software Programming language where GC is most needed.
Jul 11 2014
next sibling parent "Chris" <wendlec tcd.ie> writes:
I forgot to mention that the fact that D implements the Thompson 
algorithm for regular expressions made me smile. All other 
languages insist on inefficient algorithms.
Jul 11 2014
prev sibling parent "Israel Rodriguez" <tl12000 live.com> writes:
On Friday, 11 July 2014 at 18:13:52 UTC, Chris wrote:

 On Friday, 11 July 2014 at 17:54:38 UTC, Israel Rodriguez wrote:

 On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote:
 Let's not

 forget that zeolots and professional posters will always 
 point out the flaws of D, and blow them out of proportion. "D 
 doesn't have xyz, so it's shit!" Divide et impera (divide and 
 rule).



 Lol, this one made me laugh.

 It is true though. I have only been keeping up with D for like 
 the last year or so and have found that its missing many 
 things that i would like it to do by itself, without the help 
 of C/C++. Multimedia and graphics for example.



 D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an 
 exception because...well...every OS out there has OpenGL...


 Why reinvent the wheel, when D can interface to the wheel. A 
 lot of things are programmed in C/C++. Other languages use 
 modules (Python, Java) to access existing C libraries. D can do 
 it straight away. I cannot tell you how much it has helped me. 
 I depend on C libraries not because I use D, but because the 
 libraries are useful and well established / tested / sound.


 Apart from that GC is a concern to many. I can see why GC 
 would not be needed for a systems language but i see D 
 primarily as a General Software Programming language where GC 
 is most needed.




This is true, but theoretically i feel this is wrong because its 
like putting training wheels on your bike. Know what i mean?

Anyways thats just how "Feel" but maybe youre right, in that, 
maybe that isnt the right way to go...
Jul 11 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2014 10:54 AM, Israel Rodriguez wrote:

 On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote:
 Let's not

 forget that zeolots and professional posters will always point out the flaws
 of D, and blow them out of proportion. "D doesn't have xyz, so it's shit!"
 Divide et impera (divide and rule).


 Lol, this one made me laugh.



Speaking of inventing reasons to not use D, years ago the reason was "D has
only 
one implementation, so it's too risky to use." Lately, the reason is "D has 3 
implementations, so it's too risky to use, there should be only one".

We have to be careful to filter out real reasons from people just pulling our 
chains.
Jul 11 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Thanks for posting this. You're right that it is easy to lose perspective.

I agree that the GC phobia is way, WAY, overblown for practical programming.
For 
example, Warp uses the GC, but only for things like initialization, where perf 
doesn't matter, and for permanent data structures. It doesn't use it on the
fast 
path, and so Warp keeps the convenience and safety of GC without the perf hit.

This was not hard to do.

I understand that Sociomantic does something similar to good effect.

GC phobia is a convenient excuse for people to not use D, people who may have 
different actual reasons that they don't express for various reasons or may not 
even realize.

For example, in the 80's, a friend of mine talked with a C++ programmer who 
fervently and passionately argued that compiler speed was the most important 
attribute. My friend says no, compile speed is at the bottom of the list of
what 
the programmer care about. Shocked, the programmer asked WTF was he talking 
about? My friend said "You use Microsoft C++, which is the slowest compiler by
a 
factor of 4. What you actually care about is branding, not speed." And the 
programmer eventually admitted he was right.

But we still need an answer to the people who believe that GC is the touch of 
death, that the GC is a troll hiding under a bridge that will pop out at any 
moment and destroy their program.
Jul 11 2014
next sibling parent reply "Mike" <none none.com> writes:
On Friday, 11 July 2014 at 19:46:25 UTC, Walter Bright wrote:

 I agree that the GC phobia is way, WAY, overblown for practical 
 programming.


I agree with this, as well, but it's a generalization.

There are some applications that the current GC is not suitable 
for, but D provides a plethora of features for disabling the GC 
or managing memory in other ways (very cool), so I don't see a 
reason to not use D even for the most demanding problem.  I love 
the GC for some things I do, but can't use it for other things I 
do.  For the vast majority of applications I see people using D 
for, however, I see no reason why there should be any worry about 
the GC.

The problem, however, when managing one's own memory is that one 
cannot use some of the built-in types, like Exceptions, that are 
instantiated deep within the runtime.  A solution to this would 
likely quiet some of the clamoring, IMO.

I would be interested in hearing any suggestions for disabling 
the GC and still making use of Exceptions, dynamic arrays, etc... 
using a user-supplied memory manager.  Maybe something like this 
already exists, and people like me just aren't aware of it.

Being a novice still, I don't know what the solution is.  At the 
moment I exploring region-based memory management (nice example 
at http://en.wikipedia.org/wiki/Region-based_memory_management).  
I also saw some proposals for something like 
gc.pushAllocator(myAllocator)/gc.popAllocator(), which would be 
nice.

Mike
Jul 11 2014
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 12/07/2014 12:10 p.m., Mike wrote:

 On Friday, 11 July 2014 at 19:46:25 UTC, Walter Bright wrote:

 I agree that the GC phobia is way, WAY, overblown for practical
 programming.


 I agree with this, as well, but it's a generalization.

 There are some applications that the current GC is not suitable for, but
 D provides a plethora of features for disabling the GC or managing
 memory in other ways (very cool), so I don't see a reason to not use D
 even for the most demanding problem.  I love the GC for some things I
 do, but can't use it for other things I do.  For the vast majority of
 applications I see people using D for, however, I see no reason why
 there should be any worry about the GC.

 The problem, however, when managing one's own memory is that one cannot
 use some of the built-in types, like Exceptions, that are instantiated
 deep within the runtime.  A solution to this would likely quiet some of
 the clamoring, IMO.

 I would be interested in hearing any suggestions for disabling the GC
 and still making use of Exceptions, dynamic arrays, etc... using a
 user-supplied memory manager.  Maybe something like this already exists,
 and people like me just aren't aware of it.

 Being a novice still, I don't know what the solution is.  At the moment
 I exploring region-based memory management (nice example at
 http://en.wikipedia.org/wiki/Region-based_memory_management). I also saw
 some proposals for something like
 gc.pushAllocator(myAllocator)/gc.popAllocator(), which would be nice.

 Mike


Something I've been thinking about is an overload for with statement.
E.g.

with(new MyAllocator) {
	void*[256] values;
	//...
}

class MyAllocator : IGC {
	private {
		IGC prevGC;
	}
	
	void opWithIn() {
		this.prevGC = GC.getImpl();
		GC.setImpl(this);
	}

	void opWithOut() {
		GC.setImpl(this.prevGC);
	}
}

Of course if we added an overload that allowed for passing root memory 
blocks that can be freed (ref countered guaranteed at compilation), we 
could force them to be freed in opWithOut. Otherwise tell the previous 
GC to use it.

Now I sort of mix GC and allocator up a little bit, but if it is done 
right. We could swap out the GC for an allocator and make it almost the 
same.

But in saying this, this would mean we would need to have a rethink of 
how we do the GC in druntime. At least from the architecture point of view.

This isn't the reason I thought of this, mostly because I was exploring 
how to do something like GWT nice (not really required but could be 
useful for caching output).

Its a small addition, that may pay off for this kind of work 
substantially. Unless of course we already have it? I didn't realize 
that statements worked in with statements till a couple days ago. So if 
not, I would be surprised.
Jul 11 2014
next sibling parent "Mike" <none none.com> writes:
On Saturday, 12 July 2014 at 03:59:58 UTC, Rikki Cattermole wrote:

 Something I've been thinking about is an overload for with 
 statement.
 E.g.

 with(new MyAllocator) {
 	void*[256] values;
 	//...
 }

 class MyAllocator : IGC {
 	private {
 		IGC prevGC;
 	}
 	
 	void opWithIn() {
 		this.prevGC = GC.getImpl();
 		GC.setImpl(this);
 	}

 	void opWithOut() {
 		GC.setImpl(this.prevGC);
 	}
 }

 Of course if we added an overload that allowed for passing root 
 memory blocks that can be freed (ref countered guaranteed at 
 compilation), we could force them to be freed in opWithOut. 
 Otherwise tell the previous GC to use it.

 Now I sort of mix GC and allocator up a little bit, but if it 
 is done right. We could swap out the GC for an allocator and 
 make it almost the same.

 But in saying this, this would mean we would need to have a 
 rethink of how we do the GC in druntime. At least from the 
 architecture point of view.

 This isn't the reason I thought of this, mostly because I was 
 exploring how to do something like GWT nice (not really 
 required but could be useful for caching output).

 Its a small addition, that may pay off for this kind of work 
 substantially. Unless of course we already have it? I didn't 
 realize that statements worked in with statements till a couple 
 days ago. So if not, I would be surprised.


I think that puts convenient syntax around the basic idea.

Region-based memory management is just what I'm currently 
studying.  There are probably other ways to accomplish the goal:  
allow the user control the allocation, lifetime, and deallocation 
of the built-in types.

Mike
Jul 11 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-07-12 05:59, Rikki Cattermole wrote:


 Something I've been thinking about is an overload for with statement.
 E.g.

 with(new MyAllocator) {
      void*[256] values;
      //...
 }

 class MyAllocator : IGC {
      private {
          IGC prevGC;
      }

      void opWithIn() {
          this.prevGC = GC.getImpl();
          GC.setImpl(this);
      }

      void opWithOut() {
          GC.setImpl(this.prevGC);
      }
 }


Or without language changes:

void withAllocator (alias allocator, alias block)
{
     auto prevGC = GC.getImpl();
     scope(exit)
         GC.setImpl(this.prevGC);

     GC.setImpl(allocator);
     block();
}

withAllocator!(new Allocator, {
     void*[256] values;
});

Not as nice syntax though. That could of course be fixed with AST macros 
[1] :)

[1] http://wiki.dlang.org/DIP50#Statement_Macros

-- 
/Jacob Carlborg
Jul 13 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 13/07/2014 11:50 p.m., Jacob Carlborg wrote:

 On 2014-07-12 05:59, Rikki Cattermole wrote:


 Something I've been thinking about is an overload for with statement.
 E.g.

 with(new MyAllocator) {
      void*[256] values;
      //...
 }

 class MyAllocator : IGC {
      private {
          IGC prevGC;
      }

      void opWithIn() {
          this.prevGC = GC.getImpl();
          GC.setImpl(this);
      }

      void opWithOut() {
          GC.setImpl(this.prevGC);
      }
 }


 Or without language changes:

 void withAllocator (alias allocator, alias block)
 {
      auto prevGC = GC.getImpl();
      scope(exit)
          GC.setImpl(this.prevGC);

      GC.setImpl(allocator);
      block();
 }

 withAllocator!(new Allocator, {
      void*[256] values;
 });

 Not as nice syntax though. That could of course be fixed with AST macros
 [1] :)

 [1] http://wiki.dlang.org/DIP50#Statement_Macros


Definitely, but there is a rather big difference in requirements to 
implement them ;)
But in saying this, we might be able to move the with statement into 
druntime via AST macros. Should it have the ability to modify the this 
context like with statement does now.
Jul 13 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-07-13 14:01, Rikki Cattermole wrote:


 Definitely, but there is a rather big difference in requirements to
 implement them ;)
 But in saying this, we might be able to move the with statement into
 druntime via AST macros. Should it have the ability to modify the this
 context like with statement does now.


Yeah, there are many features that could have been implemented as macros 
instead of in the language, if D had had them from the beginning.

-- 
/Jacob Carlborg
Jul 13 2014
parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Sunday, 13 July 2014 at 12:21:13 UTC, Jacob Carlborg wrote:

 Yeah, there are many features that could have been implemented 
 as macros instead of in the language, if D had had them from 
 the beginning.


What's the status of that DIP? What's the process by which 
something like that would even get added to D?

I very much like the idea. Static metaprogramming and powerful 
compile time capabilities are the killer features of D, so 
strengthening them further seems worthwhile.
Jul 13 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 July 2014 at 16:32:15 UTC, Brian Rogoff wrote:

 On Sunday, 13 July 2014 at 12:21:13 UTC, Jacob Carlborg wrote:

 Yeah, there are many features that could have been implemented 
 as macros instead of in the language, if D had had them from 
 the beginning.


 What's the status of that DIP?


It exists, pretty much all. No proof of concept implementation 
and no official approval so far. Community discussion was not 
really active either - most likely because it does not seem very 
realistic to expect it implemented.


 What's the process by which something like that would even get 
 added to D?


Usually it comes to providing DMD pull request that implements 
the DIP and than convincing Walter/Andrei it is worth merging. 
Most likely change will still be rejected but without PR chances 
are close zero.
Jul 13 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/13/14, 9:42 AM, Dicebot wrote:

 On Sunday, 13 July 2014 at 16:32:15 UTC, Brian Rogoff wrote:

 On Sunday, 13 July 2014 at 12:21:13 UTC, Jacob Carlborg wrote:

 Yeah, there are many features that could have been implemented as
 macros instead of in the language, if D had had them from the beginning.


 What's the status of that DIP?


 It exists, pretty much all. No proof of concept implementation and no
 official approval so far. Community discussion was not really active
 either - most likely because it does not seem very realistic to expect
 it implemented.


 What's the process by which something like that would even get added
 to D?


 Usually it comes to providing DMD pull request that implements the DIP
 and than convincing Walter/Andrei it is worth merging. Most likely
 change will still be rejected but without PR chances are close zero.


I'm not sure about that.

The main problem with most of the current DIPs is quality. There seems 
to be an implied expectation that once a DIP follows the format 
guidelines and has reasonable content, it's implied that it should 
receive some sort of official review.

We don't have the resources to do that. What can be expected is that a 
DIP should be worked at for a while by its champion(s) along with the 
community until it's to a high standard and generally strong (preferably 
with a proof-of-concept implementation in tow).


Andrei
Jul 15 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2014 5:10 PM, Mike wrote:

 The problem, however, when managing one's own memory is that one cannot use
some
 of the built-in types, like Exceptions, that are instantiated deep within the
 runtime.  A solution to this would likely quiet some of the clamoring, IMO.


The thing is, Exceptions should be exceptional, not normal. So if you're
worried 
about GC pauses during exception processing, I think it's time to re-examine 
what exceptions in your code are being used for.
Jul 11 2014
next sibling parent reply Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 7/11/14, 9:10 PM, Walter Bright via Digitalmars-d wrote:

 On 7/11/2014 5:10 PM, Mike wrote:

 The problem, however, when managing one's own memory is that one cannot use
some
 of the built-in types, like Exceptions, that are instantiated deep within the
 runtime.  A solution to this would likely quiet some of the clamoring, IMO.


 The thing is, Exceptions should be exceptional, not normal. So if you're
worried about GC pauses
 during exception processing, I think it's time to re-examine what exceptions
in your code are being
 used for.


It's not the try/throw/catch/finally parts, it's the new that's usually
involved.  The chance that 
the gc will kick in and affect every thread, not just the thread dealing with
the exception is a big 
hit that is unacceptable in some scenarios.
Jul 11 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2014 9:24 PM, Brad Roberts via Digitalmars-d wrote:

 On 7/11/14, 9:10 PM, Walter Bright via Digitalmars-d wrote:

 The thing is, Exceptions should be exceptional, not normal. So if you're
 worried about GC pauses
 during exception processing, I think it's time to re-examine what exceptions
 in your code are being
 used for.


 It's not the try/throw/catch/finally parts, it's the new that's usually
 involved.  The chance that the gc will kick in and affect every thread, not
just
 the thread dealing with the exception is a big hit that is unacceptable in some
 scenarios.


That's a good point.
Jul 11 2014
prev sibling parent reply "Mike" <none none.com> writes:
On Saturday, 12 July 2014 at 04:10:32 UTC, Walter Bright wrote:

 On 7/11/2014 5:10 PM, Mike wrote:

 The problem, however, when managing one's own memory is that 
 one cannot use some
 of the built-in types, like Exceptions, that are instantiated 
 deep within the
 runtime.  A solution to this would likely quiet some of the 
 clamoring, IMO.


 The thing is, Exceptions should be exceptional, not normal. So 
 if you're worried about GC pauses during exception processing, 
 I think it's time to re-examine what exceptions in your code 
 are being used for.


I understand that, but that wasn't my point.  I was just using 
Exceptions as an example of a built-in type (instantiated in the 
runtime outside of the users control).  Dynamic arrays are 
another.

The goal is for the user to be able to be able to control the 
allocation for all types in D, not just the ones the user 
creates.  And to be able to continue to use, to the extent 
possible, roughly the same idioms and patterns they would use if 
employing the GC.

It looks like you were headed down that path with DIP46 
(http://wiki.dlang.org/DIP46).  It's almost a year old.  Do you 
still feel its worth pursuing?

Mike
Jul 11 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2014 9:35 PM, Mike wrote:

 It looks like you were headed down that path with DIP46
 (http://wiki.dlang.org/DIP46).  It's almost a year old.  Do you still feel its
 worth pursuing?


I haven't thought much about that since. There always seems to be something
else 
needing attention.
Jul 11 2014
prev sibling parent reply "Vic" <vic.cvc gmx.com> writes:
On Friday, 11 July 2014 at 19:46:25 UTC, Walter Bright wrote:
<snip>

 GC phobia is a convenient excuse for people to not use D, 
 people who may have different actual reasons that they don't 
 express for various reasons or may not even realize.


Hi Walter,

Please give us a bit more respect and benefit of the doubt and 
assume that we do know what we want when say something.

I want to use D! I may be forced to C++ my team because GC built 
into the base lib. It is possible to build a base lib w/o GC I 
just am in  a small company and can't afford to do that.

Cheers,
Vic
Jul 17 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vic"  wrote in message news:xblbppsybigjgrtgifll forum.dlang.org...


 Hi Walter,

 Please give us a bit more respect and benefit of the doubt and assume that 
 we do know what we want when say something.

 I want to use D! I may be forced to C++ my team because GC built into the 
 base lib. It is possible to build a base lib w/o GC I just am in  a small 
 company and can't afford to do that.

 Cheers,
 Vic


Walter is just one guy, what makes you think he can afford to re-write the 
standard library for you?
Jul 17 2014