Using D

[Chris via Digitalmars-d]

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.

[simendsjo via Digitalmars-d]

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

Post by Chris via Digitalmars-d
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.

[simendsjo via Digitalmars-d]

(...)

Post by Chris via Digitalmars-d
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.

[Russel Winder via Digitalmars-d]

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

Post by simendsjo via Digitalmars-d
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.

Post by simendsjo via Digitalmars-d
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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140711/5bbbdee2/attachment.sig>

[simendsjo via Digitalmars-d]

Post by Russel Winder via Digitalmars-d
[
]

Post by simendsjo via Digitalmars-d
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).

Post by Russel Winder via Digitalmars-d

Post by simendsjo via Digitalmars-d
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.

[Ali Çehreli via Digitalmars-d]

Post by simendsjo via Digitalmars-d

Post by Russel Winder via Digitalmars-d
[
]

Post by simendsjo via Digitalmars-d
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).

Post by Russel Winder via Digitalmars-d

Post by simendsjo via Digitalmars-d
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

[bearophile via Digitalmars-d]

Post by Ali Çehreli via Digitalmars-d
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

[Russel Winder via Digitalmars-d]

On Fri, 2014-07-11 at 18:53 +0200, simendsjo via Digitalmars-d wrote:
[
]

Post by simendsjo via Digitalmars-d
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 – also the way local variables are stored and manipulated has
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.

[
]

Post by simendsjo via Digitalmars-d
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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140712/1ba6b901/attachment.sig>

[Joakim via Digitalmars-d]

Post by simendsjo via Digitalmars-d
(...)

Post by Chris via Digitalmars-d
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.

[Chris via Digitalmars-d]

Post by Joakim via Digitalmars-d

Post by simendsjo via Digitalmars-d
(...)

Post by Chris via Digitalmars-d
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.

Post by Joakim via Digitalmars-d
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?

[Joakim via Digitalmars-d]

Post by Chris via Digitalmars-d

Post by Joakim via Digitalmars-d
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.

[Russel Winder via Digitalmars-d]

On Fri, 2014-07-11 at 20:25 +0000, Joakim via Digitalmars-d wrote:
[
]

Post by Joakim via Digitalmars-d
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.

[
]

Go and D are really quite close to something useful though on this
front.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140712/19b72ca6/attachment.sig>

[Russel Winder via Digitalmars-d]

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

Post by Chris via Digitalmars-d
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 :-)

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.

[
]
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140711/41b46372/attachment.sig>

[Chris via Digitalmars-d]

On Friday, 11 July 2014 at 16:22:27 UTC, Russel Winder via

Post by Russel Winder via Digitalmars-d
On Fri, 2014-07-11 at 15:30 +0000, Chris via Digitalmars-d
[
]

Post by Chris via Digitalmars-d
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 :-)

Post by Russel Winder via Digitalmars-d
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.

[Chris via Digitalmars-d]

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

Post by Russel Winder via Digitalmars-d
On Fri, 2014-07-11 at 15:30 +0000, Chris via Digitalmars-d
[
]

Post by Chris via Digitalmars-d
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 :-)

Post by Russel Winder via Digitalmars-d
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.

[H. S. Teoh via Digitalmars-d]

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

[Russel Winder via Digitalmars-d]

On Fri, 2014-07-11 at 10:40 -0700, H. S. Teoh via Digitalmars-d wrote:
[
]

Post by H. S. Teoh via Digitalmars-d
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.

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.

Post by H. S. Teoh via Digitalmars-d
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.

Post by H. S. Teoh via Digitalmars-d
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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140712/ccfa58b4/attachment.sig>

[Marco Leise via Digitalmars-d]

Am Sat, 12 Jul 2014 11:38:08 +0100
schrieb Russel Winder via Digitalmars-d

Post by Russel Winder via Digitalmars-d

Post by H. S. Teoh via Digitalmars-d
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.

[Chris via Digitalmars-d]

Post by Marco Leise via Digitalmars-d
Am Sat, 12 Jul 2014 11:38:08 +0100
schrieb Russel Winder via Digitalmars-d

