Re: Using D
On 07/11/2014 05:30 PM, Chris wrote: (...) > Believe me, D's supposed sluggishness as regards GC is > not so important for most applications. I dare say 90% of all > applications are fine with the current GC. (...) I agree with this. The bottlenecks i my applications are MySQL and Microsoft Office (Excel, Powerpoint, or even just plain COM). The same bottlenecks as I get when using C#. Of course, it depends a lot on what you do, but for my use (and yours, and probably many others), the GC performance is something you can probably safely ignore. A little anecdote.. I once got a 20% speed increase in Python by "moving" a variable instantiation outside a tight loop. i = 0 # loop here i = something rather than # loop here i = something The compiler wasn't smart enough to do this.
Re: Using D
On 07/11/2014 05:43 PM, simendsjo wrote: > On 07/11/2014 05:30 PM, Chris wrote: > (...) >> Believe me, D's supposed sluggishness as regards GC is >> not so important for most applications. I dare say 90% of all >> applications are fine with the current GC. > (...) > (...) Oh, and a little GC.disable()/GC.enable() goes a long way. Only had to do this a couple of times though.
Re: Using D
On Fri, 2014-07-11 at 15:30 +, Chris via Digitalmars-d wrote: […] > Let's not forget that Go has millions and billions of dollars > behind it and that it is inevitable that the whole internet will > be full of zealots and professional posters who promote Go as > "th 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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Using D
On Fri, 2014-07-11 at 17:43 +0200, simendsjo via Digitalmars-d wrote: […] > A little anecdote.. I once got a 20% speed increase in Python by > "moving" a variable instantiation outside a tight loop. > i = 0 > # loop here > i = something > > rather than > # loop here > i = something This is interesting. I can believe there is some performance benefit, but I am not sure I believe 20% improvement. If you can send me the code you were using, I would like to do some benchmarking on this. > 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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Using D
On 07/11/2014 06:28 PM, Russel Winder via Digitalmars-d wrote: > On Fri, 2014-07-11 at 17:43 +0200, simendsjo via Digitalmars-d wrote: > […] >> A little anecdote.. I once got a 20% speed increase in Python by >> "moving" a variable instantiation outside a tight loop. >> i = 0 >> # loop here >> i = something >> >> rather than >> # loop here >> i = something > > This is interesting. I can believe there is some performance benefit, > but I am not sure I believe 20% improvement. If you can send me the code > you were using, I would like to do some benchmarking on this. Yes, I was very perplexed when I was profiling and finally found the main offender. Unfortunately I don't have the code - it was a project done for a past employer back in 2006/2007 (Python 2.4 IIRC). >> The compiler wasn't smart enough to do this. > > The Python compiler cannot and will never be able to do any such thing. > Indeed if it did any such thing, it would be an error since it > significantly changes the semantics of the program. Thus not doing this > is not the fault of the compiler. The fact that you were able to do > this and it appeared to give you the same results just means that the > change in program semantics did not affect your computation. Which is > good, but not something the compiler could determine. I think of this as a fault in the compiler. It was quite obvious (to me) that nothing else relied on the value so the value didn't have to be created on each iteration.
Re: Using D
On Friday, 11 July 2014 at 16:22:27 UTC, Russel Winder via Digitalmars-d wrote: On Fri, 2014-07-11 at 15:30 +, Chris via Digitalmars-d wrote: […] Let's not forget that Go has millions and billions of dollars behind it and that it is inevitable that the whole internet will be full of zealots and professional posters who promote Go as "th best thing ever". People. Sheep. Meehhh. (I think I detect unintended irony in this post :-) I get the point :-) Go, via goroutines, promotes CSP as an approach to application parallelism and is therefore a Good Thing™. Don't underestimate the power of single threaded processes communicating using channels and no shared memory. It is true that any language has zealots, look at Fortran, Java, Python, D, but a language should not be judged solely by its zealotry level. Well except for JavaScript (aka ECMAScript) of course. […] I remember Java used to be "th" 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.
Re: Using D
On Friday, 11 July 2014 at 16:54:40 UTC, Chris wrote: On Friday, 11 July 2014 at 16:22:27 UTC, Russel Winder via Digitalmars-d wrote: On Fri, 2014-07-11 at 15:30 +, Chris via Digitalmars-d wrote: […] Let's not forget that Go has millions and billions of dollars behind it and that it is inevitable that the whole internet will be full of zealots and professional posters who promote Go as "th best thing ever". People. Sheep. Meehhh. (I think I detect unintended irony in this post :-) I get the point :-) Go, via goroutines, promotes CSP as an approach to application parallelism and is therefore a Good Thing™. Don't underestimate the power of single threaded processes communicating using channels and no shared memory. It is true that any language has zealots, look at Fortran, Java, Python, D, but a language should not be judged solely by its zealotry level. Well except for JavaScript (aka ECMAScript) of course. […] I remember Java used to be "th" 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.
Re: Using D
On Fri, Jul 11, 2014 at 03:30:15PM +, Chris via Digitalmars-d wrote: > I have followed the recent discussions about D and I can see the usual > pattern, to wit GC, Go (or whatever) is so much better, everyone > blaming each other for not contributing, not being allowed to > contribute blah. Well, this forum *is* for discussing ways of improving D, so it shouldn't be surprising that we constantly find things to nitpick about. :-) It doesn't mean at all that D is lousy or the community is bad, 'cos if it were so, we wouldn't even be here to begin with. We're here 'cos we care, and we complain 'cos we care enough to want things to improve. > First of all, I am in no position to criticize anyone who is > contributing to the language. I don't contribute, because I don't have > the time to do so. Indeed I have huge, massive respect for everyone > who contributes to D. The only thing I do is to actually use the > language and tell everyone about it. I have developed a screen reader > plug in in D (using C libraries) that was ridiculously easy to > integrate on Windows as a DLL. I used vibe.d to create a lightning > fast online version of the screen reader. Believe me, D's supposed > sluggishness as regards GC is not so important for most applications. > I dare say 90% of all applications are fine with the current GC. I > compiled both applications with dmd (testing phase) not with ldc or > gdc and they are very fast. I agree. I'm still convinced that GC phobia is blown out of proportion -- I used to be in that camp, so I totally sympathize with where they're coming from -- but as you say, only a small percentage of applications actually need to squeeze every last cycle out of the CPU such that the GC actually starts to make a significant difference in performance. Most applications work just fine with the GC, and in fact, I'd argue that they work *better* with the GC, because manual memory management is *hard* (just look at how many security exploits are caused by memory management mistakes) and tedious (look at how often the same memory bugs are repeated over and over). GC-supported code is cleaner to read, easier to write, and in many cases, the simpler design of the code reduces the likelihood of bugs and eliminates a whole class of bugs. Sure you pay for that by short pauses every now and then, but seriously, 90% of applications don't even *care* about such pauses. For applications with slightly higher performance demands, gdc -O3 (or whatever the LDC equivalent is) generally improves performance by about 20% or so above dmd. In my own compute-intensive projects, I have consistently noted about a 20-30% performance improvement when compiling with gdc, compared to dmd. That's pretty significant, because GC pauses are generally nowhere near that percentage, so just by recompiling with gdc already eliminates the perceived GC performance issue for 95% of applications. Besides, avoiding frequent small allocations also reduces most of the workload of the GC, so you can still get pretty far without totally turning it off. So it's really only the remaining 5% of applications that really, absolutely, *have* to go GC-less (or control it very tightly). They do happen to have supporters of the rather vocal kind, so we tend to hear from them a lot more, but that by no means is representative of the grand scheme of things as far as the GC is concerned! [...] > Let's first make a list of things that have been achieved with D and > that are on a par with or even bettar than in other languages (C, C++, > C#, Go, Rust ...). I don't know C#, Go, or Rust, so I can't really say much on that front, but at least as far as C/C++ are concerned, D totally beats them flat in the following points IMO: - Metaprogramming. Templates in C++ scarred many for life. Templates in D are actually a pleasure to use. - CTFE. Coupled with metaprogramming, this is a total killer combination that I've yet to see another language beat. - Slices. Finally, a systems-level language whose string support isn't crippled (C), maimed (C++), or otherwise handicapped (Java). And this extends to arrays in general. While there *are* other language with nice string/array manipulation support, D is the only one I know of that does it without sacrificing performance. - Ranges. It can totally revolutionize the way you approach programming. And, with metaprogramming/CTFE, they can still perform as fast as non-range-based code. Total win! - Extended meaning of purity: IMO it's a total stroke of genius to define "weak purity" that allows you to implement pure functions (in the Haskell sense) using mutating primitives (loops and assignments, etc.). While the current compilers don't really do that much with this presently, there is a lot of potential here that may turn this into a killer feature. - Built-in unittests. Sounds trivial, but I can testify to its value in dramatically improving the quality of my code. I've worke
Re: Using D
On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Jul 11, 2014 at 03:30:15PM +, Chris via Digitalmars-d wrote: I have followed the recent discussions about D and I can see the usual pattern, to wit GC, Go (or whatever) is so much better, everyone blaming each other for not contributing, not being allowed to contribute blah. Well, this forum *is* for discussing ways of improving D, so it shouldn't be surprising that we constantly find things to nitpick about. :-) It doesn't mean at all that D is lousy or the community is bad, 'cos if it were so, we wouldn't even be here to begin with. We're here 'cos we care, and we complain 'cos we care enough to want things to improve. First of all, I am in no position to criticize anyone who is contributing to the language. I don't contribute, because I don't have the time to do so. Indeed I have huge, massive respect for everyone who contributes to D. The only thing I do is to actually use the language and tell everyone about it. I have developed a screen reader plug in in D (using C libraries) that was ridiculously easy to integrate on Windows as a DLL. I used vibe.d to create a lightning fast online version of the screen reader. Believe me, D's supposed sluggishness as regards GC is not so important for most applications. I dare say 90% of all applications are fine with the current GC. I compiled both applications with dmd (testing phase) not with ldc or gdc and they are very fast. I agree. I'm still convinced that GC phobia is blown out of proportion -- I used to be in that camp, so I totally sympathize with where they're coming from -- but as you say, only a small percentage of applications actually need to squeeze every last cycle out of the CPU such that the GC actually starts to make a significant difference in performance. Most applications work just fine with the GC, and in fact, I'd argue that they work *better* with the GC, because manual memory management is *hard* (just look at how many security exploits are caused by memory management mistakes) and tedious (look at how often the same memory bugs are repeated over and over). GC-supported code is cleaner to read, easier to write, and in many cases, the simpler design of the code reduces the likelihood of bugs and eliminates a whole class of bugs. Sure you pay for that by short pauses every now and then, but seriously, 90% of applications don't even *care* about such pauses. For applications with slightly higher performance demands, gdc -O3 (or whatever the LDC equivalent is) generally improves performance by about 20% or so above dmd. In my own compute-intensive projects, I have consistently noted about a 20-30% performance improvement when compiling with gdc, compared to dmd. That's pretty significant, because GC pauses are generally nowhere near that percentage, so just by recompiling with gdc already eliminates the perceived GC performance issue for 95% of applications. Besides, avoiding frequent small allocations also reduces most of the workload of the GC, so you can still get pretty far without totally turning it off. So it's really only the remaining 5% of applications that really, absolutely, *have* to go GC-less (or control it very tightly). They do happen to have supporters of the rather vocal kind, so we tend to hear from them a lot more, but that by no means is representative of the grand scheme of things as far as the GC is concerned! [...] Let's first make a list of things that have been achieved with D and that are on a par with or even bettar than in other languages (C, C++, C#, Go, Rust ...). I don't know C#, Go, or Rust, so I can't really say much on that front, but at least as far as C/C++ are concerned, D totally beats them flat in the following points IMO: - Metaprogramming. Templates in C++ scarred many for life. Templates in D are actually a pleasure to use. - CTFE. Coupled with metaprogramming, this is a total killer combination that I've yet to see another language beat. - Slices. Finally, a systems-level language whose string support isn't crippled (C), maimed (C++), or otherwise handicapped (Java). And this extends to arrays in general. While there *are* other language with nice string/array manipulation support, D is the only one I know of that does it without sacrificing performance. - Ranges. It can totally revolutionize the way you approach programming. And, with metaprogramming/CTFE, they can still perform as fast as non-range-based code. Total win! - Extended meaning of purity: IMO it's a total stroke of genius to define "weak purity" that allows you to implement pure functions (in the Haskell sense) using mutating primitives (loops and assignments, etc.). While the current compilers don't really do that much with this presently, there is a lot of potential here that may turn this into a killer feature. - Built-in uni
Re: Using D
On Fri, Jul 11, 2014 at 04:54:39PM +, Chris via Digitalmars-d wrote:
[...]
> I remember Java used to be "th" best thing ever. After years of
> using it, however, I found out how restricted the language was / is.
> Still, it's been a success, because people believed all the
> propaganda. What matters to me is not so much the odd fancy feature,
> it's how well the language performs in general purpose programming.
[...]
I remember how I was skeptical of Java from day 1. Call me a cynic, but
everytime I hear something being overhyped, I immediately assign
whatever it is being hyped about as a second class product, and regard
it with suspicion. Same goes with cloud computing, which, as Nick likes
to say, is just marketing propaganda for "the internet".
When I finally got past the hype and tried out the language for myself,
I found the same thing you did: it's totally straitjacketed, and shoves
the OO idealogy down your throat even when it obviously doesn't fit. The
infamous long-winded "class MyLousyApp { public static void main(blah
blah blah) ... }" is a prime example of shoehorning something obviously
non-OO into an OO paradigm, just because we want to. Not to mention
Java's verbosity, which is only tolerable with IDE support -- total
fail, in my book. I mean, hello, we're talking about a *language*
intended for *humans* to communicate with the computer? If we need
*another* program to help us elucidate this communication, something's
gone very, very wrong with the language. A language that needs a machine
to help you write, is by definition a language for communication between
*machines*, not between humans and machines.
Then there's the lack of generics until the n'th revision, and when it
finally came, it was lackluster (google for issues caused by type
erasure in Java sometime). D totally beats Java in this area IMO.
That's not to say that Java, the language, (as opposed to the class
library or the marketing hype) isn't a pretty good language. In fact,
it's quite a beautiful language -- in the idealistic, ivory tower,
detached-from-real-life sense of being a perfect specimen suitable for a
museum piece. Its disconnect from the messy real world, unfortunately,
makes it rather painful to use in real-life. Well, except with the help
of automated tools like IDEs and what-not, which makes one wonder, if we
need a machine to help us communicate with a machine, why not just write
assembly language instead? But I digress. :-P
[...]
> Mind you, D is a hindsight language, which makes it wiser. Does it
> have flaws? Yes. I come across them sometimes. Is there a language
> without flaws? If there is, tell me about it.
When I was still using C/C++ for my personal projects, the problems I
keep running into drove me to dream about what I'd like in an ideal
language. I tried writing my own, but didn't get very far -- not
everyone is a Walter Bright, after all. ;-) So I searched online instead
-- and found that D is the one language that's closest to my idea of
what an ideal language should be. There are some things about it that
aren't quite up to my ideals, but there are also many other areas where
it *exceeded* my ideals. So in spite of whatever warts or wrinkles D may
have, it's still the best language out there IMO.
> I'm very pragmatic, D is a good tool and, being community driven,
> there is a real chance of making it a fantastic tool. Individual
> features are not everything.
Agreed, it's the synergy of multiple complementary features coming
together, that really makes the language shine. Templates + CTFE +
static if, is one example I can think of. Together, they make a total
killer combination in the world of metaprogramming IMO. I'm sure you can
think of several other synergistic combinations in D.
T
--
Claiming that your operating system is the best in the world because
more people use it is like saying McDonalds makes the best food in the
world. -- Carl B. Constantine
Re: Using D
On Fri, Jul 11, 2014 at 05:39:30PM +, Chris via Digitalmars-d wrote:
[...]
> Thanks. That's a nice list. This is what I was talking about, the
> experience with D, what you can achieve with it and how it compares
> with other languages. We need more of this. I have the feeling
> sometimes that to an outsider D might look like an eternally
> unfinished business. A nice playground for programmers, but not for
> production, which is absolutely not true. The GC issue is sometimes
> presented as "the language will stand or fall with this". As you noted
> and which is also my experience, the GC issue ain't that big. 90-95%
> of all applications can live with it.
Oh, and how did I forget UFCS? I think some of us were a bit hesitant
about this at first, but coupled with ranges, it has opened up a whole
new way of writing (and thinking about) your program:
// UFCS FTW! ;-)
auto formatYear(int year, int monthsPerRow)
{
return datesInYear(year)
.byMonth()
.chunks(monthsPerRow)
.map!(row => row.formatMonths()
.array()
.pasteBlocks(colSpacing)
.join("\n"))
.join("\n\n");
}
(Shamelessly quoted from my article:
http://wiki.dlang.org/Component_programming_with_ranges
;-))
T
--
Don't modify spaghetti code unless you can eat the consequences.
Re: Using D
On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote: Let's not forget that zeolots and professional posters will always point out the flaws of D, and blow them out of proportion. "D doesn't have xyz, so it's shit!" Divide et impera (divide and rule). Lol, this one made me laugh. It is true though. I have only been keeping up with D for like the last year or so and have found that its missing many things that i would like it to do by itself, without the help of C/C++. Multimedia and graphics for example. D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an exception because...well...every OS out there has OpenGL... Apart from that GC is a concern to many. I can see why GC would not be needed for a systems language but i see D primarily as a General Software Programming language where GC is most needed.
Re: Using D
On Friday, 11 July 2014 at 17:54:38 UTC, Israel Rodriguez wrote: Lol, this one made me laugh. It is true though. I have only been keeping up with D for like the last year or so and have found that its missing many things that i would like it to do by itself, without the help of C/C++. Multimedia and graphics for example. D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an exception because...well...every OS out there has OpenGL... Apart from that GC is a concern to many. I can see why GC would not be needed for a systems language but i see D primarily as a General Software Programming language where GC is most needed. Right not i use C# are my primary language where i can do everything and anything i need but thats only because the .NET framework provides nearly everything i need without the help of C/C++. The only thing i need is win32 APIs.
Re: Using D
On Friday, 11 July 2014 at 17:41:41 UTC, H. S. Teoh via Digitalmars-d wrote: [...] Mind you, D is a hindsight language, which makes it wiser. Does it have flaws? Yes. I come across them sometimes. Is there a language without flaws? If there is, tell me about it. When I was still using C/C++ for my personal projects, the problems I keep running into drove me to dream about what I'd like in an ideal language. I tried writing my own, but didn't get very far -- not everyone is a Walter Bright, after all. ;-) So I searched online instead -- and found that D is the one language that's closest to my idea of what an ideal language should be. There are some things about it that aren't quite up to my ideals, but there are also many other areas where it *exceeded* my ideals. So in spite of whatever warts or wrinkles D may have, it's still the best language out there IMO. I went down a similar path. Always frustrated with existing languages. Then I accidentally discovered D and I knew that was it! It killed so many birds with one stone. Unicode, C-interfaceable (if that's a word), native compilation to begin with, then I discovered all the nice features and I've become a better programmer simply by trying to understand D. It gives me more freedom to put human thought into a computer, to model our world in terms a computer can understand, and not the other way around. I still don't get why people who put up with other languages like Java and C++, and patiently wait years for simple improvements, say, when they see D, "it doesn't have xyz*, it's shit!" I just don't get it. *(usually GC or thread related)
Re: Using D
On Friday, 11 July 2014 at 17:54:38 UTC, Israel Rodriguez wrote: On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote: Let's not forget that zeolots and professional posters will always point out the flaws of D, and blow them out of proportion. "D doesn't have xyz, so it's shit!" Divide et impera (divide and rule). Lol, this one made me laugh. It is true though. I have only been keeping up with D for like the last year or so and have found that its missing many things that i would like it to do by itself, without the help of C/C++. Multimedia and graphics for example. D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an exception because...well...every OS out there has OpenGL... Why reinvent the wheel, when D can interface to the wheel. A lot of things are programmed in C/C++. Other languages use modules (Python, Java) to access existing C libraries. D can do it straight away. I cannot tell you how much it has helped me. I depend on C libraries not because I use D, but because the libraries are useful and well established / tested / sound. Apart from that GC is a concern to many. I can see why GC would not be needed for a systems language but i see D primarily as a General Software Programming language where GC is most needed.
Re: Using 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.
Re: Using D
On Friday, 11 July 2014 at 18:13:52 UTC, Chris wrote: On Friday, 11 July 2014 at 17:54:38 UTC, Israel Rodriguez wrote: On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote: Let's not forget that zeolots and professional posters will always point out the flaws of D, and blow them out of proportion. "D doesn't have xyz, so it's shit!" Divide et impera (divide and rule). Lol, this one made me laugh. It is true though. I have only been keeping up with D for like the last year or so and have found that its missing many things that i would like it to do by itself, without the help of C/C++. Multimedia and graphics for example. D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an exception because...well...every OS out there has OpenGL... Why reinvent the wheel, when D can interface to the wheel. A lot of things are programmed in C/C++. Other languages use modules (Python, Java) to access existing C libraries. D can do it straight away. I cannot tell you how much it has helped me. I depend on C libraries not because I use D, but because the libraries are useful and well established / tested / sound. Apart from that GC is a concern to many. I can see why GC would not be needed for a systems language but i see D primarily as a General Software Programming language where GC is most needed. This is true, but theoretically i feel this is wrong because its like putting training wheels on your bike. Know what i mean? Anyways thats just how "Feel" but maybe youre right, in that, maybe that isnt the right way to go...
Re: Using D
On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Jul 11, 2014 at 03:30:15PM +, Chris via Digitalmars-d wrote: I have followed the recent discussions about D and I can see the usual pattern, to wit GC, Go (or whatever) is so much better, everyone blaming each other for not contributing, not being allowed to contribute blah. Well, this forum *is* for discussing ways of improving D, so it shouldn't be surprising that we constantly find things to nitpick about. :-) It doesn't mean at all that D is lousy or the community is bad, 'cos if it were so, we wouldn't even be here to begin with. We're here 'cos we care, and we complain 'cos we care enough to want things to improve. First of all, I am in no position to criticize anyone who is contributing to the language. I don't contribute, because I don't have the time to do so. Indeed I have huge, massive respect for everyone who contributes to D. The only thing I do is to actually use the language and tell everyone about it. I have developed a screen reader plug in in D (using C libraries) that was ridiculously easy to integrate on Windows as a DLL. I used vibe.d to create a lightning fast online version of the screen reader. Believe me, D's supposed sluggishness as regards GC is not so important for most applications. I dare say 90% of all applications are fine with the current GC. I compiled both applications with dmd (testing phase) not with ldc or gdc and they are very fast. I agree. I'm still convinced that GC phobia is blown out of proportion -- I used to be in that camp, so I totally sympathize with where they're coming from -- but as you say, only a small percentage of applications actually need to squeeze every last cycle out of the CPU such that the GC actually starts to make a significant difference in performance. Most applications work just fine with the GC, and in fact, I'd argue that they work *better* with the GC, because manual memory management is *hard* (just look at how many security exploits are caused by memory management mistakes) and tedious (look at how often the same memory bugs are repeated over and over). GC-supported code is cleaner to read, easier to write, and in many cases, the simpler design of the code reduces the likelihood of bugs and eliminates a whole class of bugs. Sure you pay for that by short pauses every now and then, but seriously, 90% of applications don't even *care* about such pauses. For applications with slightly higher performance demands, gdc -O3 (or whatever the LDC equivalent is) generally improves performance by about 20% or so above dmd. In my own compute-intensive projects, I have consistently noted about a 20-30% performance improvement when compiling with gdc, compared to dmd. That's pretty significant, because GC pauses are generally nowhere near that percentage, so just by recompiling with gdc already eliminates the perceived GC performance issue for 95% of applications. Besides, avoiding frequent small allocations also reduces most of the workload of the GC, so you can still get pretty far without totally turning it off. So it's really only the remaining 5% of applications that really, absolutely, *have* to go GC-less (or control it very tightly). They do happen to have supporters of the rather vocal kind, so we tend to hear from them a lot more, but that by no means is representative of the grand scheme of things as far as the GC is concerned! [...] Let's first make a list of things that have been achieved with D and that are on a par with or even bettar than in other languages (C, C++, C#, Go, Rust ...). I don't know C#, Go, or Rust, so I can't really say much on that front, but at least as far as C/C++ are concerned, D totally beats them flat in the following points IMO: - Metaprogramming. Templates in C++ scarred many for life. Templates in D are actually a pleasure to use. - CTFE. Coupled with metaprogramming, this is a total killer combination that I've yet to see another language beat. - Slices. Finally, a systems-level language whose string support isn't crippled (C), maimed (C++), or otherwise handicapped (Java). And this extends to arrays in general. While there *are* other language with nice string/array manipulation support, D is the only one I know of that does it without sacrificing performance. - Ranges. It can totally revolutionize the way you approach programming. And, with metaprogramming/CTFE, they can still perform as fast as non-range-based code. Total win! - Extended meaning of purity: IMO it's a total stroke of genius to define "weak purity" that allows you to implement pure functions (in the Haskell sense) using mutating primitives (loops and assignments, etc.). While the current compilers don't really do that much with this presently, there is a lot of potential here that may turn this into a killer feature. - Built-in uni
Re: Using D
On Friday, 11 July 2014 at 15:42:04 UTC, simendsjo wrote: On 07/11/2014 05:30 PM, Chris wrote: (...) Believe me, D's supposed sluggishness as regards GC is not so important for most applications. I dare say 90% of all applications are fine with the current GC. (...) I agree with this. The bottlenecks i my applications are MySQL and Microsoft Office (Excel, Powerpoint, or even just plain COM). The same bottlenecks as I get when using C#. Of course, it depends a lot on what you do, but for my use (and yours, and probably many others), the GC performance is something you can probably safely ignore. Ah, but that's because you're comparing it to C#, not languages that don't use GC. The big problem for D is that the market for programming languages has bifurcated since D was created, with the performant native-compiled languages like C/C++/Obj-C on one side and the much larger market for easier to use but much less performant, what used to be called "scripting," languages like ruby/python/java on the other. Trying to be a better C++, by borrowing some ease of use features like GC or reflection from the scripting languages, leaves D stuck in the middle right now, neither here nor there. Who still uses native-compiled languages? Performance-sensitive games, server applications that squeeze out performance, like number-crunching or search engines, and desktop apps that need the performance, that's about it. Everything else has either gone to the web with a scripting language backend or mobile. I hear that even enterprise LOB desktop apps are mostly written in Java/C# these days, because they just don't need the speed of a native language and can crank the code out quicker that way. However, mobile could be D's saving grace, as native development is back on iOS and even Android is moving to Ahead-Of-Time compiling with the next release. Too bad D doesn't work on mobile, even though some of us are working on getting it there. D should focus on the native end of the market, by trying to be the easier way to get most of the performance. You're not going to get the scripting guys now, because native is just too hard for them. If D can assert itself in that smaller niche of native languages, it might have enough juice to go after the other end later. I don't think either happens without a commercial implementation, community development doesn't cut it. Linux didn't take off till long after it got commercial vendors on board, the same will be true here. I don't mean to be pessimistic about D's goal of being usable by all, from scripting to systems, as D may actually be good enough to get there one day. I just think you're not going to get there without focusing on taking over a niche at a time, particularly the niche best suited to D right now, mobile.
Re: Using D
On 7/11/2014 1:40 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jul 11, 2014 at 04:54:39PM +, Chris via Digitalmars-d wrote:
[...]
I remember Java used to be "th" best thing ever. After years of
using it, however, I found out how restricted the language was / is.
Still, it's been a success, because people believed all the
propaganda. What matters to me is not so much the odd fancy feature,
it's how well the language performs in general purpose programming.
[...]
I remember how I was skeptical of Java from day 1. Call me a cynic, but
everytime I hear something being overhyped, I immediately assign
whatever it is being hyped about as a second class product, and regard
it with suspicion.
I tend to be like that even for non-computer stuff too, viewing
whatever's popular with skepticism. Once in a while it'll backfire and
keep me away from something I later realize is actually pretty decent,
but I've found *usually* it serves me well. But then, my tastes tend to
be uncommon *anyway*, so maybe that's why it works for me ;)
Same goes with cloud computing, which, as Nick likes
to say, is just marketing propaganda for "the internet".
Yes!!
"Cloud" drives me crazy more than any other word! It's the hipster word
for "Internet", and it's EVERYWHERE.
When I finally got past the hype and tried out the language for myself,
I found the same thing you did: it's totally straitjacketed, and shoves
the OO idealogy down your throat even when it obviously doesn't fit. The
infamous long-winded "class MyLousyApp { public static void main(blah
blah blah) ... }" is a prime example of shoehorning something obviously
non-OO into an OO paradigm, just because we want to. Not to mention
Java's verbosity, which is only tolerable with IDE support -- total
fail, in my book. I mean, hello, we're talking about a *language*
intended for *humans* to communicate with the computer? If we need
*another* program to help us elucidate this communication, something's
gone very, very wrong with the language. A language that needs a machine
to help you write, is by definition a language for communication between
*machines*, not between humans and machines.
While I agree with all of that, there are two things I've always had to
give Java credit for: It's classes and module system are what originally
taught me that C/C++ aren't ideal and...umm...have some notable downsides...
That's not to say that Java, the language, (as opposed to the class
library or the marketing hype) isn't a pretty good language. In fact,
it's quite a beautiful language -- in the idealistic, ivory tower,
detached-from-real-life sense of being a perfect specimen suitable for a
museum piece. Its disconnect from the messy real world, unfortunately,
makes it rather painful to use in real-life.
Yea, that's one of the things that drew me to D. It came around saying
(quite literally) "pragmatic language design" at exactly the time I was
noticing how much of a pain ideology-driven and minimalist languages can be.
Re: Using D
On Fri, Jul 11, 2014 at 03:08:39PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
> On 7/11/2014 1:40 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
> >That's not to say that Java, the language, (as opposed to the class
> >library or the marketing hype) isn't a pretty good language. In fact,
> >it's quite a beautiful language -- in the idealistic, ivory tower,
> >detached-from-real-life sense of being a perfect specimen suitable
> >for a museum piece. Its disconnect from the messy real world,
> >unfortunately, makes it rather painful to use in real-life.
>
> Yea, that's one of the things that drew me to D. It came around saying
> (quite literally) "pragmatic language design" at exactly the time I
> was noticing how much of a pain ideology-driven and minimalist
> languages can be.
If you really wanna go minimalist, there's BF... :-P
On the other extreme of pragmatism, Larry Wall claims that the reason
Perl is useful is because it's a mess, which maps well to the problem
space, which is also a mess, which we call reality. :-P I *will* say
that at one point I was quite enamored of Perl, but nowadays I think it
goes a little *too* far in the pragmatism, and as a result is rather
messy to work with.
One of the big advantages of D was that it's so easy to use when what
you need is something simple, so I've been writing quite a lot of little
script-like helper programs nowadays in D where in the past I would have
used Perl. Unlike Perl, though, D also scales up nicely when what was
initially a simple problem grows into a more complex problem. In Perl,
there's this threshold of complexity below which it's pretty comfortable
to use, but once you pass that point, the seams start to burst and the
potholes start to appear, a common sign of which is the appearance of
deeply-nested data structures that leads to riddle-like code such as:
${a{b}{c}}->{$d->{e}}->{f} = ${g[h]{i}->{j}}->{k}[l]->{m};
along with the programming-by-convention that comes along with it.
Abstractions in Perl tend to be quite leaky, which is OK with write-once
throwaway-after scripts, but as the complexity of the program increases,
it becomes a source of frustration and hiding places for bugs.
In D, you simply leave the original script-like core as-is, then bring
in the proverbial big guns on top of it to deal with the growing
complexity, and the miracle is that the result is all nicely integrated
and water-tight. It's quite unlike any other programming language that
I've used before, in this respect.
T
--
Talk is cheap. Whining is actually free. -- Lars Wirzenius
Re: Using D
On 7/11/2014 10:54 AM, Israel Rodriguez wrote: On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote: Let's not forget that zeolots and professional posters will always point out the flaws of D, and blow them out of proportion. "D doesn't have xyz, so it's shit!" Divide et impera (divide and rule). Lol, this one made me laugh. Speaking of inventing reasons to not use D, years ago the reason was "D has only one implementation, so it's too risky to use." Lately, the reason is "D has 3 implementations, so it's too risky to use, there should be only one". We have to be careful to filter out real reasons from people just pulling our chains.
Re: Using 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.
Re: Using D
This is an awesome list, it's almost exactly what I would have written!
Re: Using D
On Friday, 11 July 2014 at 19:00:30 UTC, Joakim wrote: On Friday, 11 July 2014 at 15:42:04 UTC, simendsjo wrote: On 07/11/2014 05:30 PM, Chris wrote: (...) Believe me, D's supposed sluggishness as regards GC is not so important for most applications. I dare say 90% of all applications are fine with the current GC. (...) I agree with this. The bottlenecks i my applications are MySQL and Microsoft Office (Excel, Powerpoint, or even just plain COM). The same bottlenecks as I get when using C#. Of course, it depends a lot on what you do, but for my use (and yours, and probably many others), the GC performance is something you can probably safely ignore. Ah, but that's because you're comparing it to C#, not languages that don't use GC. The big problem for D is that the market for programming languages has bifurcated since D was created, with the performant native-compiled languages like C/C++/Obj-C on one side and the much larger market for easier to use but much less performant, what used to be called "scripting," languages like ruby/python/java on the other. Trying to be a better C++, by borrowing some ease of use features like GC or reflection from the scripting languages, leaves D stuck in the middle right now, neither here nor there. Who still uses native-compiled languages? Performance-sensitive games, server applications that squeeze out performance, like number-crunching or search engines, and desktop apps that need the performance, that's about it. Everything else has either gone to the web with a scripting language backend or mobile. I hear that even enterprise LOB desktop apps are mostly written in Java/C# these days, because they just don't need the speed of a native language and can crank the code out quicker that way. However, mobile could be D's saving grace, as native development is back on iOS and even Android is moving to Ahead-Of-Time compiling with the next release. Too bad D doesn't work on mobile, even though some of us are working on getting it there. I agree. This is a big pain for me too. D should focus on the native end of the market, by trying to be the easier way to get most of the performance. You're not going to get the scripting guys now, because native is just too hard for them. If D can assert itself in that smaller niche of native languages, it might have enough juice to go after the other end later. I don't think either happens without a commercial implementation, community development doesn't cut it. Linux didn't take off till long after it got commercial vendors on board, the same will be true here. I don't mean to be pessimistic about D's goal of being usable by all, from scripting to systems, as D may actually be good enough to get there one day. I just think you're not going to get there without focusing on taking over a niche at a time, particularly the niche best suited to D right now, mobile. A niche for a general purpose language?
Re: Using D
On Friday, 11 July 2014 at 19:56:20 UTC, Chris wrote: I don't mean to be pessimistic about D's goal of being usable by all, from scripting to systems, as D may actually be good enough to get there one day. I just think you're not going to get there without focusing on taking over a niche at a time, particularly the niche best suited to D right now, mobile. A niche for a general purpose language? Name one "general purpose language" that currently crosses the native->scripting divide and has good usage on both ends of the market. It doesn't exist, because it's almost impossible to do. Even if your goal is to be general purpose, you have to do it by taking on one niche at a time, which is even harder because you have to have your eye on staying general purpose the whole time. It's an extremely difficult balancing act, with one hand tied behind your back. I think D could do it someday, but not the way the market is today. Right now, it's too easy for many developers to slap together a webapp on rails or django and then simply scale up their hardware when necessary. Maybe that all changes in the future and efficiency becomes more of a concern on the server, perhaps when the market matures, but we're not there yet. In the meantime, mobile is where most new native development has moved, so D has to really hit that fertile ground. I also think big data could be big for D, Don mentioned D brought their costs down a lot in his DConf talk.
Re: Using D
On Friday, 11 July 2014 at 19:46:25 UTC, Walter Bright wrote: I agree that the GC phobia is way, WAY, overblown for practical programming. I agree with this, as well, but it's a generalization. There are some applications that the current GC is not suitable for, but D provides a plethora of features for disabling the GC or managing memory in other ways (very cool), so I don't see a reason to not use D even for the most demanding problem. I love the GC for some things I do, but can't use it for other things I do. For the vast majority of applications I see people using D for, however, I see no reason why there should be any worry about the GC. The problem, however, when managing one's own memory is that one cannot use some of the built-in types, like Exceptions, that are instantiated deep within the runtime. A solution to this would likely quiet some of the clamoring, IMO. I would be interested in hearing any suggestions for disabling the GC and still making use of Exceptions, dynamic arrays, etc... using a user-supplied memory manager. Maybe something like this already exists, and people like me just aren't aware of it. Being a novice still, I don't know what the solution is. At the moment I exploring region-based memory management (nice example at http://en.wikipedia.org/wiki/Region-based_memory_management). I also saw some proposals for something like gc.pushAllocator(myAllocator)/gc.popAllocator(), which would be nice. Mike
Re: Using D
On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via Digitalmars-d wrote: - Metaprogramming. Templates in C++ scarred many for life. Templates in D are actually a pleasure to use. - CTFE. Coupled with metaprogramming, this is a total killer combination that I've yet to see another language beat. - Slices. Finally, a systems-level language whose string support isn't crippled (C), maimed (C++), or otherwise handicapped (Java). And this extends to arrays in general. While there *are* other language with nice string/array manipulation support, D is the only one I know of that does it without sacrificing performance. - Ranges. It can totally revolutionize the way you approach programming. And, with metaprogramming/CTFE, they can still perform as fast as non-range-based code. Total win! - Extended meaning of purity: IMO it's a total stroke of genius to define "weak purity" that allows you to implement pure functions (in the Haskell sense) using mutating primitives (loops and assignments, etc.). While the current compilers don't really do that much with this presently, there is a lot of potential here that may turn this into a killer feature. - Built-in unittests. Sounds trivial, but I can testify to its value in dramatically improving the quality of my code. I've worked with large C/C++ codebases, and most of them don't even bother with any kind of unit testing -- it's up to the programmer to test everything, and we just take his word for it -- and simply accept the countless stream of bugs that come thereafter as a fact of life. Of the rare few that actually do have tests, the tests are usually (1) outdated, (2) commented out 'cos nobody cares to update them, (3) ignored by the coders anyway 'cos they can't be bothered to switch to another language in another framework just to write tests that nobody will run while having their hands tied behind their back. D's built-in unittest blocks is a total game changer in this area, in spite of its simplicity (which some people have complained about). - Along these lines, static assert totally rawkz. It ensures, at *compile-time*, that assumptions in your code haven't been violated by a careless code change, forcing the person who made the change to fix it (rather than introducing a possibly subtle error that will only be uncovered months down the road on the customer's production site). - The fastest regex library known on the planet (thanks to, guess what? metaprogramming and CTFE!). I'm a regex aficionado, and this is a total big deal in my book. - Built-in Unicode support. Compiler-level support for Unicode is something C/C++ sorely lacks, and that immediately puts them in the "legacy" category. LibICU is a nightmare to use. D, however, lets you treat Unicode directly in the language. (Full Unicode compliance isn't quite there yet, but we're getting pretty close.) Modern languages like Java/C# also have built-in Unicode support, so D is at least on par with them. C/C++ is definitely behind in this category, though. These are just language-level cool stuff. At a higher level, we also have: - rdmd: run your D programs like scripts, yet with native compiled performance. Rawkage! - Dustmite: a totally revolutionary tool IMO, that changes finding heisenbugs from an impossible game of chance to something that actually has hope of being fixed within reasonable amounts of time. - vibe.d: I haven't used it myself, but from what I hear, it's extremely awesome. Great list, I'll add a couple more: - GDC & LDC - D on ARM and other platforms is possible thanks to talent donated to these efforts. - D is universal - I don't know how to articulate this, but I'm sick of learning so many languages for different purposes and different platforms. I'm beginning to use D for just about everything, and I don't have to worry so much about whether I'm on Windows or Linux. I'm even using D to write low-level drivers for my micrcontroller. I use it for my build scripts, automating my builds in the same language I'm building. D, one language to rule them all. Mike
Re: Using D
On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Jul 11, 2014 at 03:30:15PM +, Chris via Digitalmars-d wrote: I have followed the recent discussions about D and I can see the usual pattern, to wit GC, Go (or whatever) is so much better, everyone blaming each other for not contributing, not being allowed to contribute blah. Well, this forum *is* for discussing ways of improving D, so it shouldn't be surprising that we constantly find things to nitpick about. :-) It doesn't mean at all that D is lousy or the community is bad, 'cos if it were so, we wouldn't even be here to begin with. We're here 'cos we care, and we complain 'cos we care enough to want things to improve. First of all, I am in no position to criticize anyone who is contributing to the language. I don't contribute, because I don't have the time to do so. Indeed I have huge, massive respect for everyone who contributes to D. The only thing I do is to actually use the language and tell everyone about it. I have developed a screen reader plug in in D (using C libraries) that was ridiculously easy to integrate on Windows as a DLL. I used vibe.d to create a lightning fast online version of the screen reader. Believe me, D's supposed sluggishness as regards GC is not so important for most applications. I dare say 90% of all applications are fine with the current GC. I compiled both applications with dmd (testing phase) not with ldc or gdc and they are very fast. I agree. I'm still convinced that GC phobia is blown out of proportion -- I used to be in that camp, so I totally sympathize with where they're coming from -- but as you say, only a small percentage of applications actually need to squeeze every last cycle out of the CPU such that the GC actually starts to make a significant difference in performance. Most applications work just fine with the GC, and in fact, I'd argue that they work *better* with the GC, because manual memory management is *hard* (just look at how many security exploits are caused by memory management mistakes) and tedious (look at how often the same memory bugs are repeated over and over). GC-supported code is cleaner to read, easier to write, and in many cases, the simpler design of the code reduces the likelihood of bugs and eliminates a whole class of bugs. Sure you pay for that by short pauses every now and then, but seriously, 90% of applications don't even *care* about such pauses. For applications with slightly higher performance demands, gdc -O3 (or whatever the LDC equivalent is) generally improves performance by about 20% or so above dmd. In my own compute-intensive projects, I have consistently noted about a 20-30% performance improvement when compiling with gdc, compared to dmd. That's pretty significant, because GC pauses are generally nowhere near that percentage, so just by recompiling with gdc already eliminates the perceived GC performance issue for 95% of applications. Besides, avoiding frequent small allocations also reduces most of the workload of the GC, so you can still get pretty far without totally turning it off. So it's really only the remaining 5% of applications that really, absolutely, *have* to go GC-less (or control it very tightly). They do happen to have supporters of the rather vocal kind, so we tend to hear from them a lot more, but that by no means is representative of the grand scheme of things as far as the GC is concerned! [...] Let's first make a list of things that have been achieved with D and that are on a par with or even bettar than in other languages (C, C++, C#, Go, Rust ...). I don't know C#, Go, or Rust, so I can't really say much on that front, but at least as far as C/C++ are concerned, D totally beats them flat in the following points IMO: - Metaprogramming. Templates in C++ scarred many for life. Templates in D are actually a pleasure to use. - CTFE. Coupled with metaprogramming, this is a total killer combination that I've yet to see another language beat. - Slices. Finally, a systems-level language whose string support isn't crippled (C), maimed (C++), or otherwise handicapped (Java). And this extends to arrays in general. While there *are* other language with nice string/array manipulation support, D is the only one I know of that does it without sacrificing performance. - Ranges. It can totally revolutionize the way you approach programming. And, with metaprogramming/CTFE, they can still perform as fast as non-range-based code. Total win! - Extended meaning of purity: IMO it's a total stroke of genius to define "weak purity" that allows you to implement pure functions (in the Haskell sense) using mutating primitives (loops and assignments, etc.). While the current compilers don't really do that much with this presently, there is a lot of potential here that may turn this into a killer feature. - Built-in uni
Re: Using D
On 12/07/2014 12:10 p.m., Mike wrote:
On Friday, 11 July 2014 at 19:46:25 UTC, Walter Bright wrote:
I agree that the GC phobia is way, WAY, overblown for practical
programming.
I agree with this, as well, but it's a generalization.
There are some applications that the current GC is not suitable for, but
D provides a plethora of features for disabling the GC or managing
memory in other ways (very cool), so I don't see a reason to not use D
even for the most demanding problem. I love the GC for some things I
do, but can't use it for other things I do. For the vast majority of
applications I see people using D for, however, I see no reason why
there should be any worry about the GC.
The problem, however, when managing one's own memory is that one cannot
use some of the built-in types, like Exceptions, that are instantiated
deep within the runtime. A solution to this would likely quiet some of
the clamoring, IMO.
I would be interested in hearing any suggestions for disabling the GC
and still making use of Exceptions, dynamic arrays, etc... using a
user-supplied memory manager. Maybe something like this already exists,
and people like me just aren't aware of it.
Being a novice still, I don't know what the solution is. At the moment
I exploring region-based memory management (nice example at
http://en.wikipedia.org/wiki/Region-based_memory_management). I also saw
some proposals for something like
gc.pushAllocator(myAllocator)/gc.popAllocator(), which would be nice.
Mike
Something I've been thinking about is an overload for with statement.
E.g.
with(new MyAllocator) {
void*[256] values;
//...
}
class MyAllocator : IGC {
private {
IGC prevGC;
}
void opWithIn() {
this.prevGC = GC.getImpl();
GC.setImpl(this);
}
void opWithOut() {
GC.setImpl(this.prevGC);
}
}
Of course if we added an overload that allowed for passing root memory
blocks that can be freed (ref countered guaranteed at compilation), we
could force them to be freed in opWithOut. Otherwise tell the previous
GC to use it.
Now I sort of mix GC and allocator up a little bit, but if it is done
right. We could swap out the GC for an allocator and make it almost the
same.
But in saying this, this would mean we would need to have a rethink of
how we do the GC in druntime. At least from the architecture point of view.
This isn't the reason I thought of this, mostly because I was exploring
how to do something like GWT nice (not really required but could be
useful for caching output).
Its a small addition, that may pay off for this kind of work
substantially. Unless of course we already have it? I didn't realize
that statements worked in with statements till a couple days ago. So if
not, I would be surprised.
Re: Using D
On Sat, Jul 12, 2014 at 01:18:05AM +, Mike via Digitalmars-d wrote: [...] > - D is universal - I don't know how to articulate this, but I'm sick > of learning so many languages for different purposes and different > platforms. I'm beginning to use D for just about everything, and I > don't have to worry so much about whether I'm on Windows or Linux. One of the things I eventually hope to get to, is to write D apps that work on both Windows and Linux. I'm pretty sure my code can already run on Windows, but I just haven't setup the dev environment yet. > I'm even using D to write low-level drivers for my micrcontroller. I > use it for my build scripts, automating my builds in the same language > I'm building. D, one language to rule them all. [...] Whoa. That's a pretty cool idea: use D to build D! I think I'm going to start doing that too. Right now I'm using SCons (Python-based), which is pretty great for what I need, but the thought of using D to build D sounds so appealing to me that I'm gonna hafta do just that. :) Thanks for the idea! T -- "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net)
Re: Using D
On 7/11/2014 5:10 PM, Mike wrote: The problem, however, when managing one's own memory is that one cannot use some of the built-in types, like Exceptions, that are instantiated deep within the runtime. A solution to this would likely quiet some of the clamoring, IMO. The thing is, Exceptions should be exceptional, not normal. So if you're worried about GC pauses during exception processing, I think it's time to re-examine what exceptions in your code are being used for.
Re: Using D
On 7/11/14, 9:10 PM, Walter Bright via Digitalmars-d wrote: On 7/11/2014 5:10 PM, Mike wrote: The problem, however, when managing one's own memory is that one cannot use some of the built-in types, like Exceptions, that are instantiated deep within the runtime. A solution to this would likely quiet some of the clamoring, IMO. The thing is, Exceptions should be exceptional, not normal. So if you're worried about GC pauses during exception processing, I think it's time to re-examine what exceptions in your code are being used for. It's not the try/throw/catch/finally parts, it's the new that's usually involved. The chance that the gc will kick in and affect every thread, not just the thread dealing with the exception is a big hit that is unacceptable in some scenarios.
Re: Using D
On Saturday, 12 July 2014 at 04:10:32 UTC, Walter Bright wrote: On 7/11/2014 5:10 PM, Mike wrote: The problem, however, when managing one's own memory is that one cannot use some of the built-in types, like Exceptions, that are instantiated deep within the runtime. A solution to this would likely quiet some of the clamoring, IMO. The thing is, Exceptions should be exceptional, not normal. So if you're worried about GC pauses during exception processing, I think it's time to re-examine what exceptions in your code are being used for. I understand that, but that wasn't my point. I was just using Exceptions as an example of a built-in type (instantiated in the runtime outside of the users control). Dynamic arrays are another. The goal is for the user to be able to be able to control the allocation for all types in D, not just the ones the user creates. And to be able to continue to use, to the extent possible, roughly the same idioms and patterns they would use if employing the GC. It looks like you were headed down that path with DIP46 (http://wiki.dlang.org/DIP46). It's almost a year old. Do you still feel its worth pursuing? Mike
Re: Using D
On Saturday, 12 July 2014 at 03:59:58 UTC, Rikki Cattermole wrote:
Something I've been thinking about is an overload for with
statement.
E.g.
with(new MyAllocator) {
void*[256] values;
//...
}
class MyAllocator : IGC {
private {
IGC prevGC;
}
void opWithIn() {
this.prevGC = GC.getImpl();
GC.setImpl(this);
}
void opWithOut() {
GC.setImpl(this.prevGC);
}
}
Of course if we added an overload that allowed for passing root
memory blocks that can be freed (ref countered guaranteed at
compilation), we could force them to be freed in opWithOut.
Otherwise tell the previous GC to use it.
Now I sort of mix GC and allocator up a little bit, but if it
is done right. We could swap out the GC for an allocator and
make it almost the same.
But in saying this, this would mean we would need to have a
rethink of how we do the GC in druntime. At least from the
architecture point of view.
This isn't the reason I thought of this, mostly because I was
exploring how to do something like GWT nice (not really
required but could be useful for caching output).
Its a small addition, that may pay off for this kind of work
substantially. Unless of course we already have it? I didn't
realize that statements worked in with statements till a couple
days ago. So if not, I would be surprised.
I think that puts convenient syntax around the basic idea.
Region-based memory management is just what I'm currently
studying. There are probably other ways to accomplish the goal:
allow the user control the allocation, lifetime, and deallocation
of the built-in types.
Mike
Re: Using D
On 7/11/2014 9:35 PM, Mike wrote: It looks like you were headed down that path with DIP46 (http://wiki.dlang.org/DIP46). It's almost a year old. Do you still feel its worth pursuing? I haven't thought much about that since. There always seems to be something else needing attention.
Re: Using D
On 7/11/2014 9:24 PM, Brad Roberts via Digitalmars-d wrote: On 7/11/14, 9:10 PM, Walter Bright via Digitalmars-d wrote: The thing is, Exceptions should be exceptional, not normal. So if you're worried about GC pauses during exception processing, I think it's time to re-examine what exceptions in your code are being used for. It's not the try/throw/catch/finally parts, it's the new that's usually involved. The chance that the gc will kick in and affect every thread, not just the thread dealing with the exception is a big hit that is unacceptable in some scenarios. That's a good point.
Re: Using D
On 07/11/2014 09:53 AM, simendsjo wrote: > On 07/11/2014 06:28 PM, Russel Winder via Digitalmars-d wrote: >> On Fri, 2014-07-11 at 17:43 +0200, simendsjo via Digitalmars-d wrote: >> […] >>> A little anecdote.. I once got a 20% speed increase in Python by >>> "moving" a variable instantiation outside a tight loop. >>>i = 0 >>># loop here >>> i = something >>> >>> rather than >>># loop here >>> i = something >> >> This is interesting. I can believe there is some performance benefit, >> but I am not sure I believe 20% improvement. If you can send me the code >> you were using, I would like to do some benchmarking on this. > > Yes, I was very perplexed when I was profiling and finally found the > main offender. Unfortunately I don't have the code - it was a project > done for a past employer back in 2006/2007 (Python 2.4 IIRC). > >>> The compiler wasn't smart enough to do this. >> >> The Python compiler cannot and will never be able to do any such thing. >> Indeed if it did any such thing, it would be an error since it >> significantly changes the semantics of the program. Thus not doing this >> is not the fault of the compiler. The fact that you were able to do >> this and it appeared to give you the same results just means that the >> change in program semantics did not affect your computation. Which is >> good, but not something the compiler could determine. > > I think of this as a fault in the compiler. It was quite obvious (to me) > that nothing else relied on the value so the value didn't have to be > created on each iteration. Can that 'i = something' expression be monkey-patched in Python? If so, it could have side-effects to make the program change semantics like Russel Winder means. Ali
Re: Using D
Ali Çehreli: Can that 'i = something' expression be monkey-patched in Python? If so, it could have side-effects to make the program change semantics like Russel Winder means. Right. And even PyPy isn't a compiler. Python is interpreted. And at best JITted. In most cases you use Cpython, that is an interpreter. And in Python most optimizations are dangerous, because the language is very dynamic. If you look for performance it's better for you to look elsewhere (like Julia). Bye, bearophile
Re: Using D
On Friday, 11 July 2014 at 19:08:43 UTC, Nick Sabalausky wrote: Yea, that's one of the things that drew me to D. It came around saying (quite literally) "pragmatic language design" at exactly the time I was noticing how much of a pain ideology-driven and minimalist languages can be. +1000 --- Paolo
Re: Using D
On Fri, 2014-07-11 at 20:25 +, Joakim via Digitalmars-d wrote: […] > 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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Using D
On Fri, 2014-07-11 at 18:53 +0200, simendsjo via Digitalmars-d wrote: […] > 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. […] > 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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Using D
On Fri, 2014-07-11 at 16:54 +, Chris via Digitalmars-d wrote: […] > I remember Java used to be "th" 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 :-) > 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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Using D
On Fri, 2014-07-11 at 10:40 -0700, H. S. Teoh via Digitalmars-d wrote:
[…]
> 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.
> Then there's the lack of generics until the n'th revision, and when it
> finally came, it was lackluster (google for issues caused by type
> erasure in Java sometime). D totally beats Java in this area IMO.
I think it may just be Stockholm Syndrome, but some notable people whose
opinions I generally trust, are now saying that type erasure in Java is
a good thing. I am not one of them. Java should have done what C# did
and enforce reification of type parameters in the underlying machine,
JVM and CLR respectively.
> That's not to say that Java, the language, (as opposed to the class
> library or the marketing hype) isn't a pretty good language. In fact,
> it's quite a beautiful language -- in the idealistic, ivory tower,
> detached-from-real-life sense of being a perfect specimen suitable for a
> museum piece. Its disconnect from the messy real world, unfortunately,
> makes it rather painful to use in real-life. Well, except with the help
> of automated tools like IDEs and what-not, which makes one wonder, if we
> need a machine to help us communicate with a machine, why not just write
> assembly language instead? But I digress. :-P
Now this is mis-direction. Java is a real-world language in that it is
used in the real world. Whilst there are many using Java because they
know no better, many are using it out of choice. Java evolves with the
needs of the users prepared to get involved in evolving the language.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Using D
On 12 July 2014 11:27, Russel Winder via Digitalmars-d wrote: > On Fri, 2014-07-11 at 16:54 +, Chris via Digitalmars-d wrote: > […] >> I remember Java used to be "th" best thing ever. After years >> of using it, however, I found out how restricted the language was >> / is. Still, it's been a success, because people believed all the >> propaganda. What matters to me is not so much the odd fancy >> feature, it's how well the language performs in general purpose >> programming. Go was designed for servers and thus will always >> have one up on D or any other language at that matter. But could >> I use Go for what I have used D? Not so sure about that. Also, >> like Java Go is a closed thing. D isn't. Once I read about D that >> it shows what can be done "once you take a language out of the >> hands of a committee". Go, like Java, will finally end up in a >> cul de sac and will have a hard time trying to get out of it. Not >> because the language is inherently bad, because it's in the hand >> of a committee. Ideology kills a language. But it doesn't matter, >> because people will use Go or whatever anyway, will _have_ to use >> it. > > People believed the FORTRAN propaganda, the COBOL propaganda, the Pascal > propaganda. I think we ought to distinguish good marketing from hype. > Java had good marketing, was in the right place at the right time, and > had a huge amount of hype as well. > > If Go is better for server things than D then might as well stop trying > to use D at all. > > Go was actually designed as a better C with CSP for concurrency and > parallelism. > Or a better Oberon, I haven't quite decided which yet... :) > If there were more D users in the London area than one in London and one > in Brighton maybe we could start a London D User Group (LonDUG). > SkillsMatter would host. > And I say Hello! from sunny Brighton. I do believe there are a few people around the London area who either have worked in, work in, or have a vested interest in D. I'll give Dejan a poke and find out some more numbers. Regards Iain.
Re: Using D
Am 12.07.2014 14:54, schrieb Iain Buclaw via Digitalmars-d: On 12 July 2014 11:27, Russel Winder via Digitalmars-d wrote: On Fri, 2014-07-11 at 16:54 +, Chris via Digitalmars-d wrote: […] I remember Java used to be "th" 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
Re: Using D
On Sat, 2014-07-12 at 13:54 +0100, Iain Buclaw via Digitalmars-d wrote: […] > Or a better Oberon, I haven't quite decided which yet... :) Whatever the reality initially, it is definitely now marketed as a modernized C. Echoes of C++ then. > > If there were more D users in the London area than one in London and one > > in Brighton maybe we could start a London D User Group (LonDUG). > > SkillsMatter would host. > > > > And I say Hello! from sunny Brighton. Aha the Brighton dwelling D user of note ;-) I have lived in Brighton, but it was a long time ago, it is probably very different now. No West Pier for a start! > I 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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Using D
On 12 July 2014 15:11, Russel Winder via Digitalmars-d wrote: > On Sat, 2014-07-12 at 13:54 +0100, Iain Buclaw via Digitalmars-d wrote: > […] >> Or a better Oberon, I haven't quite decided which yet... :) > > Whatever the reality initially, it is definitely now marketed as a > modernized C. Echoes of C++ then. > >> > If there were more D users in the London area than one in London and one >> > in Brighton maybe we could start a London D User Group (LonDUG). >> > SkillsMatter would host. >> > >> >> And I say Hello! from sunny Brighton. > > Aha the Brighton dwelling D user of note ;-) > > I have lived in Brighton, but it was a long time ago, it is probably > very different now. No West Pier for a start! > I live literally 400 yards away from the burnt down west pier. Its a beautiful sight in the morning, come sun, rain, or fog. I hear they are building a 100 metre high elevator-to-nowhere in its place. Sad times... >> I do believe there are a few people around the London area who either >> have worked in, work in, or have a vested interest in D. I'll give >> Dejan a poke and find out some more numbers. > > We could start a code dojo to build up an initial activity and then > spawn off public meetings with tutorial style material to attract people > new to D. "D for C++ programmers", "D for C programmers", "D for Python > programmers", "D for JavaScript kiddies",… > > We might initially draw on the ACCU London people to gauge interest. > I can give you my details, and can see where things go from there. Regards Iain.
Re: Using D
On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via Digitalmars-d wrote: In the end it is about community rather than the programming language per se. Java created a huge community that was evangelical. Go has rapidly created an active community that is evangelical. Python has rapidly created a large evangelical community. D has slowly created a small community that hasn't as yet created the outward looking evangelical aspect. Where are the user groups having local meetings is my main metric. Java definitely, Go definitely, C++ sort of, D no. This is the real problem for D I feel. Without local user groups meeting up you don't get exposure and you don't get traction in the market. This seems like an outdated way of looking at things. I've never attended a user group in my life, yet I've picked up several technologies since I left college a while back. When I found out that such user groups existed, I thought they were kind of quaint, a remnant of pre-internet times. As for an evangelical community, did C and C++ have those? I don't think anyone was ever really evangelical about Obj-C as it took off over the last couple years, riding on the coattails of the meteoric rise of iOS. Evangelism can help, but it can be more a sign of the evangelist's enthusiasm than a tech worth using. Maybe D isn't ready for evangelism yet, there's something to be said for getting the product in gear before advertising it. Not saying there's anything wrong with DUGs, higher bandwidth interaction and all, but the current approach of D developers giving talks at outside gatherings or putting DConf talks online seems like a much better way to spread the gospel to me. Certainly both can be done, I just wouldn't use DUGs as the main metric. I've said it a couple times before, but it bears repeating: what D needs is a killer app. Rails showed the ease of use of ruby. iOS made Obj-C a star. D needs to show its utility by spawning a similar killer app, that's what will prove its worth in the market. We can't know what that will be, but if D is any good, it will probably happen at some point.
Re: Using D
.On 12 July 2014 20:55, Joakim via Digitalmars-d wrote: > On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via Digitalmars-d > wrote: >> >> In the end it is about community rather than the programming language >> per se. Java created a huge community that was evangelical. Go has >> rapidly created an active community that is evangelical. Python has >> rapidly created a large evangelical community. D has slowly created a >> small community that hasn't as yet created the outward looking >> evangelical aspect. Where are the user groups having local meetings is >> my main metric. Java definitely, Go definitely, C++ sort of, D no. This >> is the real problem for D I feel. Without local user groups meeting up >> you don't get exposure and you don't get traction in the market. > > > This seems like an outdated way of looking at things. I've never attended a > user group in my life, yet I've picked up several technologies since I left > college a while back. When I found out that such user groups existed, I > thought they were kind of quaint, a remnant of pre-internet times. > > As for an evangelical community, did C and C++ have those? I don't think > anyone was ever really evangelical about Obj-C as it took off over the last > couple years, riding on the coattails of the meteoric rise of iOS. > Evangelism can help, but it can be more a sign of the evangelist's > enthusiasm than a tech worth using. Maybe D isn't ready for evangelism yet, > there's something to be said for getting the product in gear before > advertising it. > > Not saying there's anything wrong with DUGs, higher bandwidth interaction > and all, but the current approach of D developers giving talks at outside > gatherings or putting DConf talks online seems like a much better way to > spread the gospel to me. Certainly both can be done, I just wouldn't use > DUGs as the main metric. > We are social creatures, and the fact is that people just get more done when they are in a room together. The beer probably helps more in agreeing also. ;-) > I've said it a couple times before, but it bears repeating: what D needs is > a killer app. Rails showed the ease of use of ruby. iOS made Obj-C a star. > D needs to show its utility by spawning a similar killer app, that's what > will prove its worth in the market. We can't know what that will be, but if > D is any good, it will probably happen at some point. Killer... app... ugh, how evangelical.
Re: Using D
On 2014-07-12 05:59, Rikki Cattermole wrote:
Something I've been thinking about is an overload for with statement.
E.g.
with(new MyAllocator) {
void*[256] values;
//...
}
class MyAllocator : IGC {
private {
IGC prevGC;
}
void opWithIn() {
this.prevGC = GC.getImpl();
GC.setImpl(this);
}
void opWithOut() {
GC.setImpl(this.prevGC);
}
}
Or without language changes:
void withAllocator (alias allocator, alias block)
{
auto prevGC = GC.getImpl();
scope(exit)
GC.setImpl(this.prevGC);
GC.setImpl(allocator);
block();
}
withAllocator!(new Allocator, {
void*[256] values;
});
Not as nice syntax though. That could of course be fixed with AST macros
[1] :)
[1] http://wiki.dlang.org/DIP50#Statement_Macros
--
/Jacob Carlborg
Re: Using D
On 13/07/2014 11:50 p.m., Jacob Carlborg wrote:
On 2014-07-12 05:59, Rikki Cattermole wrote:
Something I've been thinking about is an overload for with statement.
E.g.
with(new MyAllocator) {
void*[256] values;
//...
}
class MyAllocator : IGC {
private {
IGC prevGC;
}
void opWithIn() {
this.prevGC = GC.getImpl();
GC.setImpl(this);
}
void opWithOut() {
GC.setImpl(this.prevGC);
}
}
Or without language changes:
void withAllocator (alias allocator, alias block)
{
auto prevGC = GC.getImpl();
scope(exit)
GC.setImpl(this.prevGC);
GC.setImpl(allocator);
block();
}
withAllocator!(new Allocator, {
void*[256] values;
});
Not as nice syntax though. That could of course be fixed with AST macros
[1] :)
[1] http://wiki.dlang.org/DIP50#Statement_Macros
Definitely, but there is a rather big difference in requirements to
implement them ;)
But in saying this, we might be able to move the with statement into
druntime via AST macros. Should it have the ability to modify the this
context like with statement does now.
Re: Using D
On 2014-07-13 14:01, Rikki Cattermole wrote: Definitely, but there is a rather big difference in requirements to implement them ;) But in saying this, we might be able to move the with statement into druntime via AST macros. Should it have the ability to modify the this context like with statement does now. Yeah, there are many features that could have been implemented as macros instead of in the language, if D had had them from the beginning. -- /Jacob Carlborg
Re: Using D
On Sunday, 13 July 2014 at 12:21:13 UTC, Jacob Carlborg wrote: Yeah, there are many features that could have been implemented as macros instead of in the language, if D had had them from the beginning. What's the status of that DIP? What's the process by which something like that would even get added to D? I very much like the idea. Static metaprogramming and powerful compile time capabilities are the killer features of D, so strengthening them further seems worthwhile.
Re: Using D
On Sunday, 13 July 2014 at 16:32:15 UTC, Brian Rogoff wrote: On Sunday, 13 July 2014 at 12:21:13 UTC, Jacob Carlborg wrote: Yeah, there are many features that could have been implemented as macros instead of in the language, if D had had them from the beginning. What's the status of that DIP? It exists, pretty much all. No proof of concept implementation and no official approval so far. Community discussion was not really active either - most likely because it does not seem very realistic to expect it implemented. What's the process by which something like that would even get added to D? Usually it comes to providing DMD pull request that implements the DIP and than convincing Walter/Andrei it is worth merging. Most likely change will still be rejected but without PR chances are close zero.
Re: Using D
On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via Digitalmars-d wrote: On Fri, 2014-07-11 at 16:54 +, Chris via Digitalmars-d wrote: […] I remember Java used to be "th" best thing ever. After years of using it, however, I found out how restricted the language was / is. Still, it's been a success, because people believed all the propaganda. What matters to me is not so much the odd fancy feature, it's how well the language performs in general purpose programming. Go was designed for servers and thus will always have one up on D or any other language at that matter. But could I use Go for what I have used D? Not so sure about that. Also, like Java Go is a closed thing. D isn't. Once I read about D that it shows what can be done "once you take a language out of the hands of a committee". Go, like Java, will finally end up in a cul de sac and will have a hard time trying to get out of it. Not because the language is inherently bad, because it's in the hand of a committee. Ideology kills a language. But it doesn't matter, because people will use Go or whatever anyway, will _have_ to use it. People believed the FORTRAN propaganda, the COBOL propaganda, the Pascal propaganda. I think we ought to distinguish good marketing from hype. Java had good marketing, was in the right place at the right time, and had a huge amount of hype as well. If Go is better for server things than D then might as well stop trying to use D at all. Go was actually designed as a better C with CSP for concurrency and parallelism. Go, D, Rust, C++, C, Haskell,… are all just programming languages that create native code executable. Thus they are all in the same category regarding potential usage. Everything else is about whether the programmer likes and uses well, the language. If Go and Java are closed languages, so is D. All three have open source repositories and people can submit changes via pull requests. All three have committees comprising the people who have commit rights to the mainline and they are the only people who can actually change the language. But D is much more open to discussion and features are implemented faster, as far as I see. If I think about Java, that it took them ages to implement useful features like enumerations. Go ruled out templates, if I remember correctly. It's this kind of ideological / dictatorial attitude I don't like. Of course, Walter has the veto of death, it's his child after all. But there is far more flexibility. In the D community people listen to each other and trust each other's judgements and user experiences (or we wisely shut up, if they have no expertise on a certain topic). I think I have to repeat the point about irony here regarding ideology :-) What I'm taking issue with is that everybody focuses on the flaws of D (every language has flaws), which often gives the impression that it's an unfinished, stay-away business. It's not. D can be used, and I've used it, for production code. It's more mature than D or Rust and it is superior to other languages like Java (no OO-ideology for example). Mind you, D is a hindsight language, which makes it wiser. Does it have flaws? Yes. I come across them sometimes. Is there a language without flaws? If there is, tell me about it. Talking about hindsight, I've tried many different languages, I like D because of what it has to offer for general purpose programming, it compiles natively, interfaces with C at no cost at all, it has strong modelling power, features that users require are added. I may sound like a zealot (see "irony"), but I'm not. I'm very pragmatic, D is a good tool and, being community driven, there is a real chance of making it a fantastic tool. Individual features are not everything. Go folk have exactly the same view and argument regarding Go. Java folk have exactly the same view and argument regarding Java – well except for the compiles to native code bit, obviously. ;-) In the end it is about community rather than the programming language per se. Java created a huge community that was evangelical. Go has rapidly created an active community that is evangelical. Python has rapidly created a large evangelical community. D has slowly created a small community that hasn't as yet created the outward looking evangelical aspect. Where are the user groups having local meetings is my main metric. Java definitely, Go definitely, C++ sort of, D no. This is the real problem for D I feel. Without local user groups meeting up you don't get exposure and you don't get traction in the market. [snip] You are right of course, but that was not my point at all. My point was that we have to stop the constant D-bashing. One flaw (or perceived flaw) is blown out of proportion and used to discard the language as useless, which it is not. What H.S. Teoh described is true, you can start with script like stuff in D and it scales later. I've been doin
Re: Using D
On 7/13/14, 9:42 AM, Dicebot wrote: On Sunday, 13 July 2014 at 16:32:15 UTC, Brian Rogoff wrote: On Sunday, 13 July 2014 at 12:21:13 UTC, Jacob Carlborg wrote: Yeah, there are many features that could have been implemented as macros instead of in the language, if D had had them from the beginning. What's the status of that DIP? It exists, pretty much all. No proof of concept implementation and no official approval so far. Community discussion was not really active either - most likely because it does not seem very realistic to expect it implemented. What's the process by which something like that would even get added to D? Usually it comes to providing DMD pull request that implements the DIP and than convincing Walter/Andrei it is worth merging. Most likely change will still be rejected but without PR chances are close zero. I'm not sure about that. The main problem with most of the current DIPs is quality. There seems to be an implied expectation that once a DIP follows the format guidelines and has reasonable content, it's implied that it should receive some sort of official review. We don't have the resources to do that. What can be expected is that a DIP should be worked at for a while by its champion(s) along with the community until it's to a high standard and generally strong (preferably with a proof-of-concept implementation in tow). Andrei
Re: Using D
On Monday, 14 July 2014 at 10:13:43 UTC, Chris wrote: On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via 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!" 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
Re: Using D
Am 16.07.2014 17:39, schrieb Vic:
On Monday, 14 July 2014 at 10:13:43 UTC, Chris wrote:
On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via
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!"
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
Re: Using D
On Wednesday, 16 July 2014 at 17:18:11 UTC, Paulo Pinto wrote:
Apple is stating that Swift is a C replacement ("Swift is a
successor to the C and Objective-C languages." -
https://developer.apple.com/swift/).
"Swift is an innovative new programming language for Cocoa and
Cocoa Touch." and "Swift is a successor to the C and Objective-C
languages. It includes low-level primitives such as types, flow
control, and operators." Yes, that's low level!
Swift is Objective-C in a new dress, but not a system level
programming language (and neither is Objective-C IMHO). It is an
application level language for Cocoa frameworks.
Re: Using D
Am 16.07.2014 21:26, schrieb "Ola Fosheim Grøstad"
":
On Wednesday, 16 July 2014 at 17:18:11 UTC, Paulo Pinto wrote:
Apple is stating that Swift is a C replacement ("Swift is a successor
to the C and Objective-C languages." -
https://developer.apple.com/swift/).
"Swift is an innovative new programming language for Cocoa and Cocoa
Touch." and "Swift is a successor to the C and Objective-C languages. It
includes low-level primitives such as types, flow control, and
operators." Yes, that's low level!
Swift is Objective-C in a new dress, but not a system level programming
language (and neither is Objective-C IMHO). It is an application level
language for Cocoa frameworks.
Just like ANSI C without the usual set of language extensions.
Having done system programming in Turbo Pascal and Oberon, I guess I
don't seek C like features in system programming languages.
--
Paulo
Re: Using D
On Friday, 11 July 2014 at 19:46:25 UTC, Walter Bright wrote: 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
Re: Using D
"Vic" wrote in message news:xblbppsybigjgrtgi...@forum.dlang.org... Hi Walter, Please give us a bit more respect and benefit of the doubt and assume that we do know what we want when say something. I want to use D! I may be forced to C++ my team because GC built into the base lib. It is possible to build a base lib w/o GC I just am in a small company and can't afford to do that. Cheers, Vic Walter is just one guy, what makes you think he can afford to re-write the standard library for you?
Re: Using D
Am Sat, 12 Jul 2014 11:38:08 +0100 schrieb Russel Winder 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. -- Marco signature.asc Description: PGP signature
Re: Using D
On Monday, 25 August 2014 at 07:47:45 UTC, Marco Leise wrote: Am Sat, 12 Jul 2014 11:38:08 +0100 schrieb Russel Winder via Digitalmars-d : > 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.
Re: Using D
On Mon, 2014-08-25 at 09:01 +, Chris via Digitalmars-d wrote: […] > The main thing that put me off Java was not so much the fact that > you're restricted to OOP and that it's verbose etc., but that it > caused all sorts of problems when shipping the actual programs. > "Write once run everywhere" is a myth, if you ask me. D is much > closer to that than Java. In the end we encountered so many > problems that I dumped Java for cross platform development (and > for development in general). Nobody in the Java world ever talks > about this, but cross platform doesn't really work (apart from > running simple programs). […] Java is not really an object-oriented programming language. OK it has classes, inheritance, and method calls, but it is not founded on message passing. For example: a + b is not a message in Java as it is in C++, Python, etc. 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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Using D
On Mon, 2014-08-25 at 09:55 +0200, Marco Leise via Digitalmars-d wrote: […] > Yes, Java is verbose, but its modularity makes it very > flexible. The classic example is how you read lines of text > from a file. Instead of a special class for that, you take > use simple primitives with descriptive names and assemble > something that reads lines of UTF-8 text from a buffer that > has a file as its input. It actually acknowledges quite a bit > of real-world mess when you look at it, for example different > encodings on stdin and stdout. Groovy makes it even easier. I avoid using Java if I can use Groovy, which is about 100% of the time now with @CompileStatic. > Conventions like beans, where every property is implemented as > a pair of getter/setter or naming rules like ...Adapter, The Bean Protocol is about the worst offence committed by the Java Platform. It destroys encapsulation and any thought of object-oriented programming. > ...Comparator make it easy to reflect on unknown code. Java reflection is really a bit of a mess. Another reason for using Groovy it makes working with the JVM reflection system much easier. > On the one hand it is limiting to only have Java OOP in the > toolbox, on the other hand it is cheap to train someone on > Java and Java libraries and actually not a horror to try and > make sense of other people's code, because it wont be > implemented in any of 5 different paradigms + s.o.'s personal > naming conventions. Java "OOP" isn't really OOP. > I've never been a fan of developing in vi or emacs and as far > as I am concerned, a programming language need not be designed > like a human language. There are many graphical programming > environments as well, for example for physics. Emacs is the One True Editor, not using it is clearly a declaration of war :-) > The simpler the language the more robust the refactoring tools > can become. The more conventions are in use, the better custom > tailored tools and IDEs can emerge. I.e. in Eclipse you only > type the capital letters of a long class name and have the > auto-completion figure out which class in scope or available > import paths matches these "initials". Heck, it even fills in > the parameters when you call a method using the available > variables in scope. If you were unaware that you need a third > argument, the IDE can generate a new variable with a name > based on the method parameter or place a constructor call for > the required type. > Sometimes you can just focus on the program logic and have the > IDE generate most of the code. Delphi's and C# IDEs similarly > expose properties of GUI objects in tables and generate the > code for event handlers on double-clicks. It saves time, you > cannot misspell anything... I like it. I switch between Emacs, Vi, Eclipse, IntelliJ IDEA, PyCharm, Wing IDE, depending on programming language and activity. None of the tools work for all situations. It would be nice if they did, but there is always something wrong for a given activity. IDE popups can be a useful tool, the problem with over-reliance, particularly for the weaker programmers is that they create code they do not understand. In the Eclipse/Java context, I see far too much in the way of "form filling of template" type programming by people who are working under the impression that because they are using a template nothing can go wrong. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Using D
On 08/25/2014 12:53 PM, Russel Winder via Digitalmars-d wrote:
For example:
a + b
is not a message in Java as it is in C++, ...
error: member reference base type 'int' is not a structure or union
int main(){ (1).operator+(2); }
~~~^
Re: Using D
On 25.08.2014 10:55, Marco Leise wrote: Am Sat, 12 Jul 2014 11:38:08 +0100 schrieb Russel Winder 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
Re: Using D
On 25.08.2014 13:53, Russel Winder via Digitalmars-d wrote: On Mon, 2014-08-25 at 09:01 +, Chris via Digitalmars-d wrote: […] The main thing that put me off Java was not so much the fact that you're restricted to OOP and that it's verbose etc., but that it caused all sorts of problems when shipping the actual programs. "Write once run everywhere" is a myth, if you ask me. D is much closer to that than Java. In the end we encountered so many problems that I dumped Java for cross platform development (and for development in general). Nobody in the Java world ever talks about this, but cross platform doesn't really work (apart from running simple programs). […] Java is not really an object-oriented programming language. OK it has classes, inheritance, and method calls, but it is not founded on message passing. For example: a + b is not a message in Java as it is in C++, Python, etc. Since when does C++ does support message passing? Write Once Run Anywhere (WORA) has been a known fallacy since about 1995 ;-) Versions of things really are a bit of a dependency/configuration nightmare. Maven Central and Gradle help somewhat for the JVM, but then there is the shared library nightmare for all other platforms. It is surely way better than the alternatives, specially if one remembers the chaos of writing portable code in C or C++ back when Java apperead. On those days I was writing "portable" code across UNIX systems and discovering that POSIX isn't as portable as it gets sold by. The real fun was between the K&R C, ANSI C and pre-standard C++ support across compilers. -- Paulo
Re: Using D
On Monday, 25 August 2014 at 13:51:25 UTC, Paulo Pinto wrote: It is surely way better than the alternatives, specially if one remembers the chaos of writing portable code in C or C++ back when Java apperead. Yeah, Flash and javascript are the kings of portable programming. Then you have the scripting languages (python,perl,tcl/tk…). Then you have Java. Then you have Qt, etc Compiled languages come far down on the list. HTML5 will remain the king I believe, since OS upgrades can nuke any compiled program and HTML5 capable browsers are distributed with the OS.
Re: Using D
On Mon, 25 Aug 2014 16:51:23 +0300 Paulo Pinto via Digitalmars-d wrote: > Since when does C++ does support message passing? since people started to think that "OOP was invented in C++". signature.asc Description: PGP signature
Re: Using D
On Monday, 25 August 2014 at 14:05:35 UTC, ketmar via Digitalmars-d wrote: On Mon, 25 Aug 2014 16:51:23 +0300 Paulo Pinto via Digitalmars-d wrote: Since when does C++ does support message passing? since people started to think that "OOP was invented in C++". The terminology "message" for "method" comes from Smalltalk. It is used liberally. C++ is using the OOP model of SIMULA, which did invent OOP! So I'd say the way C++ does OOP is how it was invented. SIMULA was created by Kristen Nygaard and Ole-Johan Dahl. Nygaard was very much interested in object-oriented modelling and as a mode of thinking about problems. Not only in programming. Dahl went on to work on formal program verification. I had them as lecturers at the university. Very interesting people.
Re: Using D
On Mon, 25 Aug 2014 14:15:09 + via Digitalmars-d wrote: > C++ is using the OOP model of SIMULA, which did invent OOP! So > I'd say the way C++ does OOP is how it was invented. and Smalltalk does OOP the way it should be done. ;-) signature.asc Description: PGP signature
Re: Using D
On Monday, 25 August 2014 at 14:27:55 UTC, ketmar via Digitalmars-d wrote: On Mon, 25 Aug 2014 14:15:09 + via Digitalmars-d wrote: C++ is using the OOP model of SIMULA, which did invent OOP! So I'd say the way C++ does OOP is how it was invented. and Smalltalk does OOP the way it should be done. ;-) I haven't used Smalltalk, but can't say it looks pretty… But I probably shouldn't judge by looks, it is the personality that counts! The SIMULA model was later refined in Beta which was minimalistic in the same vein as Self. In Beta everything is an object, even functions and blocks (which could be specialized). And virtual functions are evaluated from superclasses down to subclasses so that the superclass is encapsulating the subclass in a similar way to how the "with" statement works. Beta had virtual class definitions and type variables so that you could let a subclass specialize the types that was instantiated in the superclass in a subclass. D does seem to lack type variables? So it is quite static in comparison.
Re: Using D
On Mon, 25 Aug 2014 14:41:46 + via Digitalmars-d wrote: > D does seem to lack type variables? So it is quite static in > comparison. the problem with "overly dynamic" languages like Smalltalk (and especially Self) is that it's insanely hard to write an efficient compiler which generates fast machine code. JIT compilation, polymorphic inline caching and alot of other techniques allows this languages to work with "acceptable speed", but primitive C compiler with peephole optimizer can beat 'em easily. D is aimed to generate efficient machine code, so it must be "static". we can emulate dynamic calls with AA and opDispatch, but this will be... not fast. ;-) signature.asc Description: PGP signature
Re: Using D
On Monday, 25 August 2014 at 14:54:33 UTC, ketmar via Digitalmars-d wrote: D is aimed to generate efficient machine code, so it must be "static". we can emulate dynamic calls with AA and opDispatch, but this will be... not fast. ;-) Beta was static and compiled directly to asm. That does not preclude dynamism such as type variables, hidden parent pointers (where the object instanced from) and a rich set of virtual bindings and the ability to specialize everwhere. Examples: - a type variable is essentially just a pointer to a typeinfo-block with constructors and meta information. - a virtual type specification is just a type variable that is constrained to a class hierarchy. - to have specialization everywhere you just add the capability to have unnamed types Ola
Re: Using D
On Mon, 25 Aug 2014 16:08:52 + via Digitalmars-d wrote: > Beta was static and compiled directly to asm. it's not hard to compile dynamic language to native code. what is hard is to make this code fast. this requires very sofisticated compiler which can eliminate as much indirect calls as possible. that's why we have the ability to create non-virtual methods in languages like D or C++. "everything is object" is a nice concept, but it has it's price. signature.asc Description: PGP signature
Re: Using D
On Monday, 25 August 2014 at 16:26:19 UTC, ketmar via Digitalmars-d wrote: is to make this code fast. this requires very sofisticated compiler which can eliminate as much indirect calls as possible. that's why we have the ability to create non-virtual methods in languages like D or C++. "everything is object" is a nice concept, but it has it's price. You need whole program analysis to get the most out of it. Just about everything can be replaced by LUTs or switches. If you look at real code very little of the kind of dynamic programs you write in languages like Python and Ruby actually are dynamic in nature. Sure, there are examples of the opposite, but I think that is more in the line of "eclectic programming" than "useful programming". I think the whole separate compilation idea is going to be old fashioned real soon now. It makes little sense to not have the build system as a service run on a cluster and the program as a database with builtin versioning. Why recompile the whole file when only a tiny function should be according to the dependencies?
Re: Using D
On 8/25/14, 1:26 PM, ketmar via Digitalmars-d wrote: On Mon, 25 Aug 2014 16:08:52 + via Digitalmars-d wrote: Beta was static and compiled directly to asm. it's not hard to compile dynamic language to native code. what is hard is to make this code fast. this requires very sofisticated compiler which can eliminate as much indirect calls as possible. that's why we have the ability to create non-virtual methods in languages like D or C++. "everything is object" is a nice concept, but it has it's price. Not at all. In Crystal everything is an object, it compiles to native code and it's super fast. All methods are virtual (and there's actually no way to make a method non-virtual). The trick is to not use virtual tables, but do multiple dispatch (or only use virtual tables when needed). If you have: a = Foo.new a.some_method then it's obvious to the compiler that some_method belongs to Foo: no virtual call involved, no virtual table lookup, etc: just a direct call. If you have: x = 1.abs 1 is still an object, only it's memory representation is 32 bits, and the method turns out to be just like a function call. To me, the real problem with OOP is to automatically relate it to virtual tables, interfaces, etc.
Re: Using D
On Monday, 25 August 2014 at 14:41:48 UTC, Ola Fosheim Grøstad wrote: On Monday, 25 August 2014 at 14:27:55 UTC, ketmar via Digitalmars-d wrote: On Mon, 25 Aug 2014 14:15:09 + via Digitalmars-d wrote: C++ is using the OOP model of SIMULA, which did invent OOP! So I'd say the way C++ does OOP is how it was invented. and Smalltalk does OOP the way it should be done. ;-) I haven't used Smalltalk, but can't say it looks pretty… But I probably shouldn't judge by looks, it is the personality that counts! Smalltalk is great, specially as operating system. I used SmalltalkWorks, before Java was concieved. It was the closest I ever been of the Xerox PARC OS experience. The UNIX CLI experience is nothing, compared to the possibility to touch the whole system and use any public class/method on your scripts (transcript). My second experience with such enviroments was with Oberon, Wirth based his work on Mesa/Cedar. Imagine just having dynamic loadable modules as executables. All exported functions could be used in the REPL, applied to OS widgets or user selections, depending on the signature. -- Paulo
Re: Using D
On Monday, 25 August 2014 at 14:54:33 UTC, ketmar via Digitalmars-d wrote: On Mon, 25 Aug 2014 14:41:46 + via Digitalmars-d wrote: D does seem to lack type variables? So it is quite static in comparison. the problem with "overly dynamic" languages like Smalltalk (and especially Self) is that it's insanely hard to write an efficient compiler which generates fast machine code. JIT compilation, polymorphic inline caching and alot of other techniques allows this languages to work with "acceptable speed", but primitive C compiler with peephole optimizer can beat 'em easily. D is aimed to generate efficient machine code, so it must be "static". we can emulate dynamic calls with AA and opDispatch, but this will be... not fast. ;-) May be, but JIT were created thanks to Lisp and Smalltalk. In Smalltalk's case, the genesis to Java Hotspot JIT, lies in this paper, http://dl.acm.org/citation.cfm?id=894616 -- Paulo
Re: Using D
On Mon, 25 Aug 2014 16:33:00 + via Digitalmars-d wrote: > I think the whole separate compilation idea is going to be old > fashioned real soon now. It makes little sense to not have the > build system as a service run on a cluster and the program as a > database with builtin versioning. but i don't want to buy and setup 42 servers in my room just to compile "hello world"! ;-) and no, i will not buy all that modern BS about "clouds". > 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. signature.asc Description: PGP signature
Re: Using D
On Mon, 25 Aug 2014 14:36:21 -0300 Ary Borenszweig via Digitalmars-d wrote: > 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 such simple code analysis easily confused by function calls. or we have to analyse function body at each call and instantiate parameterised functions. ah, hello, interprocedural analysis. and what if function is in another module? ah, hello, full program analysis. and bye-bye, compilation speed. > To me, the real problem with OOP is to automatically relate it to > virtual tables, interfaces, etc. i myself thinking about message passing when i see OOP mentioned. ;-) signature.asc Description: PGP signature
Re: Using D
On Mon, 25 Aug 2014 17:50:35 + Paulo Pinto via Digitalmars-d wrote: > May be, but JIT were created thanks to Lisp and Smalltalk. i know that. i'm interested in JIT developement and know about Self, Strongtalk and other strange words. ;-) and i really hate SUN for practically killing Strongtalk. Java sux and Strongtalk is dead. loose-loose. signature.asc Description: PGP signature
Re: Using D
On 8/25/2014 2:01 AM, Chris wrote: The main thing that put me off Java was not so much the fact that you're restricted to OOP and that it's verbose etc., but that it caused all sorts of problems when shipping the actual programs. "Write once run everywhere" is a myth, if you ask me. D is much closer to that than Java. In the end we encountered so many problems that I dumped Java for cross platform development (and for development in general). Nobody in the Java world ever talks about this, but cross platform doesn't really work (apart from running simple programs). I haven't ported much Java code, but I have found D code to be significantly easier to port than C++. The varying sizes of basic types in C++ is what causes most of the problems.
Re: Using D
On Tuesday, 26 August 2014 at 04:03:17 UTC, ketmar via Digitalmars-d wrote: On Mon, 25 Aug 2014 16:33:00 + via Digitalmars-d wrote: I think the whole separate compilation idea is going to be old fashioned real soon now. It makes little sense to not have the build system as a service run on a cluster and the program as a database with builtin versioning. but i don't want to buy and setup 42 servers in my room just to compile "hello world"! ;-) You won't, your single home computer will be enough for small programs. But if your code ever grows large enough to benefit from a cluster, you'll just sign up for an account online and you tools will automatically start sending your diffs to the remote cluster and compiling the code there. and no, i will not buy all that modern BS about "clouds". It is amazing that the "cloud" is being applied to a host of problems, but not really to speed up building software yet. Of course, there's a bunch of giant corporations, like Facebook or Google, putting their own private "clouds" to such uses, but the vast majority of programmers just use a powerful workstation instead, the old '80s model of software development. That will change. It's not that you can't roll your own and do it on AWS right now, it just isn't dead simple to do it off the shelf, so most don't. And of course test runs have been increasingly pushed into these remote clusters. Other than a few devs with privacy and security concerns, most will move to such a "cloud" model in the coming years.
Re: Using D
On Tue, 26 Aug 2014 05:59:45 + Joakim via Digitalmars-d wrote: > Other than a few devs with privacy and security concerns it's about me. ;-) signature.asc Description: PGP signature
Re: Using D
On Tuesday, 26 August 2014 at 05:58:36 UTC, Walter Bright wrote: On 8/25/2014 2:01 AM, Chris wrote: The main thing that put me off Java was not so much the fact that you're restricted to OOP and that it's verbose etc., but that it caused all sorts of problems when shipping the actual programs. "Write once run everywhere" is a myth, if you ask me. D is much closer to that than Java. In the end we encountered so many problems that I dumped Java for cross platform development (and for development in general). Nobody in the Java world ever talks about this, but cross platform doesn't really work (apart from running simple programs). I haven't ported much Java code, but I have found D code to be significantly easier to port than C++. The varying sizes of basic types in C++ is what causes most of the problems. The problem was that Java didn't behave as expected on Windows. Things that worked fine on Linux and OS X didn't work on Windows (even simple things like deleting files). User reported all sorts of problems, one of them being that the Java Access Bridge didn't work. Why, nobody knows. The lack of a proper sound API / library. Then there was the versioning hell with JRE/JVM and having to tell users what version they had to download (the non tech savvy crowd). I know that MS doesn't make it easy for Java either. Well, I could have sorted the problems out with Java web start, SWT and all that kind of stuff. Instead, I learned D which I can compile and run on each platform without a problem. In my opinion, if a technology like Java needs so many crutches to make it work on different platforms, then it's useless for cross-platform development. Also, once you need interaction with the system or other (native) applications, then it becomes frustrating pretty soon. D solved all these problems for me and more, in fact it helped me to design a better product, because it opened doors for me as regards both programming patterns and interaction with the system and various libraries. That there are other languages with which I could have achieved similar things, I do not doubt. But I do doubt that it would have been so easy, and the fact that new languages that aim for what D already stands for are still being invented (cf. Nimrod) shows that existing mainstream technologies like Java, C++, C# don't meet programmers' demands yet.
Re: Using D
On 26/08/2014 09:46, Chris wrote: The problem was that Java didn't behave as expected on Windows. Things that worked fine on Linux and OS X didn't work on Windows (even simple things like deleting files). User reported all sorts of problems, one of them being that the Java Access Bridge didn't work. Why, nobody knows. The lack of a proper sound API / library. Then there was the versioning hell with JRE/JVM and having to tell users what version they had to download (the non tech savvy crowd). I know that MS doesn't make it easy for Java either. Well, I could have sorted the problems out with Java web start, SWT and all that kind of stuff. Instead, I learned D which I can compile and run on each platform without a problem. The promise of "Write once run everywhere" is still pretty much accurate if you stick to core Java code and libraries. Of course once you start using OS/implementation specific code you will have to code more carefully, and are more likely to encounter cross-platform problems. That's just the nature of things, you can't say it's a failure of Java. It's like coding in D using lots of malloc/free in your code, and then when your program breaks, you complain that "the D GC doesn't work!". Of course the GC only is only guaranteed to work if you stick to GC-managed memory. To be honest I smell a load of Java-biased *BS* here, especially because of this sentence: "Instead, I learned D which I can compile and run on each platform without a problem." Actually virtually all other languages, including D, are just as bad as Java (if not worse) in the aspects mentioned above. For example, if you write code which heavily interacts with the filesystem, you are bound to encounter platform/OS-specific problems no matter what language. I'd bet money those "even simple things like deleting files", you'd have in D as well. At least in Java the APIs they are usually careful to specify which aspects of behavior are implementation-specific. In other cases, such as the sound library or accessibility library, most other cross-platform language don't even have those!, so how can you be saying that D runs better on each platform that Java?.. (Does a non-existent library run perfectly on every conceivable platform? one could say yes...) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Using D
On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno Medeiros wrote: On 26/08/2014 09:46, Chris wrote: The problem was that Java didn't behave as expected on Windows. Things that worked fine on Linux and OS X didn't work on Windows (even simple things like deleting files). User reported all sorts of problems, one of them being that the Java Access Bridge didn't work. Why, nobody knows. The lack of a proper sound API / library. Then there was the versioning hell with JRE/JVM and having to tell users what version they had to download (the non tech savvy crowd). I know that MS doesn't make it easy for Java either. Well, I could have sorted the problems out with Java web start, SWT and all that kind of stuff. Instead, I learned D which I can compile and run on each platform without a problem. The promise of "Write once run everywhere" is still pretty much accurate if you stick to core Java code and libraries. Of course once you start using OS/implementation specific code you will have to code more carefully, and are more likely to encounter cross-platform problems. That's just the nature of things, you can't say it's a failure of Java. It's like coding in D using lots of malloc/free in your code, and then when your program breaks, you complain that "the D GC doesn't work!". Of course the GC only is only guaranteed to work if you stick to GC-managed memory. I can expect the Java Access Bridge to work, because Java offers it as a built-in technology. If it does not work, it's a broken promise. Simple as that. To be honest I smell a load of Java-biased *BS* here, especially because of this sentence: "Instead, I learned D which I can compile and run on each platform without a problem." Which is true. I could compile it on Linux, OS X and Windows. It was almost trivial to write a DLL that third party software can use. Try that with Java and tell me if it's trivially easy. I think what you meant was _anti_-Java *BS*. I'm only writing about my experience with the two languages. The one worked for me, the other didn't. Actually virtually all other languages, including D, are just as bad as Java (if not worse) in the aspects mentioned above. For example, if you write code which heavily interacts with the filesystem, you are bound to encounter platform/OS-specific problems no matter what language. I'd bet money those "even simple things like deleting files", you'd have in D as well. At least in Java the APIs they are usually careful to specify which aspects of behavior are implementation-specific. Well, my statement refered to the fact that Java f**ked up big time there, which clearly breaks the promise "write once, run everywhere", especially because dealing with files is a feature one would expect to be part and parcel of a programming language. Deleting files should not give you a headache. Basically what you're saying is "Java is cross-platform but it's not, but hey, other languages are just as bad!". Well, then they should stop using the word "cross-platform" when advertising their language. In other cases, such as the sound library or accessibility library, most other cross-platform language don't even have those!, so how can you be saying that D runs better on each platform that Java?.. (Does a non-existent library run perfectly on every conceivable platform? one could say yes...) D interfaces to existing audio / sound libraries in C (libsndfile, portaudio). All you have to do is to include those libs and call the functions you need. Doing this with Java is a bit more complicated (you'll probably need tools). You are welcome to report on any serious issues you've encountered when porting D programs to various platforms. Maybe it can be fixed in the core of the language and it would help to make D even more portable. A lot of cross-platform issues can be dealt with by including "version(Windows/Posix ...)" in your code.
Re: Using D
On 04/09/2014 16:21, Chris wrote: On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno Medeiros wrote: On 26/08/2014 09:46, Chris wrote: The problem was that Java didn't behave as expected on Windows. Things that worked fine on Linux and OS X didn't work on Windows (even simple things like deleting files). User reported all sorts of problems, one of them being that the Java Access Bridge didn't work. Why, nobody knows. The lack of a proper sound API / library. Then there was the versioning hell with JRE/JVM and having to tell users what version they had to download (the non tech savvy crowd). I know that MS doesn't make it easy for Java either. Well, I could have sorted the problems out with Java web start, SWT and all that kind of stuff. Instead, I learned D which I can compile and run on each platform without a problem. The promise of "Write once run everywhere" is still pretty much accurate if you stick to core Java code and libraries. Of course once you start using OS/implementation specific code you will have to code more carefully, and are more likely to encounter cross-platform problems. That's just the nature of things, you can't say it's a failure of Java. It's like coding in D using lots of malloc/free in your code, and then when your program breaks, you complain that "the D GC doesn't work!". Of course the GC only is only guaranteed to work if you stick to GC-managed memory. I can expect the Java Access Bridge to work, because Java offers it as a built-in technology. If it does not work, it's a broken promise. Simple as that. Does Java Access Bridge really not work, or you just didn't use it right? Or are you trying to use in for a purpose it's aimed to be used? Unfortunately, I'm not familiar with JAB, so I can't comment further on it.. To be honest I smell a load of Java-biased *BS* here, especially because of this sentence: "Instead, I learned D which I can compile and run on each platform without a problem." Which is true. I could compile it on Linux, OS X and Windows. It was almost trivial to write a DLL that third party software can use. Try that with Java and tell me if it's trivially easy. I think what you meant was _anti_-Java *BS*. I'm only writing about my experience with the two languages. The one worked for me, the other didn't. When you say DLL, do you mean a shared library in general, or really an actual Windows DLL? I'm assuming it's the former, otherwise that doesn't make sense. Well In Java you can create them quite easily: jars. They are trivial to be used by other Java programs! I don't see your point. Actually virtually all other languages, including D, are just as bad as Java (if not worse) in the aspects mentioned above. For example, if you write code which heavily interacts with the filesystem, you are bound to encounter platform/OS-specific problems no matter what language. I'd bet money those "even simple things like deleting files", you'd have in D as well. At least in Java the APIs they are usually careful to specify which aspects of behavior are implementation-specific. Well, my statement refered to the fact that Java f**ked up big time there, which clearly breaks the promise "write once, run everywhere", especially because dealing with files is a feature one would expect to be part and parcel of a programming language. Deleting files should not give you a headache. Basically what you're saying is "Java is cross-platform but it's not, but hey, other languages are just as bad!". Well, then they should stop using the word "cross-platform" when advertising their language. If the core of the language was "working with with filesystem", then yeah, they should not advertise it as cross-platform. But it's not the core of language (even if it's part of the standard library), it's just a minor library component, one amongst many (the vast majority of it being fully cross-platform). In other cases, such as the sound library or accessibility library, most other cross-platform language don't even have those!, so how can you be saying that D runs better on each platform that Java?.. (Does a non-existent library run perfectly on every conceivable platform? one could say yes...) D interfaces to existing audio / sound libraries in C (libsndfile, portaudio). All you have to do is to include those libs and call the functions you need. Doing this with Java is a bit more complicated (you'll probably need tools). You are welcome to report on any serious issues you've encountered when porting D programs to various platforms. Maybe it can be fixed in the core of the language and it would help to make D even more portable. A lot of cross-platform issues can be dealt with by including "version(Windows/Posix ...)" in your code. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Using D
On Friday, 5 September 2014 at 11:27:17 UTC, Bruno Medeiros wrote: On 04/09/2014 16:21, Chris wrote: On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno Medeiros wrote: On 26/08/2014 09:46, Chris wrote: The problem was that Java didn't behave as expected on Windows. Things that worked fine on Linux and OS X didn't work on Windows (even simple things like deleting files). User reported all sorts of problems, one of them being that the Java Access Bridge didn't work. Why, nobody knows. The lack of a proper sound API / library. Then there was the versioning hell with JRE/JVM and having to tell users what version they had to download (the non tech savvy crowd). I know that MS doesn't make it easy for Java either. Well, I could have sorted the problems out with Java web start, SWT and all that kind of stuff. Instead, I learned D which I can compile and run on each platform without a problem. The promise of "Write once run everywhere" is still pretty much accurate if you stick to core Java code and libraries. Of course once you start using OS/implementation specific code you will have to code more carefully, and are more likely to encounter cross-platform problems. That's just the nature of things, you can't say it's a failure of Java. It's like coding in D using lots of malloc/free in your code, and then when your program breaks, you complain that "the D GC doesn't work!". Of course the GC only is only guaranteed to work if you stick to GC-managed memory. I can expect the Java Access Bridge to work, because Java offers it as a built-in technology. If it does not work, it's a broken promise. Simple as that. Does Java Access Bridge really not work, or you just didn't use it right? Or are you trying to use in for a purpose it's aimed to be used? Unfortunately, I'm not familiar with JAB, so I can't comment further on it.. I used it with Swing. It was ignored by all the screen readers. To be honest I smell a load of Java-biased *BS* here, especially because of this sentence: "Instead, I learned D which I can compile and run on each platform without a problem." Which is true. I could compile it on Linux, OS X and Windows. It was almost trivial to write a DLL that third party software can use. Try that with Java and tell me if it's trivially easy. I think what you meant was _anti_-Java *BS*. I'm only writing about my experience with the two languages. The one worked for me, the other didn't. When you say DLL, do you mean a shared library in general, or really an actual Windows DLL? I'm assuming it's the former, otherwise that doesn't make sense. Well In Java you can create them quite easily: jars. They are trivial to be used by other Java programs! I don't see your point. I mean a DLL that can be loaded by say a Python program (as in my case) or any other software that wants to use my plug-in[1]. A jar can only be used by another Java program. Making a Java program accessible to 3rd party software via a DLL is not so simple, and the JVM has to be up and running all the time. Java is cross-platform as long as you stay within the safe and cosy Java bubble that floats on top of the JVM. But once you step outside of the JVM, gravity kicks in. Don't get me wrong. I like the concept of a VM. Only Java has been screwed up over the years by bad and wrong decisions, partly due to ideology and partly due to strategic / marketing decisions. It's a pity really. It started out as a very promising language but got caught under the wheels of corporate decisions and OOP evangelists. [1] Have a look at this. It was really just as simple: http://wiki.dlang.org/Win32_DLLs_in_D Actually virtually all other languages, including D, are just as bad as Java (if not worse) in the aspects mentioned above. For example, if you write code which heavily interacts with the filesystem, you are bound to encounter platform/OS-specific problems no matter what language. I'd bet money those "even simple things like deleting files", you'd have in D as well. At least in Java the APIs they are usually careful to specify which aspects of behavior are implementation-specific. Well, my statement refered to the fact that Java f**ked up big time there, which clearly breaks the promise "write once, run everywhere", especially because dealing with files is a feature one would expect to be part and parcel of a programming language. Deleting files should not give you a headache. Basically what you're saying is "Java is cross-platform but it's not, but hey, other languages are just as bad!". Well, then they should stop using the word "cross-platform" when advertising their language. If the core of the language was "working with with filesystem", then yeah, they should not advertise it as cross-platform. But it's not the core of language (even if it's part of the standard library), it's just a minor library component, one amongst many (the vast majority of it being f
Re: Using D
On Friday, 5 September 2014 at 13:42:56 UTC, Chris wrote: On Friday, 5 September 2014 at 11:27:17 UTC, Bruno Medeiros wrote: On 04/09/2014 16:21, Chris wrote: On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno Medeiros wrote: On 26/08/2014 09:46, Chris wrote: The problem was that Java didn't behave as expected on Windows. Things that worked fine on Linux and OS X didn't work on Windows (even simple things like deleting files). User reported all sorts of problems, one of them being that the Java Access Bridge didn't work. Why, nobody knows. The lack of a proper sound API / library. Then there was the versioning hell with JRE/JVM and having to tell users what version they had to download (the non tech savvy crowd). I know that MS doesn't make it easy for Java either. Well, I could have sorted the problems out with Java web start, SWT and all that kind of stuff. Instead, I learned D which I can compile and run on each platform without a problem. The promise of "Write once run everywhere" is still pretty much accurate if you stick to core Java code and libraries. Of course once you start using OS/implementation specific code you will have to code more carefully, and are more likely to encounter cross-platform problems. That's just the nature of things, you can't say it's a failure of Java. It's like coding in D using lots of malloc/free in your code, and then when your program breaks, you complain that "the D GC doesn't work!". Of course the GC only is only guaranteed to work if you stick to GC-managed memory. I can expect the Java Access Bridge to work, because Java offers it as a built-in technology. If it does not work, it's a broken promise. Simple as that. Does Java Access Bridge really not work, or you just didn't use it right? Or are you trying to use in for a purpose it's aimed to be used? Unfortunately, I'm not familiar with JAB, so I can't comment further on it.. I used it with Swing. It was ignored by all the screen readers. To be honest I smell a load of Java-biased *BS* here, especially because of this sentence: "Instead, I learned D which I can compile and run on each platform without a problem." Which is true. I could compile it on Linux, OS X and Windows. It was almost trivial to write a DLL that third party software can use. Try that with Java and tell me if it's trivially easy. I think what you meant was _anti_-Java *BS*. I'm only writing about my experience with the two languages. The one worked for me, the other didn't. When you say DLL, do you mean a shared library in general, or really an actual Windows DLL? I'm assuming it's the former, otherwise that doesn't make sense. Well In Java you can create them quite easily: jars. They are trivial to be used by other Java programs! I don't see your point. I mean a DLL that can be loaded by say a Python program (as in my case) or any other software that wants to use my plug-in[1]. A jar can only be used by another Java program. Making a Java program accessible to 3rd party software via a DLL is not so simple, and the JVM has to be up and running all the time. Java is cross-platform as long as you stay within the safe and cosy Java bubble that floats on top of the JVM. But once you step outside of the JVM, gravity kicks in. Don't get me wrong. I like the concept of a VM. Only Java has been screwed up over the years by bad and wrong decisions, partly due to ideology and partly due to strategic / marketing decisions. It's a pity really. It started out as a very promising language but got caught under the wheels of corporate decisions and OOP evangelists. You can write DLLs in Java, for example with http://www.excelsiorjet.com/. The fact that the Java reference implementation is a VM, doesn't tie the language to a VM. There are quite a few commercial compilers and JVMs with AOT support to choose from. Oracle is finally thinking about adding a AOT compilation mode to the standard toolchain in the Java 9+ release. http://www.oracle.com/technetwork/java/jvmls2014goetzrose-2265201.pdf As for OOP evangelists, had Java not happened, probably your rant would be now be about Smalltalk and Eiffel. The two OO languages getting an enterprise foothold at the time Sun started pushing Java. -- Paulo
Re: Using D
On Friday, 5 September 2014 at 14:18:46 UTC, Paulo Pinto wrote: On Friday, 5 September 2014 at 13:42:56 UTC, Chris wrote: On Friday, 5 September 2014 at 11:27:17 UTC, Bruno Medeiros wrote: On 04/09/2014 16:21, Chris wrote: On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno Medeiros wrote: On 26/08/2014 09:46, Chris wrote: The problem was that Java didn't behave as expected on Windows. Things that worked fine on Linux and OS X didn't work on Windows (even simple things like deleting files). User reported all sorts of problems, one of them being that the Java Access Bridge didn't work. Why, nobody knows. The lack of a proper sound API / library. Then there was the versioning hell with JRE/JVM and having to tell users what version they had to download (the non tech savvy crowd). I know that MS doesn't make it easy for Java either. Well, I could have sorted the problems out with Java web start, SWT and all that kind of stuff. Instead, I learned D which I can compile and run on each platform without a problem. The promise of "Write once run everywhere" is still pretty much accurate if you stick to core Java code and libraries. Of course once you start using OS/implementation specific code you will have to code more carefully, and are more likely to encounter cross-platform problems. That's just the nature of things, you can't say it's a failure of Java. It's like coding in D using lots of malloc/free in your code, and then when your program breaks, you complain that "the D GC doesn't work!". Of course the GC only is only guaranteed to work if you stick to GC-managed memory. I can expect the Java Access Bridge to work, because Java offers it as a built-in technology. If it does not work, it's a broken promise. Simple as that. Does Java Access Bridge really not work, or you just didn't use it right? Or are you trying to use in for a purpose it's aimed to be used? Unfortunately, I'm not familiar with JAB, so I can't comment further on it.. I used it with Swing. It was ignored by all the screen readers. To be honest I smell a load of Java-biased *BS* here, especially because of this sentence: "Instead, I learned D which I can compile and run on each platform without a problem." Which is true. I could compile it on Linux, OS X and Windows. It was almost trivial to write a DLL that third party software can use. Try that with Java and tell me if it's trivially easy. I think what you meant was _anti_-Java *BS*. I'm only writing about my experience with the two languages. The one worked for me, the other didn't. When you say DLL, do you mean a shared library in general, or really an actual Windows DLL? I'm assuming it's the former, otherwise that doesn't make sense. Well In Java you can create them quite easily: jars. They are trivial to be used by other Java programs! I don't see your point. I mean a DLL that can be loaded by say a Python program (as in my case) or any other software that wants to use my plug-in[1]. A jar can only be used by another Java program. Making a Java program accessible to 3rd party software via a DLL is not so simple, and the JVM has to be up and running all the time. Java is cross-platform as long as you stay within the safe and cosy Java bubble that floats on top of the JVM. But once you step outside of the JVM, gravity kicks in. Don't get me wrong. I like the concept of a VM. Only Java has been screwed up over the years by bad and wrong decisions, partly due to ideology and partly due to strategic / marketing decisions. It's a pity really. It started out as a very promising language but got caught under the wheels of corporate decisions and OOP evangelists. You can write DLLs in Java, for example with http://www.excelsiorjet.com/. I know, I know, but in D it comes for free. This would have broken the bank. The fact that the Java reference implementation is a VM, doesn't tie the language to a VM. There are quite a few commercial compilers and JVMs with AOT support to choose from. Oracle is finally thinking about adding a AOT compilation mode to the standard toolchain in the Java 9+ release. http://www.oracle.com/technetwork/java/jvmls2014goetzrose-2265201.pdf Finally, I've been waiting for this since forever. I always wondered why they didn't do it. Then again it was all about the "write once ..." ideology and they thought AOT would undermine this (which is not true). Why shouldn't programmers be able to make the decision (VM / AOT where it makes sense)? As for OOP evangelists, had Java not happened, probably your rant would be now be about Smalltalk and Eiffel. The two OO languages getting an enterprise foothold at the time Sun started pushing Java. -- Paulo It's not a rant. I'm happier in the D world than in the Java world, that's all. It's only when you step outside of the Java world that you realize who restricted and restrictive it is. For what it's worth, Java is a safe
Re: Using D
On 9/5/2014 11:42 PM, Chris wrote: On Friday, 5 September 2014 at 14:18:46 UTC, Paulo Pinto wrote: It's not a rant. I'm happier in the D world than in the Java world, that's all. It's only when you step outside of the Java world that you realize who restricted and restrictive it is. For what it's worth, Java is a safe enough technology for companies. Middle of the road type of thing. Java has its place. I would say that Python plugins isn't it. Right tool for the job and all that. Like you, I'm happier in the D world, but I don't see it as a silver bullet. I'd still choose Java for particular projects for the same reasons I'd choose Java over C++ for those same projects. I don't find it restrictive at all (I actually enjoy it; I also enjoy C). As long as you work within its boundaries and use it as it's meant to be used, it works perfectly well. That holds true for any language and, IMO, is what trips people up the most when moving from one language to another. This is very clear when you take, say, a Java programmer who actually likes it and one who uses it for the day job but prefers C++ and compare their list of gripes. Eckel's books are called "Thinking in..." for a reason. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Using D
On Friday, 5 September 2014 at 14:42:05 UTC, Chris wrote: On Friday, 5 September 2014 at 14:18:46 UTC, Paulo Pinto wrote: On Friday, 5 September 2014 at 13:42:56 UTC, Chris wrote: On Friday, 5 September 2014 at 11:27:17 UTC, Bruno Medeiros wrote: On 04/09/2014 16:21, Chris wrote: On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno Medeiros wrote: On 26/08/2014 09:46, Chris wrote: The problem was that Java didn't behave as expected on Windows. Things that worked fine on Linux and OS X didn't work on Windows (even simple things like deleting files). User reported all sorts of problems, one of them being that the Java Access Bridge didn't work. Why, nobody knows. The lack of a proper sound API / library. Then there was the versioning hell with JRE/JVM and having to tell users what version they had to download (the non tech savvy crowd). I know that MS doesn't make it easy for Java either. Well, I could have sorted the problems out with Java web start, SWT and all that kind of stuff. Instead, I learned D which I can compile and run on each platform without a problem. The promise of "Write once run everywhere" is still pretty much accurate if you stick to core Java code and libraries. Of course once you start using OS/implementation specific code you will have to code more carefully, and are more likely to encounter cross-platform problems. That's just the nature of things, you can't say it's a failure of Java. It's like coding in D using lots of malloc/free in your code, and then when your program breaks, you complain that "the D GC doesn't work!". Of course the GC only is only guaranteed to work if you stick to GC-managed memory. I can expect the Java Access Bridge to work, because Java offers it as a built-in technology. If it does not work, it's a broken promise. Simple as that. Does Java Access Bridge really not work, or you just didn't use it right? Or are you trying to use in for a purpose it's aimed to be used? Unfortunately, I'm not familiar with JAB, so I can't comment further on it.. I used it with Swing. It was ignored by all the screen readers. To be honest I smell a load of Java-biased *BS* here, especially because of this sentence: "Instead, I learned D which I can compile and run on each platform without a problem." Which is true. I could compile it on Linux, OS X and Windows. It was almost trivial to write a DLL that third party software can use. Try that with Java and tell me if it's trivially easy. I think what you meant was _anti_-Java *BS*. I'm only writing about my experience with the two languages. The one worked for me, the other didn't. When you say DLL, do you mean a shared library in general, or really an actual Windows DLL? I'm assuming it's the former, otherwise that doesn't make sense. Well In Java you can create them quite easily: jars. They are trivial to be used by other Java programs! I don't see your point. I mean a DLL that can be loaded by say a Python program (as in my case) or any other software that wants to use my plug-in[1]. A jar can only be used by another Java program. Making a Java program accessible to 3rd party software via a DLL is not so simple, and the JVM has to be up and running all the time. Java is cross-platform as long as you stay within the safe and cosy Java bubble that floats on top of the JVM. But once you step outside of the JVM, gravity kicks in. Don't get me wrong. I like the concept of a VM. Only Java has been screwed up over the years by bad and wrong decisions, partly due to ideology and partly due to strategic / marketing decisions. It's a pity really. It started out as a very promising language but got caught under the wheels of corporate decisions and OOP evangelists. You can write DLLs in Java, for example with http://www.excelsiorjet.com/. I know, I know, but in D it comes for free. This would have broken the bank. The fact that the Java reference implementation is a VM, doesn't tie the language to a VM. There are quite a few commercial compilers and JVMs with AOT support to choose from. Oracle is finally thinking about adding a AOT compilation mode to the standard toolchain in the Java 9+ release. http://www.oracle.com/technetwork/java/jvmls2014goetzrose-2265201.pdf Finally, I've been waiting for this since forever. I always wondered why they didn't do it. Then again it was all about the "write once ..." ideology and they thought AOT would undermine this (which is not true). Why shouldn't programmers be able to make the decision (VM / AOT where it makes sense)? I once read in a forum, shortly after the Oracle/Sun acquisition aftermath that there was a strong political position inside Sun against AOT. The post was arguably from an ex-Sun employee, but I cannot say s/he was really telling the truth. Actually, I think it was a bad decision to have gone fully VM, without any optional AOT options in the standard toolchain. At l
Re: Using D
On Friday, 5 September 2014 at 15:13:02 UTC, Mike Parker wrote: On 9/5/2014 11:42 PM, Chris wrote: On Friday, 5 September 2014 at 14:18:46 UTC, Paulo Pinto wrote: It's not a rant. I'm happier in the D world than in the Java world, that's all. It's only when you step outside of the Java world that you realize who restricted and restrictive it is. For what it's worth, Java is a safe enough technology for companies. Middle of the road type of thing. Java has its place. I would say that Python plugins isn't it. Right tool for the job and all that. Like you, I'm happier in the D world, but I don't see it as a silver bullet. I'd still choose Java for particular projects for the same reasons I'd choose Java over C++ for those same projects. I don't find it restrictive at all (I actually enjoy it; I also enjoy C). As long as you work within its boundaries and use it as it's meant to be used, it works perfectly well. The plugin had to be for Python, and for other languages to be able to plug into native MSAPI, OS X etc. Among other things, Java's unpluginability (if that's a word :) kicked it out of the race. Atm, I don't see any reason to start a project in Java. Even server side programming can be done by D. Maybe I'll consider Java again when they have AOT compilation. I really liked Java, but it became more and more useless for my purposes. And once you have the freedom that D offers, it's hard to go back. "I don't find it restrictive at all (I actually enjoy it; I also enjoy C). As long as you work within its boundaries and use it as it's meant to be used, it works perfectly well." Isn't this statement a bit contradictory :) It's not restrictive as long as you stay within its boundaries. In D you can stretch the boundaries a bit. That holds true for any language and, IMO, is what trips people up the most when moving from one language to another. This is very clear when you take, say, a Java programmer who actually likes it and one who uses it for the day job but prefers C++ and compare their list of gripes. Eckel's books are called "Thinking in..." for a reason. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Using D
On Friday, 5 September 2014 at 14:18:46 UTC, Paulo Pinto wrote: You can write DLLs in Java, for example with http://www.excelsiorjet.com/. The fact that the Java reference implementation is a VM, doesn't tie the language to a VM. True, but it is VERY hard to get performance out of it outside a VM. Java is tailored for a VM.
Re: Using D
On Friday, 5 September 2014 at 14:18:46 UTC, Paulo Pinto wrote: You can write DLLs in Java, for example with http://www.excelsiorjet.com/. The fact that the Java reference implementation is a VM, doesn't tie the language to a VM. Why pick Java if not for JVM? It is mediocre language at most, very limited and poor feature-wise, lacking expressive power even compared to C++ (you can at least abuse templates in the latter). JVM, however, may be the best VM environment implementation out there and that can be useful.
