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 
(C, C++, C#, Go, Rust ...). Then, let's bundle the efforts that 
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 bottlenecks as I get when using C#. Of course, it depends a 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. A little anecdote.. I once got a 20% speed increase in Python by "moving" a variable instantiation outside a tight loop. i = 0 # loop here i = something rather than # loop here 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
   # loop here
     i =3D something
=20
 rather than
   # loop here
     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
   # loop here
     i = something

 rather than
   # loop here
     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
    # loop here
      i = something

 rather than
    # loop here
      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 bottlenecks as I get when using C#. Of course, it depends a 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.
Ah, but that's because you're comparing it to C#, not languages 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 Java/C# these days, because 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. 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 bottlenecks as I get when using C#. Of course, it depends a 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.
Ah, but that's because you're comparing it to C#, not languages 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 Java/C# these days, because 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. Microsoft created Singularity with Sing#. Although the project was 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 a good thing. I am not one of them. Java should have done what C# did 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 IDE generate most of the code. Delphi's and C# IDEs similarly 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 IDE generate most of the code. Delphi's and C# IDEs similarly 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 existing mainstream technologies like Java, C++, C# don't meet 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
 existing mainstream technologies like Java, C++, C# don't meet=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 
 technologies like Java, C++, C# don't meet 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.
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
 IDE generate most of the code. Delphi's and C# IDEs similarly
 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 IDE generate most of the code. Delphi's and C# IDEs similarly 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++,
 C#, Go, Rust ...).
I don't know C#, Go, or Rust, so I can't really say much on 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 like Java/C# also have built-in Unicode support, so D is at 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 -- 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++,
 C#, Go, Rust ...).
I don't know C#, Go, or Rust, so I can't really say much on 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 like Java/C# also have built-in Unicode support, so D is at 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++,
 C#, Go, Rust ...).
I don't know C#, Go, or Rust, so I can't really say much on 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 like Java/C# also have built-in Unicode support, so D is at 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
   like Java/C# also have built-in Unicode support, so D is at 
 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++,
 C#, Go, Rust ...).
I don't know C#, Go, or Rust, so I can't really say much on 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 like Java/C# also have built-in Unicode support, so D is at 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.
Right not i use C# are my primary language where i can do 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