Post by Russel Winder via Digitalmars-d

Post by H. S. Teoh via Digitalmars-d
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.

[Russel Winder via Digitalmars-d]

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

Post by Chris via Digitalmars-d
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.

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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140825/55225668/attachment.sig>

[Timon Gehr via Digitalmars-d]

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); }
~~~^~~~~~~~~

[Paulo Pinto via Digitalmars-d]

Post by Russel Winder via Digitalmars-d
[
]

Post by Chris via Digitalmars-d
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
a + b
is not a message in Java as it is in C++, Python, etc.

Since when does C++ does support message passing?

Post by Russel Winder via Digitalmars-d
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

[via Digitalmars-d]

Post by Paulo Pinto via Digitalmars-d
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.

[ketmar via Digitalmars-d]

On Mon, 25 Aug 2014 16:51:23 +0300

Post by Paulo Pinto via Digitalmars-d
Since when does C++ does support message passing?

since people started to think that "OOP was invented in C++".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140825/d743f5c6/attachment.sig>

[via Digitalmars-d]

On Monday, 25 August 2014 at 14:05:35 UTC, ketmar via

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

Post by Paulo Pinto via Digitalmars-d
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.

[ketmar via Digitalmars-d]

On Mon, 25 Aug 2014 14:15:09 +0000

Post by via Digitalmars-d
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. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140825/6e41b577/attachment.sig>

[via Digitalmars-d]

On Monday, 25 August 2014 at 14:27:55 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Mon, 25 Aug 2014 14:15:09 +0000

Post by via Digitalmars-d
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.

[ketmar via Digitalmars-d]

On Mon, 25 Aug 2014 14:41:46 +0000

Post by via Digitalmars-d
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. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140825/80e98930/attachment.sig>

[via Digitalmars-d]

On Monday, 25 August 2014 at 14:54:33 UTC, ketmar via

Post by ketmar via Digitalmars-d
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

[ketmar via Digitalmars-d]

On Mon, 25 Aug 2014 16:08:52 +0000

Post by via Digitalmars-d
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140825/9e22009d/attachment.sig>

[via Digitalmars-d]

On Monday, 25 August 2014 at 16:26:19 UTC, ketmar via

Post by ketmar via Digitalmars-d
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?

[ketmar via Digitalmars-d]

On Mon, 25 Aug 2014 16:33:00 +0000

Post by via Digitalmars-d
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"! ;-)

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

Post by via Digitalmars-d
Why recompile the whole file when only a tiny function should be
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/c0226d78/attachment-0001.sig>

[Joakim via Digitalmars-d]

On Tuesday, 26 August 2014 at 04:03:17 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Mon, 25 Aug 2014 16:33:00 +0000

Post by via Digitalmars-d
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.

Post by ketmar via Digitalmars-d
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.

[ketmar via Digitalmars-d]

On Tue, 26 Aug 2014 05:59:45 +0000

Other than a few devs with privacy and security concerns

it's about me. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/35e29c62/attachment.sig>

[Ary Borenszweig via Digitalmars-d]

Post by ketmar via Digitalmars-d
On Mon, 25 Aug 2014 16:08:52 +0000

Post by via Digitalmars-d
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.

[ketmar via Digitalmars-d]

On Mon, 25 Aug 2014 14:36:21 -0300

Post by Ary Borenszweig via Digitalmars-d
The trick is to not use virtual tables, but do multiple dispatch (or
a = 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.

Post by Ary Borenszweig via Digitalmars-d
To me, the real problem with OOP is to automatically relate it to
virtual tables, interfaces, etc.

i myself thinking about message passing when i see OOP mentioned. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/cc3407fa/attachment.sig>

[Paulo Pinto via Digitalmars-d]

On Monday, 25 August 2014 at 14:41:48 UTC, Ola Fosheim GrÞstad

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

Post by ketmar via Digitalmars-d
On Mon, 25 Aug 2014 14:15:09 +0000

Post by via Digitalmars-d
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

[Paulo Pinto via Digitalmars-d]

On Monday, 25 August 2014 at 14:54:33 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Mon, 25 Aug 2014 14:41:46 +0000

Post by via Digitalmars-d
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

[ketmar via Digitalmars-d]

On Mon, 25 Aug 2014 17:50:35 +0000

Post by Paulo Pinto via Digitalmars-d
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/4c33fe12/attachment.sig>

[Walter Bright via Digitalmars-d]

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.

[Chris via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by Chris via Digitalmars-d
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.

[Russel Winder via Digitalmars-d]

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

Post by Chris via Digitalmars-d
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. 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.

Post by Chris via Digitalmars-d
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. 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–10MB executables!

With shared libraries becoming an issue in D again, that set of
dependency and platform problems will raise their heads.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/122fe13e/attachment.sig>

[Chris via Digitalmars-d]

On Tuesday, 26 August 2014 at 09:45:15 UTC, Russel Winder via

Post by Russel Winder via Digitalmars-d
On Tue, 2014-08-26 at 08:46 +0000, Chris via Digitalmars-d
[
]

Post by Chris via Digitalmars-d
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.

Post by Russel Winder via Digitalmars-d
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.

Post by Russel Winder via Digitalmars-d
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.

Post by Russel Winder via Digitalmars-d
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.

Post by Russel Winder via Digitalmars-d

Post by Chris via Digitalmars-d
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?

Post by Russel Winder via Digitalmars-d
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.

Post by Russel Winder via Digitalmars-d
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.

Post by Russel Winder via Digitalmars-d
With shared libraries becoming an issue in D again, that set of
dependency and platform problems will raise their heads.

[Russel Winder via Digitalmars-d]

On Mon, 2014-08-25 at 09:55 +0200, Marco Leise via Digitalmars-d wrote:
[
]

Post by Marco Leise via Digitalmars-d
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,

Post by Marco Leise via Digitalmars-d
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.

Post by Marco Leise via Digitalmars-d
...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.

Post by Marco Leise via Digitalmars-d
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.

Post by Marco Leise via Digitalmars-d
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 :-)

Post by Marco Leise via Digitalmars-d
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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140825/fd97989f/attachment.sig>

[Paulo Pinto via Digitalmars-d]

Post by Marco Leise via Digitalmars-d
Am Sat, 12 Jul 2014 11:38:08 +0100
schrieb Russel Winder via Digitalmars-d

Post by Russel Winder via Digitalmars-d

Post by H. S. Teoh via Digitalmars-d
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

[Chris via Digitalmars-d]

On Friday, 11 July 2014 at 17:41:41 UTC, H. S. Teoh via

Post by H. S. Teoh via Digitalmars-d
[...]

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)

[Nick Sabalausky via Digitalmars-d]

Post by H. S. Teoh via Digitalmars-d
[...]

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 ;)

Post by H. S. Teoh via Digitalmars-d
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.

Post by H. S. Teoh via Digitalmars-d
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...

Post by H. S. Teoh via Digitalmars-d
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.

[H. S. Teoh via Digitalmars-d]

[...]

Post by Nick Sabalausky via Digitalmars-d

Post by H. S. Teoh via Digitalmars-d
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

[Paolo Invernizzi via Digitalmars-d]

Post by Nick Sabalausky via Digitalmars-d
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

[Russel Winder via Digitalmars-d]

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

Post by Chris via Digitalmars-d
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.

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

Post by Chris via Digitalmars-d
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.

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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140712/41272db7/attachment.sig>

[Iain Buclaw via Digitalmars-d]

On 12 July 2014 11:27, Russel Winder via Digitalmars-d

Post by Russel Winder via Digitalmars-d
[
]

Post by Chris via Digitalmars-d
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... :)

Post by Russel Winder via Digitalmars-d
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.

[Russel Winder via Digitalmars-d]

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

Post by Iain Buclaw via Digitalmars-d
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.

Post by Iain Buclaw via Digitalmars-d

Post by Russel Winder via Digitalmars-d
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!

Post by Iain Buclaw via Digitalmars-d
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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140712/4da73d3e/attachment.sig>

[Iain Buclaw via Digitalmars-d]

On 12 July 2014 15:11, Russel Winder via Digitalmars-d

Post by Russel Winder via Digitalmars-d
[
]

Post by Iain Buclaw via Digitalmars-d
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.

Post by Iain Buclaw via Digitalmars-d

Post by Russel Winder via Digitalmars-d
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...

Post by Russel Winder via Digitalmars-d

Post by Iain Buclaw via Digitalmars-d
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.

[Russel Winder via Digitalmars-d]

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

Post by Iain Buclaw via Digitalmars-d
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.

[
]

Post by Iain Buclaw via Digitalmars-d
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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140712/19a548a0/attachment.sig>

[Iain Buclaw via Digitalmars-d]

On 12 July 2014 15:53, Russel Winder via Digitalmars-d

Post by Russel Winder via Digitalmars-d
[
]

Post by Iain Buclaw via Digitalmars-d
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.
[
]

Post by Iain Buclaw via Digitalmars-d
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.

[Iain Buclaw via Digitalmars-d]

Post by Iain Buclaw via Digitalmars-d
On 12 July 2014 15:53, Russel Winder via Digitalmars-d

Post by Russel Winder via Digitalmars-d
[
]

Post by Iain Buclaw via Digitalmars-d
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.
[
]

Post by Iain Buclaw via Digitalmars-d
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140821/b6cc8600/attachment.html>

[Colin via Digitalmars-d]

On Thursday, 21 August 2014 at 10:06:25 UTC, Iain Buclaw via

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

Post by Iain Buclaw via Digitalmars-d
On 12 July 2014 15:53, Russel Winder via Digitalmars-d

Post by Russel Winder via Digitalmars-d
On Sat, 2014-07-12 at 15:37 +0100, Iain Buclaw via
[
]

Post by Iain Buclaw via Digitalmars-d
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.
[
]

Post by Iain Buclaw via Digitalmars-d
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!)

[Russel Winder via Digitalmars-d]

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

Post by Colin via Digitalmars-d
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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140825/e7017714/attachment.sig>

[Walter Bright via Digitalmars-d]

Post by Iain Buclaw via Digitalmars-d
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.

[Iain Buclaw via Digitalmars-d]

On 13 July 2014 08:21, Walter Bright via Digitalmars-d

Post by Walter Bright via Digitalmars-d

Post by Iain Buclaw via Digitalmars-d
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.

[Walter Bright via Digitalmars-d]

Post by Russel Winder via Digitalmars-d
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!

[Paulo Pinto via Digitalmars-d]

Post by Iain Buclaw via Digitalmars-d
On 12 July 2014 11:27, Russel Winder via Digitalmars-d

Post by Russel Winder via Digitalmars-d
[
]

Post by Chris via Digitalmars-d
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

[Joakim via Digitalmars-d]

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

Post by Russel Winder via Digitalmars-d
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.

[Iain Buclaw via Digitalmars-d]

.On 12 July 2014 20:55, Joakim via Digitalmars-d

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

Post by Russel Winder via Digitalmars-d
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.

[Chris via Digitalmars-d]

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

Post by Russel Winder via Digitalmars-d
On Fri, 2014-07-11 at 16:54 +0000, Chris via Digitalmars-d
[
]

Post by Chris via Digitalmars-d
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).

Post by Russel Winder via Digitalmars-d
I think I have to repeat the point about irony here regarding
ideology :-)

Post by Chris via Digitalmars-d
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.

[Vic via Digitalmars-d]

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

<snip>

Post by Joakim via Digitalmars-d
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

[Paulo Pinto via Digitalmars-d]

Post by Vic via Digitalmars-d

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

<snip>

Post by Joakim via Digitalmars-d
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

[via Digitalmars-d]

Post by Paulo Pinto via Digitalmars-d
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.

[Paulo Pinto via Digitalmars-d]

Am 16.07.2014 21:26, schrieb "Ola Fosheim GrÞstad"

Post by Paulo Pinto via Digitalmars-d
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

[H. S. Teoh via Digitalmars-d]

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

[Chris via Digitalmars-d]

On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via

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

Post by Chris via Digitalmars-d
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.

Post by Chris via Digitalmars-d
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!
[...]

Post by Chris via Digitalmars-d
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
- 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
- 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.

[H. S. Teoh via Digitalmars-d]

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

Post by Chris via Digitalmars-d
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

[Israel Rodriguez via Digitalmars-d]

On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote:
Let's not

Post by Chris via Digitalmars-d
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.

[Israel Rodriguez via Digitalmars-d]

Post by Israel Rodriguez via Digitalmars-d
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.

[Chris via Digitalmars-d]

Post by Chris via Digitalmars-d
Let's not

Post by Chris via Digitalmars-d
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.

Post by Chris via Digitalmars-d
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.

[Chris via Digitalmars-d]

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.

[Israel Rodriguez via Digitalmars-d]

Post by Chris via Digitalmars-d

Post by Chris via Digitalmars-d
Let's not

Post by Chris via Digitalmars-d
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.

Post by Chris via Digitalmars-d
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...

[Walter Bright via Digitalmars-d]

Post by Chris via Digitalmars-d
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.

[Remo via Digitalmars-d]

On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via

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

Post by Chris via Digitalmars-d
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.

Post by Chris via Digitalmars-d
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!
[...]

Post by Chris via Digitalmars-d
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
- 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
- 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

[Walter Bright via Digitalmars-d]

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.

[Mike via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
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

[Rikki Cattermole via Digitalmars-d]

Post by Mike via Digitalmars-d

Post by Walter Bright via Digitalmars-d
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.

[Mike via Digitalmars-d]

Post by Rikki Cattermole via Digitalmars-d
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

[Jacob Carlborg via Digitalmars-d]

Post by Rikki Cattermole via Digitalmars-d
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

[Rikki Cattermole via Digitalmars-d]

Post by Jacob Carlborg via Digitalmars-d

Post by Rikki Cattermole via Digitalmars-d
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);
}
}

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.

[Jacob Carlborg via Digitalmars-d]

Post by Rikki Cattermole via Digitalmars-d
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.

[Brian Rogoff via Digitalmars-d]

Post by Jacob Carlborg via Digitalmars-d
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.

[Dicebot via Digitalmars-d]

Post by Brian Rogoff via Digitalmars-d

Post by Jacob Carlborg via Digitalmars-d
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.

Post by Brian Rogoff via Digitalmars-d
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.

[Andrei Alexandrescu via Digitalmars-d]

Post by Brian Rogoff via Digitalmars-d

Post by Jacob Carlborg via Digitalmars-d
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.

Post by Brian Rogoff via Digitalmars-d
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

[Walter Bright via Digitalmars-d]

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.

[Brad Roberts via Digitalmars-d]

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.

[Mike via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by Mike via Digitalmars-d
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

[Walter Bright via Digitalmars-d]

Post by Mike via Digitalmars-d
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.

[Walter Bright via Digitalmars-d]

Post by Brad Roberts via Digitalmars-d

Post by Walter Bright via Digitalmars-d
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.

[Vic via Digitalmars-d]

On Friday, 11 July 2014 at 19:46:25 UTC, Walter Bright wrote:
<snip>

Post by Walter Bright via Digitalmars-d
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

[Daniel Murphy via Digitalmars-d]

Post by Vic via Digitalmars-d
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?

[Walter Bright via Digitalmars-d]

This is an awesome list, it's almost exactly what I would have written!

[Mike via Digitalmars-d]

On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via

Post by H. S. Teoh via Digitalmars-d
- 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
- 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

[H. S. Teoh via Digitalmars-d]

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

[AsmMan via Digitalmars-d]

On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via

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

Post by Chris via Digitalmars-d
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.

Post by Chris via Digitalmars-d
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!
[...]

Post by Chris via Digitalmars-d
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
- 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
- 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"