www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Nim programming language finally hit 1.0

reply Rel <relmail rambler.ru> writes:
https://nim-lang.org/blog/2019/09/23/version-100-released.html

Well, finally Nim team released 1.0. Now future releases 
shouldn't break people's code and this fact should increase 
language adoption. Still few things seems to be unfinished (like 
their NewRuntime thing), but I'd like to congratulate Nim's team 
with this big release. What do you think about it?
Sep 25
next sibling parent reply JN <666total wp.pl> writes:
On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 https://nim-lang.org/blog/2019/09/23/version-100-released.html

 Well, finally Nim team released 1.0. Now future releases 
 shouldn't break people's code and this fact should increase 
 language adoption. Still few things seems to be unfinished 
 (like their NewRuntime thing), but I'd like to congratulate 
 Nim's team with this big release. What do you think about it?
I've been looking at Nim every now and then, but I don't really like it. It's trying to cover too many bases. Don't like camelCase? Don't worry, snake_case and PascalCase works too. Don't like GC? Don't worry, you can use refcounting and manual memory management too. Considering how APIs and libraries have to adapt to such multiple cases, I imagine the standard library is quite a mess.
Sep 25
next sibling parent bauss <jj_1337 live.dk> writes:
On Wednesday, 25 September 2019 at 10:37:07 UTC, JN wrote:
 I've been looking at Nim every now and then, but I don't really 
 like it. It's trying to cover too many bases. Don't like 
 camelCase? Don't worry, snake_case and PascalCase works too.
My biggest issue with Nim too. It's going to be a mess just like PHP was with function names being in all kinds of cases and you'd never know which one it is. Is it to_lower(str) or is it toLower(str) or is it ToLower(str) or is it tolower(str) etc.
Sep 29
prev sibling parent zoujiaqing <zoujiaqing gmail.com> writes:
On Wednesday, 25 September 2019 at 10:37:07 UTC, JN wrote:
 Don't like GC? Don't worry, you can use refcounting and manual
But I like ARC . Using ARC instead of GC .
Oct 04
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 https://nim-lang.org/blog/2019/09/23/version-100-released.html

 Well, finally Nim team released 1.0. Now future releases 
 shouldn't break people's code and this fact should increase 
 language adoption. Still few things seems to be unfinished 
 (like their NewRuntime thing), but I'd like to congratulate 
 Nim's team with this big release. What do you think about it?
The link above reads almost like a summary of "Don't do what D did!". Congratulations! I've been looking at Nim on and off (like most people, I suppose). One thing that really turns me off is that indentation is an integral part of the syntax [1]. Nim designers seem to forget that Python introduced forced indentation, because Python was meant to be used by non-programmers (chemists, biologists etc.), and thus this feature was there to "help" non-programmers to keep their code clean and tidy (cf. Perl!). However, Nim is targeting (experienced) programmers who really don't need a patronizing feature like that. This is a real bummer, in my opinion, like selling a bottle of whiskey with a child safety lock to a publican. [1] https://nim-lang.org/docs/manual.html#lexical-analysis-indentation
Sep 25
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-09-25 at 10:59 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]
 clean and tidy (cf. Perl!). However, Nim is targeting=20
 (experienced) programmers who really don't need a patronizing=20
 feature like that. This is a real bummer, in my opinion, like=20
[=E2=80=A6] Using whitespace instead of curly braces is not patronising, it is a langua= ge choice. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Sep 25
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 25 September 2019 at 12:50:42 UTC, Russel Winder 
wrote:
 On Wed, 2019-09-25 at 10:59 +0000, Chris via Digitalmars-d 
 wrote: […]
 clean and tidy (cf. Perl!). However, Nim is targeting 
 (experienced) programmers who really don't need a patronizing 
 feature like that. This is a real bummer, in my opinion, like
[…] Using whitespace instead of curly braces is not patronising, it is a language choice.
I will not engage in a discussion about Python-style whitespace tyranny again. In fact, it can render code actually _less_ readable and trigger compiler errors for no reason other than "missing indentation on line 149", copying and pasting can be a real nightmare. Fixing indentation can be time consuming - and what for? Forcing users to write "clean code". It might be a language choice - but then it's a bad one, and the fact remains that Python introduced it to nudge non-programmers into structuring their code. In other words, it was meant to be patronizing from the start. Indentation style should be decided on by the teams using the language and not be part of the language. Why is this so hard to understand?
Sep 25
next sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-09-25 at 13:04 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]
 I will not engage in a discussion about Python-style whitespace=20
 tyranny again. In fact, it can render code actually _less_=20
 readable and trigger compiler errors for no reason other than=20
 "missing indentation on line 149", copying and pasting can be a=20
 real nightmare. Fixing indentation can be time consuming - and=20
 what for? Forcing users to write "clean code". It might be a=20
 language choice - but then it's a bad one, and the fact remains=20
 that Python introduced it to nudge non-programmers into=20
 structuring their code. In other words, it was meant to be=20
 patronizing from the start. Indentation style should be decided=20
 on by the teams using the language and not be part of the=20
 language. Why is this so hard to understand?
Because it is your unsubstantiated opinion cast as some form of fact that i= s not a truth. You have a right to your opinion, and clearly you hate the Python way of indentation (which must therefore include any programming language with an "offside rule" such as Haskell). You do not have a right to try and state t= hat your opinion is fact that others must also believe. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Sep 25
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 September 2019 at 13:04:09 UTC, Chris wrote:
 I will not engage in a discussion about Python-style whitespace 
 tyranny again. In fact, it can render code actually _less_ 
 readable and trigger compiler errors for no reason other than
It is annoying if using a plain text editor, but I find it to be enjoyable when using a dedicated Python editor. I feel this is an area where current languages will start to look dated as new languages appear that are designed alongside the tooling for the language. Plain text is a rather crude representation.
Sep 27
parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2019-09-27 at 14:24 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-d
wrote:
=20
[=E2=80=A6]
 I feel this is an area where current languages will start to look=20
 dated as new languages appear that are designed alongside the=20
 tooling for the language.
=20
 Plain text is a rather crude representation.
Around 1986 people were shifting from using text editors to structure orien= ted editors of one form or another, where the stored representation of the code was some form of tree. Sadly the take up of these editors was drowned out b= y the clamour from programmers "you cannot take our text file representation = of our code from us". So now we have IDE that spend vast amounts of CPU power dynamically recreating tree representations of the text files so as to prov= ide all the programming language specific support. I think I am going to chalk this one up to karma. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Sep 27
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 September 2019 at 14:48:39 UTC, Russel Winder wrote:
 I think I am going to chalk this one up to karma.
Well, I don't know. It is easier to evolve UIs today, so I believe this will change, but it will take several iterations to get there. But I guess a new paradigm for evolving software is needed, an approach that is more iterative and REPL oriented perhaps. Nobody would want to design electronics using only a text editor... they have capable visual tooling. But they started out with a visual representation on paper so it was a translation from paper, that probably made adoption easier.
Sep 27
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 25 September 2019 at 10:59:55 UTC, Chris wrote:
 On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 https://nim-lang.org/blog/2019/09/23/version-100-released.html

 Well, finally Nim team released 1.0. Now future releases 
 shouldn't break people's code and this fact should increase 
 language adoption. Still few things seems to be unfinished 
 (like their NewRuntime thing), but I'd like to congratulate 
 Nim's team with this big release. What do you think about it?
The link above reads almost like a summary of "Don't do what D did!". Congratulations! I've been looking at Nim on and off (like most people, I suppose). One thing that really turns me off is that indentation is an integral part of the syntax [1]. Nim designers seem to forget that Python introduced forced indentation, because Python was meant to be used by non-programmers (chemists, biologists etc.), and thus this feature was there to "help" non-programmers to keep their code clean and tidy (cf. Perl!). However, Nim is targeting (experienced) programmers who really don't need a patronizing feature like that. This is a real bummer, in my opinion, like selling a bottle of whiskey with a child safety lock to a publican. [1] https://nim-lang.org/docs/manual.html#lexical-analysis-indentation
Forced indentation goes back to 70's languages. Python did nothing new there.
Sep 25
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 25 September 2019 at 14:24:39 UTC, Paulo Pinto 
wrote:
 On Wednesday, 25 September 2019 at 10:59:55 UTC, Chris wrote:
 On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 https://nim-lang.org/blog/2019/09/23/version-100-released.html

 Well, finally Nim team released 1.0. Now future releases 
 shouldn't break people's code and this fact should increase 
 language adoption. Still few things seems to be unfinished 
 (like their NewRuntime thing), but I'd like to congratulate 
 Nim's team with this big release. What do you think about it?
The link above reads almost like a summary of "Don't do what D did!". Congratulations! I've been looking at Nim on and off (like most people, I suppose). One thing that really turns me off is that indentation is an integral part of the syntax [1]. Nim designers seem to forget that Python introduced forced indentation, because Python was meant to be used by non-programmers (chemists, biologists etc.), and thus this feature was there to "help" non-programmers to keep their code clean and tidy (cf. Perl!). However, Nim is targeting (experienced) programmers who really don't need a patronizing feature like that. This is a real bummer, in my opinion, like selling a bottle of whiskey with a child safety lock to a publican. [1] https://nim-lang.org/docs/manual.html#lexical-analysis-indentation
Forced indentation goes back to 70's languages. Python did nothing new there.
Let me guess, the reasoning behind it was the same in the 70ies. Force "clean code"? I.e. patronizing. Please enlighten me. Anyway, Python made forced indentation popular. Python became a mainstream language "by accident", and because of its popularity people thought that forced indentation was great, although it has its merits only in contexts where most users are not programmers (e.g. natural sciences at universities).
Sep 25
parent reply bpr <brogoff gmail.com> writes:
On Wednesday, 25 September 2019 at 14:36:44 UTC, Chris wrote:
 Let me guess, the reasoning behind it was the same in the 
 70ies. Force "clean code"? I.e. patronizing. Please enlighten 
 me.
I believe it was introduced in the seminal paper "The next 700 programming languages" by Peter J. Landin, in the ISWIM abstract language of that paper, and later picked up by implemented languages later. ABC was the one that most influenced Python. My guess is that it had nothing to do with being patronizing, and that it was just a more readable notation, but that's just like, my opinion man.
Sep 25
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 25 September 2019 at 15:05:59 UTC, bpr wrote:
 On Wednesday, 25 September 2019 at 14:36:44 UTC, Chris wrote:
 Let me guess, the reasoning behind it was the same in the 
 70ies. Force "clean code"? I.e. patronizing. Please enlighten 
 me.
I believe it was introduced in the seminal paper "The next 700 programming languages" by Peter J. Landin, in the ISWIM abstract language of that paper, and later picked up by implemented languages later. ABC was the one that most influenced Python. My guess is that it had nothing to do with being patronizing, and that it was just a more readable notation, but that's just like, my opinion man.
Thanks. Yeah, I guessed its goal was to get a more readable notation, but you can get that with any language that doesn't force you to indent. It's common sense that you structure your code visually, but I call it patronizing or nanny syntax, if you are forced to use whitespace, there are many ways to visually structure your code but this should be up to the programmer / team / company.
Sep 25
parent reply JN <666total wp.pl> writes:
On Wednesday, 25 September 2019 at 15:11:57 UTC, Chris wrote:
 Thanks. Yeah, I guessed its goal was to get a more readable 
 notation, but you can get that with any language that doesn't 
 force you to indent. It's common sense that you structure your 
 code visually, but I call it patronizing or nanny syntax, if 
 you are forced to use whitespace, there are many ways to 
 visually structure your code but this should be up to the 
 programmer / team / company.
I guess it's just a matter of preference. Personally, "forced indentation" is one of my favourite features of Python. I indent mostly unnecessary noise to me. Also, I think you underestimate how hard it is to find a missing brace in code sometimes. For example if you forget a closing brace on a method, and then the compiler thinks next methods are inner methods and it breaks on a "class Foo" declaration 200 lines of code later.
Sep 25
parent Chris <wendlec tcd.ie> writes:
On Wednesday, 25 September 2019 at 20:56:49 UTC, JN wrote:
 I guess it's just a matter of preference. Personally, "forced 
 indentation" is one of my favourite features of Python. I 

 are mostly unnecessary noise to me. Also, I think you 
 underestimate how hard it is to find a missing brace in code 
 sometimes. For example if you forget a closing brace on a 
 method, and then the compiler thinks next methods are inner 
 methods and it breaks on a "class Foo" declaration 200 lines of 
 code later.
I know, I've had my fair share of both (missing braces and missing indentation), but I find missing braces easier to fix and they don't happen nearly as often as missing / wrong indentation. If you have to move lines and blocks around for testing / debugging / refactoring purposes, forced indentation can be a real PIA, and you have to spend time fixing things that shouldn't be broke in the first place. Worst of all: you don't just have to look for the missing brace, but check the optical alignment on the screen, now, what will you do if the statement opening the block is (50-100 lines) out of sight? A waste of time, or "diminishing returns" [1]. [1] https://en.wikipedia.org/wiki/Diminishing_returns
Sep 26
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 https://nim-lang.org/blog/2019/09/23/version-100-released.html

 Well, finally Nim team released 1.0. Now future releases 
 shouldn't break people's code and this fact should increase 
 language adoption. Still few things seems to be unfinished 
 (like their NewRuntime thing), but I'd like to congratulate 
 Nim's team with this big release. What do you think about it?
I'm happy that they have come to the 1.0 release and I wish them the best. I have personally tinkered with Nim in order to see if it fits my projects. The language is ok but I find the standard libraries a bit inconsistent. Syntax wise it quite nice and you can achieve a lot with fewer lines. The reason I found D better for my purposes was that it was easier to port C like algorithms to D and also D has better libraries. In my opinion Nim is one of the closest competitors of D because they are both runner up languages and they try to focus on productivity. Right now Rust seems to be influencing D a lot but I think if you want to look other languages, you should definitely also look at Nim.
Sep 25
next sibling parent reply a11e99z <black80 bk.ru> writes:
On Wednesday, 25 September 2019 at 11:02:57 UTC, IGotD- wrote:
 On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 https://nim-lang.org/blog/2019/09/23/version-100-released.html
The reason I found D better for my purposes was that it was easier to port C like algorithms to D and also D has better libraries. In my opinion Nim is one of the closest competitors of D because they are both runner up languages and they try to focus on productivity. Right now Rust seems to be influencing D a lot but I think if you want to look other languages, you should definitely also look at Nim.
and at Zig https://ziglang.org/documentation/master/
Sep 25
next sibling parent reply Rel <relmail rambler.ru> writes:
On Wednesday, 25 September 2019 at 12:43:01 UTC, a11e99z wrote:
 On Wednesday, 25 September 2019 at 11:02:57 UTC, IGotD- wrote:
 On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 https://nim-lang.org/blog/2019/09/23/version-100-released.html
The reason I found D better for my purposes was that it was easier to port C like algorithms to D and also D has better libraries. In my opinion Nim is one of the closest competitors of D because they are both runner up languages and they try to focus on productivity. Right now Rust seems to be influencing D a lot but I think if you want to look other languages, you should definitely also look at Nim.
and at Zig https://ziglang.org/documentation/master/
The funny thing about Zig is that right now it is a better C compiler, than a Zig compiler (in my personal opinion). Also I don't really like the idea of passing allocators around.
Sep 25
parent a11e99z <black80 bk.ru> writes:
On Wednesday, 25 September 2019 at 13:04:25 UTC, Rel wrote:
 On Wednesday, 25 September 2019 at 12:43:01 UTC, a11e99z wrote:

 and at Zig https://ziglang.org/documentation/master/
The funny thing about Zig is that right now it is a better C compiler, than a Zig compiler (in my personal opinion). Also I don't really like the idea of passing allocators around.
when no coroutines that can be executed by any thread u can put default allocator at TLS else at coroutine context (and fix API)
Sep 25
prev sibling parent reply SrMordred <patric.dexheimer gmail.com> writes:
On Wednesday, 25 September 2019 at 12:43:01 UTC, a11e99z wrote:
 On Wednesday, 25 September 2019 at 11:02:57 UTC, IGotD- wrote:
 On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 https://nim-lang.org/blog/2019/09/23/version-100-released.html
The reason I found D better for my purposes was that it was easier to port C like algorithms to D and also D has better libraries. In my opinion Nim is one of the closest competitors of D because they are both runner up languages and they try to focus on productivity. Right now Rust seems to be influencing D a lot but I think if you want to look other languages, you should definitely also look at Nim.
and at Zig https://ziglang.org/documentation/master/
I fail to see an appealing reason to use Zig. Can u point me something? (and i´m loving playing with Nim and macros :) )
Sep 25
parent Rel <relmail rambler.ru> writes:
On Wednesday, 25 September 2019 at 13:51:52 UTC, SrMordred wrote:
 On Wednesday, 25 September 2019 at 12:43:01 UTC, a11e99z wrote:
 On Wednesday, 25 September 2019 at 11:02:57 UTC, IGotD- wrote:
 On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 https://nim-lang.org/blog/2019/09/23/version-100-released.html
The reason I found D better for my purposes was that it was easier to port C like algorithms to D and also D has better libraries. In my opinion Nim is one of the closest competitors of D because they are both runner up languages and they try to focus on productivity. Right now Rust seems to be influencing D a lot but I think if you want to look other languages, you should definitely also look at Nim.
and at Zig https://ziglang.org/documentation/master/
I fail to see an appealing reason to use Zig. Can u point me something? (and i´m loving playing with Nim and macros :) )
There are few things I can think of. Like a special error types that enforces error checking. Automatic C-bindings is awesome. Having cross compilation as a first class citizen is nice too. Coroutines are in the WIP right now, don't know how well it will be implemented, we'll see.
Sep 25
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 25 September 2019 at 11:02:57 UTC, IGotD- wrote:
 In my opinion Nim is one of the closest competitors of D 
 because they are both runner up languages and they try to focus 
 on productivity. Right now Rust seems to be influencing D a lot 
 but I think if you want to look other languages, you should 
 definitely also look at Nim.
The problem of D has always been that it constantly follows the fashion of the day. First it was trying to "beat" C++, then it was competing with Go, now it's Rust. What's next? I find it refreshing to see languages like Nim and Zig that try to base their decisions on what works and what doesn't, what makes sense and what doesn't, not on Reddit threads about the latest CS fashion. Given that D has introduced a nice set of promising features of its own, I don't understand why D is constantly trying to emulate other languages, before it's even clear whether feature X will work or not. I think languages like Nim and Zig do have a chance, if they avoid D's mistakes and focus on their strengths. Usefulness and consistency are of utmost importance.
Sep 25
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 25 September 2019 at 14:29:19 UTC, Chris wrote:
 On Wednesday, 25 September 2019 at 11:02:57 UTC, IGotD- wrote:
 In my opinion Nim is one of the closest competitors of D 
 because they are both runner up languages and they try to 
 focus on productivity. Right now Rust seems to be influencing 
 D a lot but I think if you want to look other languages, you 
 should definitely also look at Nim.
The problem of D has always been that it constantly follows the fashion of the day. First it was trying to "beat" C++, then it was competing with Go, now it's Rust. What's next? I find it refreshing to see languages like Nim and Zig that try to base their decisions on what works and what doesn't, what makes sense and what doesn't, not on Reddit threads about the latest CS fashion. Given that D has introduced a nice set of promising features of its own, I don't understand why D is constantly trying to emulate other languages, before it's even clear whether feature X will work or not. I think languages like Nim and Zig do have a chance, if they avoid D's mistakes and focus on their strengths. Usefulness and consistency are of utmost importance.
Definitely, on my case what D offered me, not available in either in Java or .NET, has in the mean time been sorted out. C# 7.x low level features, .NET Native and CoreRT, h C++/CLI as additional companion, and while annotations + expression trees and F# computations aren't as straightforward as D's metaprogramming, they get the job done. Likewise Java is getting value types and a JNI replacement, GraalVM is an wonderful piece of technology, battle tested by Twitter, with NVidia now adding CUDA support, and annotation processors and reflection also offer good enough metaprogramming, even if like on .NET's case they aren't as developer friendly as D's. C++20, regardless of the backwards compatibility baggage it brings along, also offers many of the features that made D noteworthy and keeps being the tool to go when Java, .NET need an extra help. Then on Apple's platform I am an happy Swift user. While I still advocate D for safe systems programming, its story needs to be more coherent. And regarding the latest DIP discussions, if D veterans have issues trying to make sense how they are supposed to work, what hopes have newly D adopters? The broken features should be sorted out, and be proud of being a GC systems language. That is what I appreciate in Go and Nim, they have their story, with GC, and stand by it, even if that alienates some crowds. So even if Go is not supposed to be a systems language, there are Google projects using it like that (gVisor, Android GPGPU debugger, Fuchsia TCP/IP stack). The language should be stabilized, GC improved (I know it has gotten much better), replace deprecated Phobos packages (xml, JSON, stream), focus on vi/Emacs/VSCode and maybe people will come and stay around. Trying to cater to the crowds that flock to the systems language of the month is damaging for D's future, at the end the only thing left is patting each other in the back while asserting "language X might have won, but D had it first".
Sep 25
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 26 September 2019 at 06:14:24 UTC, Paulo Pinto wrote:

 And regarding the latest DIP discussions, if D veterans have 
 issues trying to make sense how they are supposed to work, what 
 hopes have newly D adopters?
See also the latest threads on DIP 1000 semantic, +1000!
 The broken features should be sorted out, and be proud of being 
 a GC systems language.

 That is what I appreciate in Go and Nim, they have their story, 
 with GC, and stand by it, even if that alienates some crowds.

 So even if Go is not supposed to be a systems language, there 
 are Google projects using it like that (gVisor, Android GPGPU 
 debugger, Fuchsia TCP/IP stack).

 The language should be stabilized, GC improved (I know it has 
 gotten much better), replace deprecated Phobos packages (xml, 
 JSON, stream), focus on vi/Emacs/VSCode and maybe people will 
 come and stay around.

 Trying to cater to the crowds that flock to the systems 
 language of the month is damaging for D's future, at the end 
 the only thing left is patting each other in the back while 
 asserting "language X might have won, but D had it first".
What to say more than that? Thanks Paulo! /P
Sep 26
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 26 September 2019 at 06:14:24 UTC, Paulo Pinto wrote:

 Definitely, on my case what D offered me, not available in 
 either in Java or .NET, has in the mean time been sorted out.
[...]
 Trying to cater to the crowds that flock to the systems 
 language of the month is damaging for D's future, at the end 
 the only thing left is patting each other in the back while 
 asserting "language X might have won, but D had it first".
Thanks for this brief summary. My experience is similar (more along the lines of Java/Kotlin and now with the addition of GraalVM). Your last paragraph sums it all up. D doesn't know which path to take, yet randomness and whimsicality are exactly what you don't want when you develop software.
Sep 26
prev sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 26 September 2019 at 06:14:24 UTC, Paulo Pinto wrote:

 The language should be stabilized, GC improved (I know it has 
 gotten much better), replace deprecated Phobos packages (xml, 
 JSON, stream), focus on vi/Emacs/VSCode and maybe people will 
 come and stay around.
There's a chicken-and-egg problem, though. D doesn't have the type of community that languages like Rust, Go, or Python have. I remember in the 90s when Python was insignificant to the programming world, they had their community of true believers promoting the language and making it more usable. In 2005, when I made my move to R for my computing, I looked at Python and it had little to offer. They had a community that made a lot of stuff happen in a hurry, and they promoted the language well. It's not even a particularly good choice for scientific computing, yet it is now a giant in that area. D has its mailing list and a few people doing their own projects (I'm in that group) but not a lot of blog posts or podcasts or tutorials, and can't even put together documentation for Dub. You read the mailing list and about two out of every three posts is negative. Until some people step up to be leaders of the community, nothing else will matter as far as D adoption goes. For all the years I've been involved, it's always been people looking to Walter and Andrei to make things happen, and I haven't seen anything like that with any other language.
Sep 26
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 26 September 2019 at 13:26:13 UTC, bachmeier wrote:
 
 It's [Python] not even a particularly good choice for 
 scientific computing, yet it is now a giant in that area.
You're right. Sigh.
 D has its mailing list and a few people doing their own 
 projects (I'm in that group) but not a lot of blog posts or 
 podcasts or tutorials, and can't even put together 
 documentation for Dub. You read the mailing list and about two 
 out of every three posts is negative. Until some people step up 
 to be leaders of the community, nothing else will matter as far 
 as D adoption goes. For all the years I've been involved, it's 
 always been people looking to Walter and Andrei to make things 
 happen, and I haven't seen anything like that with any other 
 language.
There's a huge difference between Python and D, though. Python (and its proponents) were targeting amateurs. It will be hard to find a (natural science / tech) student nowadays who hasn't dabbled in Python. So the audience is huge. But D is targeting hard core programmers, and they are naturally much harder to convince, because they know exactly what they want, and what they want it for. If you don't have a convincing "story" (as Paulo said), you're out. (Python on the other hand doesn't need a convincing story, it's used for throw-away scripts and it gives millions of people the feeling that they are "programmers".) What D needs is focus and consistency. Simple as.
Sep 26
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 26 September 2019 at 13:42:47 UTC, Chris wrote:

 There's a huge difference between Python and D, though. Python 
 (and its proponents) were targeting amateurs. It will be hard 
 to find a (natural science / tech) student nowadays who hasn't 
 dabbled in Python. So the audience is huge. But D is targeting 
 hard core programmers, and they are naturally much harder to 
 convince, because they know exactly what they want, and what 
 they want it for. If you don't have a convincing "story" (as 
 Paulo said), you're out. (Python on the other hand doesn't need 
 a convincing story, it's used for throw-away scripts and it 
 gives millions of people the feeling that they are 
 "programmers".) What D needs is focus and consistency. Simple 
 as.
Programmers are obsolete. AI is coming for them.
Sep 26
prev sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 26 September 2019 at 13:42:47 UTC, Chris wrote:


 (Python on the other hand doesn't need a convincing story, it's 
 used for throw-away scripts and it gives millions of people the 
 feeling that they are "programmers".) What D needs is focus and 
 consistency. Simple as.
Python is also used for a lot of "real" programming tasks these days. D is perfectly suited for scripts of 200 lines. Moderate-sized programs typically start as small scripts and grow over time. You don't have to convince anyone to switch languages if they start out with D. Neither Walter or Andrei has a scripting background, rather they are from the large-scale enterprise software world, and that led to the current emphasis on that segment. There's no reason the community can't pick up the ball and carry it into other arenas.
Sep 26
next sibling parent Meta <jared771 gmail.com> writes:
On Thursday, 26 September 2019 at 16:04:18 UTC, bachmeier wrote:
 On Thursday, 26 September 2019 at 13:42:47 UTC, Chris wrote:


 (Python on the other hand doesn't need a convincing story, 
 it's used for throw-away scripts and it gives millions of 
 people the feeling that they are "programmers".) What D needs 
 is focus and consistency. Simple as.
Python is also used for a lot of "real" programming tasks these days. D is perfectly suited for scripts of 200 lines. Moderate-sized programs typically start as small scripts and grow over time. You don't have to convince anyone to switch languages if they start out with D. Neither Walter or Andrei has a scripting background, rather they are from the large-scale enterprise software world, and that led to the current emphasis on that segment. There's no reason the community can't pick up the ball and carry it into other arenas.
Just to add to this, IMO D is far better than Python for scripting type tasks. At work, I write all my scripts in D unless it's prohibitively difficult to do so.
Sep 26
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 26 September 2019 at 16:04:18 UTC, bachmeier wrote:

 Python is also used for a lot of "real" programming tasks these 
 days.
I know, but that doesn't mean it's a good choice. I suppose people (say scientists) just started with little scripts and then kept on using the language they already knew when things got bigger. A lot of that "real" stuff is not used in contexts where performance is crucial (e.g. real time) and believe me, it's really annoying if you get a great piece of software / research in Python that is completely useless in terms of developing a product where performance is crucial. And you cannot simply rewrite it, because it depends on loads of other Python modules developed by other scientists etc. And, of course, they used Python, because of all the useful modules...it's a vicious circle.
 D is perfectly suited for scripts of 200 lines. Moderate-sized 
 programs typically start as small scripts and grow over time. 
 You don't have to convince anyone to switch languages if they 
 start out with D.
It is, but who will adopt an exotic language like D for scripting? D is "too much" for that, and it lacks the libraries Python has. Plus, everybody else uses Python etc. Do you really want to market D as a scripting language? It clearly isn't a scripting language. It's more like C++, Java and C# - and who's gonna learn D for scripting tasks? The learning curve is too steep. D is not a trivial language at all. Python is better suited for that.
 Neither Walter or Andrei has a scripting background, rather 
 they are from the large-scale enterprise software world, and 
 that led to the current emphasis on that segment. There's no 
 reason the community can't pick up the ball and carry it into 
 other arenas.
I don't think that's gonna work (see previous paragraph). The D community shouldn't be delusional about software and why / how it's adopted. There are both technical and socio-dynamic aspects to it. I think Nim and maybe Zig are much more realistic about things. (Btw, Nim's forced indentation might be a good marketing strategy to get Python devs on board. It might work.) D has become too intellectual, i.e. playing with ideas and abstract concepts have become more important than the real world. And the problem is that this playing around with ideas has negatively affected the use of D in the real world. Once the D community gets over that, D might have a convincing "story" (it did when I first started to use it, in ~2010 I think).
Sep 27
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 27 September 2019 at 10:45:31 UTC, Chris wrote:
 [snip]

 D has become too intellectual, i.e. playing with ideas and 
 abstract concepts have become more important than the real 
 world. And the problem is that this playing around with ideas 
 has negatively affected the use of D in the real world. Once 
 the D community gets over that, D might have a convincing 
 "story" (it did when I first started to use it, in ~2010 I 
 think).
I came to D from scripting languages like Matlab, Python, and R. It got to the point where my code was taking 24 hours + to run and I tried to find alternatives that were faster. I tried C++, but didn't like it very much. I prefer D to C++, but I'm still far more productive in Matlab/Python/R because I can depend on other people's libraries to a greater extent. However, D has made some good progress on the library front in the past two years. Mir has really come into its own with its own little universe around it (lubeck and numir are fun) and the GSOC project Magpie for Data Frames already looks promising. I would contrast this progress on the library front with the intellectual issues you are describing on the language itself. For me, the biggest downside with D was a lack of libraries. As you mentioned above, modules depending on modules. The network effect is very important for these types of use cases. So I do see progress on this front, even if there is a lot of unhappy feelings about some language issues.
Sep 27
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 27 September 2019 at 12:47:44 UTC, jmh530 wrote:

 I came to D from scripting languages like Matlab, Python, and 
 R. It got to the point where my code was taking 24 hours + to 
 run and I tried to find alternatives that were faster.
You're very wise. I wish more Matlab / Python users switched to highly performant languages.
 I tried C++, but didn't like it very much. I prefer D to C++, 
 but I'm still far more productive in Matlab/Python/R because I 
 can depend on other people's libraries to a greater extent.
 However, D has made some good progress on the library front in 
 the past two years. Mir has really come into its own with its 
 own little universe around it (lubeck and numir are fun) and 
 the GSOC project Magpie for Data Frames already looks 
 promising. I would contrast this progress on the library front 
 with the intellectual issues you are describing on the language 
 itself. For me, the biggest downside with D was a lack of 
 libraries. As you mentioned above, modules depending on 
 modules. The network effect is very important for these types 
 of use cases. So I do see progress on this front, even if there 
 is a lot of unhappy feelings about some language issues.
That's good to hear. Would you care to tell us what exactly you're using D for? I'd imagine it's for some sort of stats / machine learning / AI stuff. Your experience might be valuable for others who are trying to get away from Matlab / Python, and, as bachmeier suggested, D might attract more "scrpiters". Let them know what to expect and what you can do with D + Mir etc.
Sep 27
parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 27 September 2019 at 12:59:27 UTC, Chris wrote:
 [snip]

 That's good to hear. Would you care to tell us what exactly 
 you're using D for? I'd imagine it's for some sort of stats / 
 machine learning / AI stuff. Your experience might be valuable 
 for others who are trying to get away from Matlab / Python, 
 and, as bachmeier suggested, D might attract more "scrpiters". 
 Let them know what to expect and what you can do with D + Mir 
 etc.
TBH, my use is probably more at the hobby level rather than anyth Matlab, Python, R, and some others I know are all supported) and operationally it would cause a lot of difficulties if I was the only person writing in a language (the whole, what happens if you get hit by a bus). I've had a nice goal in the back of my mind to be able to do statistical analysis and portfolio optimization in D. I can do the optimization with DlangScience/nlopt, but this overlaps with my day job, so even if I do some work on this, I would need to get jump through work hoops before putting it online. So I feel a little more comfortable working on D projects that relate to statistical analysis. Some simple projects I've thought about working on include adding ols function to lubeck that can print some pretty results and seeing if dpp can use GSL out of the box. It's just a matter of finding the time. Projects like mir and magpie are good infrastructure, but there's a lot of statistical libraries that aren't supported in D. One library that I have been making a lot of use of in R is rstan for Bayesian inference. I haven't gotten around to trying to use stan in D (I know it's possible). It would be possible for me to write something like pystan or matlabstan, but rstan is implemented a little differently and faster. So I have kept up my R usage to use that.
Sep 27
prev sibling parent reply Laeeth Isharc <laeeth laeeth.com> writes:
On Friday, 27 September 2019 at 12:47:44 UTC, jmh530 wrote:
 On Friday, 27 September 2019 at 10:45:31 UTC, Chris wrote:
 [snip]

 D has become too intellectual, i.e. playing with ideas and 
 abstract concepts have become more important than the real 
 world. And the problem is that this playing around with ideas 
 has negatively affected the use of D in the real world. Once 
 the D community gets over that, D might have a convincing 
 "story" (it did when I first started to use it, in ~2010 I 
 think).
I came to D from scripting languages like Matlab, Python, and R. It got to the point where my code was taking 24 hours + to run and I tried to find alternatives that were faster. I tried C++, but didn't like it very much. I prefer D to C++, but I'm still far more productive in Matlab/Python/R because I can depend on other people's libraries to a greater extent. However, D has made some good progress on the library front in the past two years. Mir has really come into its own with its own little universe around it (lubeck and numir are fun) and the GSOC project Magpie for Data Frames already looks promising. I would contrast this progress on the library front with the intellectual issues you are describing on the language itself. For me, the biggest downside with D was a lack of libraries. As you mentioned above, modules depending on modules. The network effect is very important for these types of use cases. So I do see progress on this front, even if there is a lot of unhappy feelings about some language issues.
I haven't done much with it yet but I hooked up your embedr to our scripting language written in D and it works for examples with very little effort. I was planning to do same for Julia so we can steal their libraries too. So currently you can write inline D and R in SIL. Python isn't far off working and C++ and C# one can do a hello world but not much more (using cling and mono). I think using cling one could maybe expose quite a lot of C++ libraries to D if you don't insist on zero overhead. What were the practical limitations you encountered with using R libraries from D via embedr?
Sep 28
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 29 September 2019 at 03:53:57 UTC, Laeeth Isharc wrote:
 [snip]
 What were the practical limitations you encountered with using 
 R libraries from D via embedr?
Honestly, I haven't put it through its paces enough to say. I have used it for small examples, but nothing that significant.
Sep 29
prev sibling parent bachmeier <no spam.net> writes:
On Sunday, 29 September 2019 at 03:53:57 UTC, Laeeth Isharc wrote:

 I haven't done much with it yet but I hooked up your embedr to 
 our scripting language written in D and it works for examples 
 with very little effort.  I was planning to do same for Julia 
 so we can steal their libraries too.  So currently you can 
 write inline D and R in SIL.  Python isn't far off working and 
 C++ and C# one can do a hello world but not much more (using 
 cling and mono). I think using cling one could maybe expose 
 quite a lot of C++ libraries to D if you don't insist on zero 
 overhead.

 What were the practical limitations you encountered with using 
 R libraries from D via embedr?
The practical limitation is that it only does what I need. It's built around R's matrix/vector types, which are the ones I use. The released version doesn't provide support for multidimensional arrays, for instance, and the wrapper for working with R lists can still lead to segfaults under some use cases. I have personal code (not in embedr) to read both arrays and lists, and to create lists to return to R. That was easy to do, but it is limited to those uses. In a nutshell: If you want to pass data between the two languages as a vector or matrix, access that data in either language, or make changes to the data, it's all there and it should work. If you want to return a list from D to R (needed in order to return multiple items from a function), that will work. If you want to do fancy things, like passing a list from R to D and then making arbitrary changes on the D side without unpacking the data, there might be problems. There are a lot of issues with automating the protection/unprotection from R's garbage collector that the cost-benefit analysis has never been in favor of getting it to work. These days, when I do have time to work on this, it's mostly going into compilation of a subset of R to D. The idea is that while it's useless to try to compile arbitrary R code, there's a subset that can be made fast, and it's that subset responsible for most bottlenecks. Add type information to your R code, compile, and you've got something that runs as fast as D. Ultimately, I want it so that a coauthor can write their code in R, I can write my code in D, and either of us can run it with good performance. If I win the lottery I will take time off of work and complete it. :)
Sep 29
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 27 September 2019 at 10:45:31 UTC, Chris wrote:
 On Thursday, 26 September 2019 at 16:04:18 UTC, bachmeier wrote:

 [...]
I know, but that doesn't mean it's a good choice. I suppose people (say scientists) just started with little scripts and then kept on using the language they already knew when things got bigger. A lot of that "real" stuff is not used in contexts where performance is crucial (e.g. real time) and believe me, it's really annoying if you get a great piece of software / research in Python that is completely useless in terms of developing a product where performance is crucial. And you cannot simply rewrite it, because it depends on loads of other Python modules developed by other scientists etc. And, of course, they used Python, because of all the useful modules...it's a vicious circle. [...]
If any language is going to overtake Python or R among scientific users, I am betting Julia will be that language.
Sep 27
next sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 27 September 2019 at 13:04:37 UTC, Paulo Pinto wrote:

 If any language is going to overtake Python or R among 
 scientific users, I am betting Julia will be that language.
Yep. I agree. It's geared towards scientific programming and the devs are well aware of the drawbacks of Python and Matlab. "Julia features optional typing, multiple dispatch, and good performance, achieved using type inference and just-in-time (JIT) compilation, implemented using LLVM. It is multi-paradigm, combining features of imperative, functional, and object-oriented programming. Julia provides ease and expressiveness for high-level numerical computing, in the same way as languages such as R, MATLAB, and Python, but also supports general programming. To achieve this, Julia builds upon the lineage of mathematical programming languages, but also borrows much from popular dynamic languages, including Lisp, Perl, Python, Lua, and Ruby." [1] [1] https://docs.julialang.org/en/v1/
Sep 27
prev sibling parent reply bachmeier <no spam.net> writes:
On Friday, 27 September 2019 at 13:04:37 UTC, Paulo Pinto wrote:

 If any language is going to overtake Python or R among 
 scientific users, I am betting Julia will be that language.
*If* that is going to happen, I think you're right. Many economists have been moving from Matlab to Julia. For instance, the New York Fed has ported their forecasting model (a fairly large codebase) from Matlab to Julia. Matlab is not the best language, but a bigger factor is that it's really expensive - wealthy institutions complain about Matlab licensing costs. I don't see it making much progress in replacing Python or R yet. Maybe that's just my small view of the world. A different use case, for which Julia isn't as well suited, is writing extensions. In R, the most popular dependency for packages by far is C++ in the form of Rcpp. D is a perfect replacements, and that's primarily how I've been using it (giving up on C++ for that was why I looked at D in the first place). There's a lot of room for D in that area. Too bad I don't have time to work on marketing it.
Sep 27
next sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 27 September 2019 at 14:01:34 UTC, bachmeier wrote:
 *If* that is going to happen, I think you're right. Many 
 economists have been moving from Matlab to Julia. For instance, 
 the New York Fed has ported their forecasting model (a fairly 
 large codebase) from Matlab to Julia. Matlab is not the best 
 language, but a bigger factor is that it's really expensive - 
 wealthy institutions complain about Matlab licensing costs. I 
 don't see it making much progress in replacing Python or R yet. 
 Maybe that's just my small view of the world.

 A different use case, for which Julia isn't as well suited, is 
 writing extensions. In R, the most popular dependency for 
 packages by far is C++ in the form of Rcpp. D is a perfect 
 replacements, and that's primarily how I've been using it 
 (giving up on C++ for that was why I looked at D in the first 
 place). There's a lot of room for D in that area. Too bad I 
 don't have time to work on marketing it.
Now, that sounds very interesting and promising. A few bullet points and maybe it could be turned into a blog post. There are two obstacles though: 1. D is huge, so you'd need a dedicated section "D for Data Scientists", so they know exactly which subset / features to use to get going. 2. Lack of consistency due to a constant change of focus by leadership / community Imo, 2. is the biggest obstacle.
Sep 27
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 27 September 2019 at 14:01:34 UTC, bachmeier wrote:
 A different use case, for which Julia isn't as well suited, is 
 writing extensions. In R, the most popular dependency for 
 packages by far is C++ in the form of Rcpp. D is a perfect 
 replacements, and that's primarily how I've been using it
Speaking of which, I've thought about D as an extension / glue language too. I think it'd be well suited for that.
Sep 27
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 September 2019 at 14:01:34 UTC, bachmeier wrote:
 On Friday, 27 September 2019 at 13:04:37 UTC, Paulo Pinto wrote:

 If any language is going to overtake Python or R among 
 scientific users, I am betting Julia will be that language.
*If* that is going to happen, I think you're right. Many economists have been moving from Matlab to Julia. For instance, the New York Fed has ported their forecasting model (a fairly large codebase) from Matlab to Julia. Matlab is not the best language, but a bigger factor is that it's really expensive - wealthy institutions complain about Matlab licensing costs. I don't see it making much progress in replacing Python or R yet. Maybe that's just my small view of the world.
Octave is a free implementation of Matlab that is quite capable, but it does not provide all the specialized matlab functions needed to achieve 100% compatibility. So if that is an obstacle for Octave, then it probably is an obstacle for Julia as well. Anyway, as long as Python is taking over in higher education then Python will remain the language of choice... Since Julia is not suitable for CS students then Python most likely will keep that position. Btw, I think most people need a very compelling reason to switch to a new language.
Sep 27
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 27 September 2019 at 14:31:14 UTC, Ola Fosheim Grøstad 
wrote:
 Octave is a  free implementation of Matlab that is quite 
 capable, but it does not provide all the specialized matlab 
 functions needed to achieve 100% compatibility.  So if that is 
 an obstacle for Octave, then it probably is an obstacle for 
 Julia as well.
Not the real deal. People always return to Matlab.
 Anyway, as long as Python is taking over in higher education 
 then Python will remain the language of choice...  Since Julia 
 is not suitable for CS students then Python most likely will 
 keep that position.

 Btw, I think most people need a very compelling reason to 
 switch to a new language.
Three compelling reasons: performance, performance and performance. :) Seriously, there's a lot of great stuff out there, but it's written in Python and Matlab and thus often quite useless except as "proof of concept". This has been bugging me for years.
Sep 27
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 September 2019 at 14:43:32 UTC, Chris wrote:
 Not the real deal. People always return to Matlab.
Probably, the problem is when you try to run models written by others and they use rarely used Matlab functions.
 Btw, I think most people need a very compelling reason to 
 switch to a new language.
Three compelling reasons: performance, performance and performance. :)
Right, but it is likely to come in the form of kernels that compiles to OpenCL for numerics. So, new libraries that can run on the GPU, but is controlled from Python.
Sep 27
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2019-09-27 at 14:31 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-d
wrote:
[=E2=80=A6]
=20
 Anyway, as long as Python is taking over in higher education then=20
 Python will remain the language of choice...  Since Julia is not=20
 suitable for CS students then Python most likely will keep that=20
 position.
=20
[=E2=80=A6] At least in the UK, Python is the language of teaching programming to 10 to= 16 year olds. Universities now have to cope with new undergraduates already knowing Python, and probably some Java. UK universities are having to change their whole approach.=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Sep 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 September 2019 at 14:51:31 UTC, Russel Winder wrote:
 At least in the UK, Python is the language of teaching 
 programming to 10 to 16 year olds. Universities now have to 
 cope with new undergraduates already knowing Python, and 
 probably some Java.

 UK universities are having to change their whole approach.
Right. I believe Python will be introduced in public schools in Norway within the next decade or so. A few years back University of Oslo chose Python as their introduction language for alle the science departments. Then the CS department introduce Java after Python. In more advanced physics courses students may choose between Python and C++. Anyway, several books, say introduction course books in physics, come in one edition for Matlab and another for Python. Adding more editions for other languages across the board seems unlikely in the near future. You probably will find some for Java and some for Julia, but not enough to cover all the courses for a bachelor. As more and more courses use programming as "advanced calculators" and for simple didactic simulations we end up with a situation where they want a single language for all science topics. Preferably one that can be used interactively. So Python seems to dominate as the tool of choice for "didactic programming".
Sep 27
parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2019-09-27 at 15:16 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-d
wrote:
=20
[=E2=80=A6]
 Right. I believe Python will be introduced in public schools in=20
 Norway within the next decade or so.  A few years back University=20
 of Oslo chose Python as their introduction language for alle the=20
 science departments. Then the CS department introduce Java after=20
 Python.  In more advanced physics courses students may choose=20
 between Python and C++.
Subjects such as biology and physics and all the various variations are for the moment settling on C++ for computational stuff and Python for coordination, visualisation, and data rendering. As example astropy for mos= t of astronomy. It isn't that Python/C++ is the best choice per se, it is tha= t libraries got developed using the Python/C++ combination, and that people working in the fields are introduced to these libraries as the de facto standard for their subject. I cannot see Nim, D, Chapel, etc. even denting this traction of Python and C++, though at least Nim looks derivative of Python. Something similar is happening in data science, machine learning, and artificial intelligence: Python has become the de facto standard because someone chose to write all the libraries people needed in Python, NumPy, or C++.
 Anyway, several books, say introduction course books in physics,=20
 come in one edition for Matlab and another for Python.  Adding=20
 more editions for other languages across the board seems unlikely=20
 in the near future.
The use of Matlab was set because universities were given free licences, I suspect as a loss leader to ensure people knew Matlab and expected to use i= t when they moved to the world of work. However, over the 2007 to 2015 period= it was clear Matlab were charging too much and that Python was the obvious pla= ce to move to. I ran many workshops over 2010 to 2015 retraining Matlab programmers as Python programmers. Actually they were electrical engineers = not programmers who just wanted to solve problems. Matlab had the tools, but wa= s too expensive, they discovered Python also had the tools, and so they switched. I suspect there is beginning to be back pressure from the world of work to universities against Matlab and for Python, but this is speculation on my part.
 You probably will find some for Java and some for Julia, but not=20
 enough to cover all the courses for a bachelor.
=20
 As more and more courses use programming as "advanced=20
 calculators" and for simple didactic simulations we end up with a=20
 situation where they want a single language for all science=20
 topics. Preferably one that can be used interactively.
Having been an integral part of the late 1990s push for Java everywhere in university to make teaching easier, it was a very big mistake. The late 198= 0s, early 1990s situation of using two or three different programming languages for the core university curriculum made for much better programmers. So Pyt= hon for everything in universities is a very bad idea as well, at least for CS students =E2=80=93 electrical engineering, biology, and physics students ar= e in a different boat.
 So Python seems to dominate as the tool of choice for "didactic=20
 programming".
=20
--=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Sep 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 September 2019 at 17:37:14 UTC, Russel Winder wrote:
 It isn't that Python/C++ is the best choice per se, it is that 
 libraries got developed using the Python/C++ combination, and 
 that people working in the fields are introduced to these 
 libraries as the de facto standard for their subject. I cannot 
 see  Nim, D, Chapel, etc. even denting this traction of Python 
 and C++, though at least Nim looks derivative of Python.
Right, it is very difficult to make this move as more and more simulation models or libraries are implemented in a specific language. Although it does happen, Fortran is not as important as it used to be, at least that is my impression. But it clearly takes decades, not years, to make this move.
 Something similar is happening in data science, machine 
 learning, and artificial intelligence: Python has become the de 
 facto standard because someone chose to write all the libraries 
 people needed in Python, NumPy, or C++.
True.
 The use of Matlab was set because universities were given free 
 licences, I suspect as a loss leader to ensure people knew 
 Matlab and expected to use it when they moved to the world of 
 work. However, over the 2007 to 2015 period it was clear Matlab 
 were charging too much and that Python was the obvious place to 
 move to. I ran many workshops over 2010 to 2015 retraining 
 Matlab programmers as Python programmers. Actually they were 
 electrical engineers not programmers who just wanted to solve 
 problems. Matlab had the tools, but was too expensive, they 
 discovered Python also had the tools, and so they switched.
Interesting that electrical engineers found that switch worthwhile, but I still think that if you primarily do experiments with linear algebra or signal processing then Matlab is more convenient to use interactively than Python. Yet, if you already know Python then maybe that isn't enough to also learn Matlab. So I think that over time, as Python becomes the primary language in education, you also get that effect. Not because Python is better than the alternative, but that learning the alternative is less attractive than solving the problem right away (so they prefer writing more code in Python than learning Matlab and write more terse code).
 I suspect there is beginning to be back pressure from the world 
 of work to universities against Matlab and for Python, but this 
 is speculation on my part.
I don't know, but I suspect as people that grew up with Python enter leadership position then the question becomes "Is there a good reason for not using Python for this?".
 university curriculum made for much better programmers. So 
 Python for everything in universities is a very bad idea as 
 well, at least for CS students – electrical engineering,
Yeah, but if you always start out with Python then students can switch field after the first two years with less resistance. Then you probably learn Arduino or C in a low level programming course, Scheme in a functional programming course, Prolog in a logic course, and Java . That's not too bad, but the real problem is that some students only do mandatory programming exercises and do not program on their own, and that institutions do not want too many students to fail. If you then add into the mix that the CS department want many students (as the money follow the student) they end up accepting low quality submissions and thus the students don't get the training through effort that they need. The desire to write your own programs and try out other languages is probably necessary to become a decent programmer. Not sure what can be done with that. In the 80s low level programming was a hobby, maybe 1 out of 10 males experimented with this on their 8-bit computers... We don't have these numbers today, I think?
Sep 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 September 2019 at 18:16:27 UTC, Ola Fosheim Grøstad 
wrote:
 The desire to write your own programs and try out other 
 languages is probably necessary to become a decent programmer. 
 Not sure what can be done with that. In the 80s low level
Another factor is that in the 80s and 90s the available languages were quite primitive and not too big and the hardware was insufficient for many tasks. So there was a real motivation to look for better tools. As languages and eco systems have become quite large and hardware is sufficient for most tasks, then we also should expect less motivation for looking for better tools. Seems like the adoption of new languages today is primarily driven by a desire by big corporations to avoid compatibility and isolate their own eco systems. Apple/Swift. Google/Go/Koitlin. Oracle/Java. I am not sure if this trend is a good thing. Actually it probably is bad. Seems like there is a desire for big business to segregate developers into Apple-programmers, Microsoft-programmers, Google-programmers, Business/Database programmers… Clearly not beneficial to programmers. Python bypasses all that though. Which in my view is a good thing.
Sep 27
next sibling parent reply JN <666total wp.pl> writes:
On Friday, 27 September 2019 at 18:41:46 UTC, Ola Fosheim Grøstad 
wrote:
 Seems like the adoption of new languages today is primarily 
 driven by a desire by big corporations to avoid compatibility 
 and isolate their own eco systems.

 Apple/Swift.

 Google/Go/Koitlin.
 Oracle/Java.
I don't think it's strictly that. It's more like they are looking for a way to improve developer experience for their respective platform. They don't have to necessarily look for isolation, they just don't want to make any effort to support other platforms more than necessary. Swift is obviously a replacement for Objective-C. Objective-C is already incompatible and isolated, because it's THE language for iOS/macOS, and basically doesn't exist elsewhere. But it is quite outdated, and developers writing apps for Apple platforms would like to use a more modern language. Kotlin is obviously a replacement for Java. Due to various reasons, Java's been quite conservative feature-wise and it's losing ground to C#, which is feels much more modern. Kotlin is an attempt to bring up Java to C# levels for developers, while still being able to interop and make use of the massive JVM ecosystem. Go... I think Go started as a side project by some googlers? I think the goal was to offer an alternative to C/C++. Nowadays we have D, Rust, Crystal but back then there weren't really alternatives if you were looking for something that isn native but isn't C/C++.
Sep 27
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 September 2019 at 18:58:31 UTC, JN wrote:
 I don't think it's strictly that. It's more like they are 
 looking for a way to improve developer experience for their 
 respective platform. They don't have to necessarily look for 
 isolation, they just don't want to make any effort to support 
 other platforms more than necessary.
It is pretty obvious that Apple doesn't want to make it easy to port iOS apps to Android. Same with Microsoft and Windows-applications. They have both made too many developer-hostile moves over the years for this not to be true. Microsoft even did it with their browser for over a decade. Apple did it with iOS Safari as well. Google is more in a grey area. They have fewer reasons to lock in and lock out.
 Kotlin is obviously a replacement for Java. Due to various 
 reasons, Java's been quite conservative feature-wise and it's 
 losing ground to C#, which is feels much more modern. Kotlin is 
 an attempt to bring up Java to C# levels for developers, while 
 still being able to interop and make use of the massive JVM 
 ecosystem.
They are not competing with C#, they are competing with Swift...
 Go... I think Go started as a side project by some googlers?
AFAIK it was an attempt to build a system programming language for internal use at Google that would allow them to hire cheaper labour than C++ programmers. But Go had problems gaining traction within Google.
Sep 27
prev sibling parent reply Ali <fakeemail example.com> writes:
On Friday, 27 September 2019 at 18:41:46 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 27 September 2019 at 18:16:27 UTC, Ola Fosheim 
 Grøstad wrote:

 Seems like the adoption of new languages today is primarily 
 driven by a desire by big corporations to avoid compatibility 
 and isolate their own eco systems.

 Apple/Swift.

 Google/Go/Koitlin.
 Oracle/Java.
Something I was always curious to know, Andrei Alexandrescu worked at facebook for few years And from the little available online, it seems that facebook for a while used D for some internal tools Again as an outsider, and with very little available on this, it seems facebook moved t Ocaml and than Reason Did Andrei, ever write a blog on why D at facebook didnt happen, it seems like it could have been a big moment for D (OCaml is a GC language, so it can't be the GC)
Oct 01
parent Chris <wendlec tcd.ie> writes:
On Tuesday, 1 October 2019 at 15:55:50 UTC, Ali wrote:
 Something I was always curious to know, Andrei Alexandrescu 
 worked at facebook for few years

 And from the little available online, it seems that facebook 
 for a while used D for some internal tools

 Again as an outsider, and with very little available on this, 
 it seems facebook  moved t Ocaml and than Reason

 Did Andrei, ever write a blog on why D at facebook didnt 
 happen, it seems like it could have been a big moment for D

 (OCaml is a GC language, so it can't be the GC)
I remember Andrei mentioned in an article that D was faster than C++ for a script like cli tool, because it never freed memory in the first place (before it finished). Below you will find some material about it [1]. I don't know what exactly D was used for at facebook (he's probably not allowed to reveal it), but it might have been data analysis, same stuff sociomantics uses it for. Anyway, would be interesting to see why facebook abandoned it (or at least didn't go on with it) after Andrei had left. But the D community tends not to ask such questions ;) [1] 2013 The announcement: https://forum.dlang.org/post/l37h5s$2gd8$1 digitalmars.com "In a post on the Dlang.org website, Alexandrescu elaborates a little more: The code project he’s working on is in “heavy daily use at Facebook” and originally it was written in C++. Now that it’s in D the team has “measured massive wins in all of source code size, build speed, and running speed.” His post has spurred a lot of positive support on the forum, and if what he says is true then it would make sense for Facebook to take a critical tool and make it more efficient–because there will be an upshot on overall efficiency of operations at the site." https://www.fastcompany.com/3019887/facebook-adds-5000-lines-of-d-language-code-whats-that-mean 2014 "Today, Alexandrescu is a research scientist at Facebook, where he and a team of coders are using D to refashion small parts of the company's massive operation. Bright, too, has collaborated with Facebook on this experimental software, as an outsider contractor. The tech giant isn't an official sponsor of the language—something Alexandrescu is quick to tell you—but Facebook believes in D enough to keep him working on it full-time, and the company is at least considering the possibility of using D in lieu of C++, the venerable language that drives the systems at the heart of so many leading web services." https://www.wired.com/2014/07/d-programming-language/
Oct 01
prev sibling parent Laeeth Isharc <laeeth laeeth.com> writes:
On Friday, 27 September 2019 at 14:01:34 UTC, bachmeier wrote:
 On Friday, 27 September 2019 at 13:04:37 UTC, Paulo Pinto wrote:

 If any language is going to overtake Python or R among 
 scientific users, I am betting Julia will be that language.
*If* that is going to happen, I think you're right. Many economists have been moving from Matlab to Julia. For instance, the New York Fed has ported their forecasting model (a fairly large codebase) from Matlab to Julia. Matlab is not the best language, but a bigger factor is that it's really expensive - wealthy institutions complain about Matlab licensing costs. I don't see it making much progress in replacing Python or R yet. Maybe that's just my small view of the world. A different use case, for which Julia isn't as well suited, is writing extensions. In R, the most popular dependency for packages by far is C++ in the form of Rcpp. D is a perfect replacements, and that's primarily how I've been using it (giving up on C++ for that was why I looked at D in the first place). There's a lot of room for D in that area. Too bad I don't have time to work on marketing it.
Small beginning. https://github.com/symmetryinvestments/juliad
Sep 28
prev sibling parent reply GreatSam4sure <greatsam4sure gmail.com> writes:
On Thursday, 26 September 2019 at 13:26:13 UTC, bachmeier wrote:
 On Thursday, 26 September 2019 at 06:14:24 UTC, Paulo Pinto 
 wrote:

 The language should be stabilized, GC improved (I know it has 
 gotten much better), replace deprecated Phobos packages (XML, 
 JSON, stream), focus on vi/Emacs/VSCode and maybe people will 
 come and stay around.
There's a chicken-and-egg problem, though. D doesn't have the type of community that languages like Rust, Go, or Python has. I remember in the 90s when Python was insignificant to the programming world, they had their community of true believers promoting the language and making it more usable. In 2005, when I made my move to R for my computing, I looked at Python and it had little to offer. They had a community that made a lot of stuff happen in a hurry, and they promoted the language well. It's not even a particularly good choice for scientific computing, yet it is now a giant in that area. D has its mailing list and a few people doing their own projects (I'm in that group) but not a lot of blog posts or podcasts or tutorials, and can't even put together documentation for Dub. You read the mailing list and about two out of every three posts is negative. Until some people step up to be leaders of the community, nothing else will matter as far as D adoption goes. For all the years I've been involved, it's always been people looking to Walter and Andrei to make things happen, and I haven't seen anything like that with any other language.
This is a newbie point of view. The biggest problem to D adoption is this community IMHO. Almost everything here is negative. The community is 95% negative to the language. There are people here that never see anything good about D yet they are here. The community is damaging to D image. It is a community that is out to destroy the language. All the hope of me using D has been almost destroyed. The leadership and most people in the community seem to be the opposite poles yet we want D to have great adoption. Just open your google and search for D you will read so many negative things about the language. Come to the community, the story is the same. This is the most negative community to its own language I have ever known of. The story has to change. This community greatly discourage me. It is my biggest problem using D. I have personally come to believe that many people in this community is sponsor against the language. Pls if you know you are no longer interest in D it will be better not to discourage others. Also, the leadership should handle the difference between them any community member to prevent them from pouring their frustration here.
Sep 27
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Sep 27, 2019 at 03:11:26PM +0000, GreatSam4sure via Digitalmars-d wrote:
[...]
 This is a newbie point of view.
 
 The biggest problem to D adoption is this community IMHO. Almost
 everything here is negative. The community is 95% negative to the
 language. There are people here that never see anything good about D
 yet they are here. The community is damaging to D image.
[...] I don't know what has happened here, and why the naysayers seem to be out in force here, but I want to say that I am very positive about D, and I'm pretty sure I'm not the only one. I just haven't been posting as much because I'm occupied with other things. But seriously, there is no language out there right now that I like better than D. It's true that D has its flaws and dark corners -- no language of this complexity can possibly be perfect -- but the good stuff is REALLY good, and none of that is going away anytime soon. OTOH, one of the reasons we are sometimes very critical about something in the language is because it's *so* good, and we have come to expect the best, so when we see something that still needs improvement, we tend to speak out. We criticize the not-so-good parts because we care. Or at least I do -- can't speak for anyone else. And one thing I've learned over the years: don't waste time on the naysayers. Know what you want, and go for it. Let others waste their breath naysaying if that's what they want -- let it be their problem, not yours. T -- Любишь кататься - люби и саночки возить.
Sep 27
prev sibling parent reply Benjiro <benjiro benjiro.com> writes:
On Friday, 27 September 2019 at 15:11:26 UTC, GreatSam4sure wrote:
 The biggest problem to D adoption is this community IMHO. 
 Almost everything here is negative. The community is 95% 
 negative to the language. There are people here that never see 
 anything good about D yet they are here. The community is 
 damaging to D image.

 It is a community that is out to destroy the language. All the 
 hope of me using D has been almost destroyed.
As one of these negative people that from time to time reads up on multiple languages forums. D was one of the first languages after moving away from Web dev, that i liked from structure point. Even got the book from Ali. But ... the more i worked with it, the more frustration, upon frustration, upon ... kept creeping in with constant issues. * Not user friendly tooling ( somewhat improved, took only a few years ) * Compiler bugs. O those bugs ... * Upgrading the compiler resulting in packages ( like vibe.d going broke ) * Lacking IDE support ( somewhat improved on Visual Studio Code ) * Lacking in packages to easily get going. * Constant and frustrating changing direction. BetterC? First get BetterD doing and when your a big boy, then do this. * The feeling off being looked down when suggestion that D is not user friendly. Especially in the past you constantly got this as a answer: "you have a issue, fix it yourself". Yes, this was the constant answer from everybody. * The snarky and frankly poison comments from regular members. Some of those now seem to have left but D really has some members that got under anybody their skin for daring to mention a issue. * Focus upon C++ crowd, when very few C++ developers have any interest in D. Hell, if a C++ developer wants to switch, they have better alternatives with bigger or better growing communities. * A leadership that seems to be stuck in the 1990's mentality. The world has moved on, people expect more these days, they have choices most old timers did not have. So they are more spoiled with those choices and are not going to put in the time. But when you ignore those "spoiled" people, you never build up a loyal base and you will never motivate them to help out with code or money. You can not run anything worth while with D unless you plan on spending a lot of time writing supporting code yourself. Some companies have no issue with this but little old me can not be bothered with it, when there are plenty of good alternatives that get the job done as good. * I know one of the posters on this forum a bit more personal. We have had some discussions about the different compilers. Just as he used Go for his personal project, i used Crystal for mine. We both found D too much trouble for the advantages it gave. Its a vicious circle and i know it. Lack in people / contributors => No Packaging / Bugs / Issues => New people scared away => Lack in people / contributors .... * D just is not sexy. I know D now from 10/2016 ( when i got Ali's book. Programming in D ). Loved the book and language syntax ( especially if you come from PHP ) but it was all the rest that ruined it for me. And over the years D seems to have been going down a direction that i hated. New features that had no meaning for me, code breaking issues and resources being put in features like BetterC, when all i wanted was a god darn simple HTTP server that worked and kept working on release updates. And more active packages. * On the subject of Programming in D, i noticed a lot of books are old. BetterC, the feature where a lot of resources have gone into, seems to be ignored in every book on the market. ------------------------------ To give you a nice example how much of a irritation D can be even today. Just right now, i tried to install D on Ubuntu because i want to time the current D compile speed, vs a few other languages. And i am following the official order ( https://dlang.org/download.html ): 1. sudo wget http://master.dl.sourceforge.net/project/d-apt/files/d-apt.list -O /etc/apt/sources.list.d/d-apt.list 2. sudo apt-get update && sudo apt-get -y --allow-unauthenticated install --reinstall d-apt-keyring 3. sudo apt-get update && sudo apt-get install dmd-compiler dub Guess what happens on Step 2.
 Err:7 https://netcologne.dl.sourceforge.net/project/d-apt d-apt 
 InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EBCF975E5BA24D5E And this issue was posted a LONG time ago. Yep ... Now try Go, Crystal, Nim, Rust, ... and a lot of other languages. I have installed all those dozens of times and a issue like simply do not show up or are fixed so fast, that it never hits "me". But whenever it involves D, its always one thing or another. ------------------------------ Hopefully this explains things from my point of view, where D simply fails me personally. Its late so i am off to bed.
Sep 28
next sibling parent reply drug <drug2004 bk.ru> writes:
29.09.2019 4:29, Benjiro пишет:
 
 To give you a nice example how much of a irritation D can be even today. 
 Just right now, i tried to install D on Ubuntu because i want to time 
 the current D compile speed, vs a few other languages. And i am 
 following the official order ( https://dlang.org/download.html ):
 
 1. sudo wget 
 http://master.dl.sourceforge.net/project/d-apt/files/d-apt.list -O 
 /etc/apt/sources.list.d/d-apt.list
d-apt isn't the official
 2. sudo apt-get update && sudo apt-get -y --allow-unauthenticated 
 install --reinstall d-apt-keyring
 3. sudo apt-get update && sudo apt-get install dmd-compiler dub
 
 Guess what happens on Step 2.
 
 Err:7 https://netcologne.dl.sourceforge.net/project/d-apt d-apt InRelease
  The following signatures couldn't be verified because the public key is not available:  NO_PUBKEY EBCF975E5BA24D5E
d-apt provides instructions to install this pubkey https://d-apt.sourceforge.io/ " To enable it, add the repository sources: $ sudo wget https://netcologne.dl.sourceforge.net/project/d-apt/files/d-apt.list -O /etc/apt/sources.list.d/d-apt.list then update local info and install "d-apt" public key (fingerprint 0xEBCF975E5BA24D5E): $ sudo apt-get update --allow-insecure-repositories && sudo apt-get -y --allow-unauthenticated install --reinstall d-apt-keyring && sudo apt-get update "
 
 And this issue was posted a LONG time ago.
So there is no issue you are talking about. Probably it's gone
 
 Yep ... Now try Go, Crystal, Nim, Rust, ... and a lot of other 
 languages. I have installed all those dozens of times and a issue like 
 simply do not show up or are fixed so fast, that it never hits "me". But 
 whenever it involves D, its always one thing or another.
 
 ------------------------------
 
 Hopefully this explains things from my point of view, where D simply 
 fails me personally. Its late so i am off to bed.
Did you ask people here to help you? You are welcome!
Sep 29
parent reply Benjiro <benjiro benjiro.com> writes:
On Sunday, 29 September 2019 at 07:43:12 UTC, drug wrote:
 Did you ask people here to help you? You are welcome!
Thanks for your help* ( See PS below ) but fixing the download was not that hard. But for a new user that tries this, it can just as well been Chinese. Its small issues like having a not working download present on the actual official website. It does not matter if its 3th party or not when its posted on the official website. This is why i mentioned before how there are so many frustrations. Its not just the big issues but the constant small issues that are present everywhere.
 You are welcome!
*PS: Next time you write with a exclamation mark, know that this makes your sentence have a totally different meaning and is considered passive aggressive in my region. Its little things like this that seems to pop up everywhere in this community on a regular base. The fact that there are no rules of conduct or any kind of oversight is probably the main reason why people see D as negative community. Even places like Reddit that are toxic, have some kind of moderation going on because people will be people. D, you want my suggestion? Invest into a proper forum, set up a RoC and actually moderate topics. And yes, i understand the irony as i am posting this off-topic in the Nim Language thread. :) This is the first step...
Sep 29
parent reply drug <drug2004 bk.ru> writes:
29.09.2019 13:35, Benjiro пишет:
 On Sunday, 29 September 2019 at 07:43:12 UTC, drug wrote:
 Did you ask people here to help you? You are welcome!
Thanks for your help* ( See PS below ) but fixing the download was not that hard. But for a new user that tries this, it can just as well been Chinese. Its small issues like having a not working download present on the actual official website. It does not matter if its 3th party or not when its posted on the official website.
But I always download dmd from the official site and have no troubles. It works out of box. Your example above is a wrong mix of several ways to install dmd.
 
 This is why i mentioned before how there are so many frustrations. Its 
 not just the big issues but the constant small issues that are present 
 everywhere.
 
 You are welcome!
*PS: Next time you write with a exclamation mark, know that this makes your sentence have a totally different meaning and is considered passive aggressive in my region.
Thank you. Good to know because I'm not native English speaker.
 
 Its little things like this that seems to pop up everywhere in this 
 community on a regular base. The fact that there are no rules of conduct 
 or any kind of oversight is probably the main reason why people see D as 
 negative community. Even places like Reddit that are toxic, have some 
 kind of moderation going on because people will be people.
 
 D, you want my suggestion? Invest into a proper forum, set up a RoC and 
 actually moderate topics. And yes, i understand the irony as i am 
 posting this off-topic in the Nim Language thread. :)
 
 This is the first step...
Yeah, before the D comminity consisted of high professional members who can develop the language. Now when less professional people start appearing here they don't want to implement the features they want by themselves and when they hear 'do it yourself' they start complaining the community is toxic. Not at all. I do not blame these people of course, they are just users of the language not its developer. But it would be nice if they understand the situation.
Sep 29
parent Johannes Pfau <nospam example.com> writes:
Am Sun, 29 Sep 2019 16:01:49 +0300 schrieb drug:

 29.09.2019 13:35, Benjiro пишет:
 On Sunday, 29 September 2019 at 07:43:12 UTC, drug wrote:
 Did you ask people here to help you? You are welcome!
Thanks for your help* ( See PS below ) but fixing the download was not that hard. But for a new user that tries this, it can just as well been Chinese. Its small issues like having a not working download present on the actual official website. It does not matter if its 3th party or not when its posted on the official website.
But I always download dmd from the official site and have no troubles. It works out of box. Your example above is a wrong mix of several ways to install dmd.
 This is why i mentioned before how there are so many frustrations. Its
 not just the big issues but the constant small issues that are present
 everywhere.
 
 You are welcome!
*PS: Next time you write with a exclamation mark, know that this makes your sentence have a totally different meaning and is considered passive aggressive in my region.
Thank you. Good to know because I'm not native English speaker.
 Its little things like this that seems to pop up everywhere in this
 community on a regular base. The fact that there are no rules of
 conduct or any kind of oversight is probably the main reason why people
 see D as negative community. Even places like Reddit that are toxic,
 have some kind of moderation going on because people will be people.
 
 D, you want my suggestion? Invest into a proper forum, set up a RoC and
 actually moderate topics. And yes, i understand the irony as i am
 posting this off-topic in the Nim Language thread. :)
 
 This is the first step...
Yeah, before the D comminity consisted of high professional members who can develop the language. Now when less professional people start appearing here they don't want to implement the features they want by themselves and when they hear 'do it yourself' they start complaining the community is toxic. Not at all. I do not blame these people of course, they are just users of the language not its developer. But it would be nice if they understand the situation.
I think a large part of this shift in the forum discussions is that most constructive, language related discussions have moved to slack. This only leaves the bike-shedding, criticism and trolling here, which seems to have changed the atmostphere a lot. A few years ago, the D community was considered very friendly and open and I think this is still the case when you look at the D.learn forum. So it's not really people who ask questions getting harsh responses, even if a question has been asked a hundred times, people still get good and friendly answers. It's more people demanding things and criticizing unproportionally. This certainly does not justify rude responses, but this seems to be the pattern recently. -- Johannes
Sep 29
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 29 September 2019 at 01:29:59 UTC, Benjiro wrote:
 all i wanted was a god darn simple HTTP server that
 worked and kept working on release updates
lol i wrote one in 2008, and it still works to this day. Very rarely breaks, I have broad forward and backward compatibility with compiler versions. I sometimes wish I actually put in Phobos like Andrei wanted me to back in the day. I just couldn't be bothered; I actually see users as a liability (you cost me time and offer me nothing) so like meh. But still, I hear this complaint over and over again and it really just seems to be a problem with vibe.d rather than the language per se.
Sep 29
prev sibling next sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Sunday, 29 September 2019 at 01:29:59 UTC, Benjiro wrote:
 On Friday, 27 September 2019 at 15:11:26 UTC, GreatSam4sure 
 wrote:
 The biggest problem to D adoption is this community IMHO. 
 Almost everything here is negative. The community is 95% 
 negative to the language. There are people here that never see 
 anything good about D yet they are here. The community is 
 damaging to D image.

 It is a community that is out to destroy the language. All the 
 hope of me using D has been almost destroyed.
As one of these negative people that from time to time reads up on multiple languages forums. D was one of the first languages after moving away from Web dev, that i liked from structure point. Even got the book from Ali. But ... the more i worked with it, the more frustration, upon frustration, upon ... kept creeping in with constant issues. * Not user friendly tooling ( somewhat improved, took only a few years ) * Compiler bugs. O those bugs ... * Upgrading the compiler resulting in packages ( like vibe.d going broke ) * Lacking IDE support ( somewhat improved on Visual Studio Code ) * Lacking in packages to easily get going. * Constant and frustrating changing direction. BetterC? First get BetterD doing and when your a big boy, then do this. * The feeling off being looked down when suggestion that D is not user friendly. Especially in the past you constantly got this as a answer: "you have a issue, fix it yourself". Yes, this was the constant answer from everybody. * The snarky and frankly poison comments from regular members. Some of those now seem to have left but D really has some members that got under anybody their skin for daring to mention a issue. * Focus upon C++ crowd, when very few C++ developers have any interest in D. Hell, if a C++ developer wants to switch, they have better alternatives with bigger or better growing communities. * A leadership that seems to be stuck in the 1990's mentality. The world has moved on, people expect more these days, they have choices most old timers did not have. So they are more spoiled with those choices and are not going to put in the time. But when you ignore those "spoiled" people, you never build up a loyal base and you will never motivate them to help out with code or money. You can not run anything worth while with D unless you plan on spending a lot of time writing supporting code yourself. Some companies have no issue with this but little old me can not be bothered with it, when there are plenty of good alternatives that get the job done as good. * I know one of the posters on this forum a bit more personal. We have had some discussions about the different compilers. Just as he used Go for his personal project, i used Crystal for mine. We both found D too much trouble for the advantages it gave. Its a vicious circle and i know it. Lack in people / contributors => No Packaging / Bugs / Issues => New people scared away => Lack in people / contributors .... * D just is not sexy. I know D now from 10/2016 ( when i got Ali's book. Programming in D ). Loved the book and language syntax ( especially if you come from PHP ) but it was all the rest that ruined it for me. And over the years D seems to have been going down a direction that i hated. New features that had no meaning for me, code breaking issues and resources being put in features like BetterC, when all i wanted was a god darn simple HTTP server that worked and kept working on release updates. And more active packages. * On the subject of Programming in D, i noticed a lot of books are old. BetterC, the feature where a lot of resources have gone into, seems to be ignored in every book on the market. ------------------------------ To give you a nice example how much of a irritation D can be even today. Just right now, i tried to install D on Ubuntu because i want to time the current D compile speed, vs a few other languages. And i am following the official order ( https://dlang.org/download.html ): 1. sudo wget http://master.dl.sourceforge.net/project/d-apt/files/d-apt.list -O /etc/apt/sources.list.d/d-apt.list 2. sudo apt-get update && sudo apt-get -y --allow-unauthenticated install --reinstall d-apt-keyring 3. sudo apt-get update && sudo apt-get install dmd-compiler dub Guess what happens on Step 2.
 Err:7 https://netcologne.dl.sourceforge.net/project/d-apt 
 d-apt InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EBCF975E5BA24D5E And this issue was posted a LONG time ago. Yep ... Now try Go, Crystal, Nim, Rust, ... and a lot of other languages. I have installed all those dozens of times and a issue like simply do not show up or are fixed so fast, that it never hits "me". But whenever it involves D, its always one thing or another. ------------------------------ Hopefully this explains things from my point of view, where D simply fails me personally. Its late so i am off to bed.
+1 Same for me for everything you said. I personally use D only for file processing scripts, first because D is very good at that, but also because this generally (but not always) prevents me from suffering from many of those problems you mentioned.
 * Focus upon C++ crowd, when very few C++ developers have any 
 interest in D. Hell, if a C++ developer wants to switch, they 
 have better alternatives with bigger or better growing 
 communities.
 Its a vicious circle and i know it.

 Lack in people / contributors => No Packaging / Bugs / Issues 
 => New people scared away => Lack in people / contributors ....
 * D just is not sexy. I know D now from 10/2016 ( when i got 
 Ali's book. Programming in D ). Loved the book and language 
 syntax ( especially if you come from PHP ) but it was all the 
 rest that ruined it for me. And over the years D seems to have 
 been going down a direction that i hated. New features that had 
 no meaning for me, code breaking issues and resources being put 
 in features like BetterC, when all i wanted was a god darn 
 simple HTTP server that worked and kept working on release 
 updates. And more active packages.
 Yep ... Now try Go, Crystal, Nim, Rust, ... and a lot of other 
 languages. I have installed all those dozens of times and a 
 issue like simply do not show up or are fixed so fast, that it 
 never hits "me". But whenever it involves D, its always one 
 thing or another.
Very well summarized... I'm a C++ developer myself (even if these days I program mostly in C#), and obviously I'm using D as a better Python/Ruby, not as a better C++. And as a "true" C++ alternative, D is far from being the best choice. I'd rather choose Rust, Zig and even Nim for my typical C/C++ use case, despite indeed it's obviously *possible* to use D for that, precisely because I know D's major pain points. D being garbage collected, I once hope it would embrace the Go/Crystal wagon of those similar languages which have put their focus on web application developement, so that their base library is providing all the required building blocks (coroutines, http, etc) in such a way we can bery easily build our own web frameworks with just a few lines of code. But I now understand that the focus is on "BetterC", not on "BetterGo"...
Sep 29
next sibling parent reply Joakim =?UTF-8?B?QnLDpG5uc3Ryw7Zt?= <notfornow dev.null.com> writes:
On Sunday, 29 September 2019 at 20:39:19 UTC, Ecstatic Coder 
wrote:
 On Sunday, 29 September 2019 at 01:29:59 UTC, Benjiro wrote:
 [...]
+1 Same for me for everything you said. I personally use D only for file processing scripts, first because D is very good at that, but also because this generally (but not always) prevents me from suffering from many of those problems you mentioned.
 [...]
 [...]
 [...]
 [...]
Very well summarized... I'm a C++ developer myself (even if these days I program mostly in C#), and obviously I'm using D as a better Python/Ruby, not as a better C++. And as a "true" C++ alternative, D is far from being the best choice. I'd rather choose Rust, Zig and even Nim for my typical C/C++ use case, despite indeed it's obviously *possible* to use D for that, precisely because I know D's major pain points. D being garbage collected, I once hope it would embrace the Go/Crystal wagon of those similar languages which have put their focus on web application developement, so that their base library is providing all the required building blocks (coroutines, http, etc) in such a way we can bery easily build our own web frameworks with just a few lines of code. But I now understand that the focus is on "BetterC", not on "BetterGo"...
I'll shim in with some positives. I don't find D lacking in any significant way that hinder my work. I use it both privately and at work with great success. It has all the tools I need in the language and I like the improvements I'm seeing, the direction the language is taking. The development of D is mostly done by voluteres which mean that I am grateful for all their time and work. I do not expect much in the way of support or that *they* listen to me. In the same way I do not expect it from any other language I use. The few times I have asked for help there has always been someone that can provide it. Last time it was kinke in fixing an ldc bug (thank you). // Joakim
Sep 29
next sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Sunday, 29 September 2019 at 22:27:40 UTC, Joakim Brännström 
wrote:
 On Sunday, 29 September 2019 at 20:39:19 UTC, Ecstatic Coder 
 wrote:
 On Sunday, 29 September 2019 at 01:29:59 UTC, Benjiro wrote:
 [...]
+1 Same for me for everything you said. I personally use D only for file processing scripts, first because D is very good at that, but also because this generally (but not always) prevents me from suffering from many of those problems you mentioned.
 [...]
 [...]
 [...]
 [...]
Very well summarized... I'm a C++ developer myself (even if these days I program Python/Ruby, not as a better C++. And as a "true" C++ alternative, D is far from being the best choice. I'd rather choose Rust, Zig and even Nim for my typical C/C++ use case, despite indeed it's obviously *possible* to use D for that, precisely because I know D's major pain points. D being garbage collected, I once hope it would embrace the Go/Crystal wagon of those similar languages which have put their focus on web application developement, so that their base library is providing all the required building blocks (coroutines, http, etc) in such a way we can bery easily build our own web frameworks with just a few lines of code. But I now understand that the focus is on "BetterC", not on "BetterGo"...
I'll shim in with some positives. I don't find D lacking in any significant way that hinder my work. I use it both privately and at work with great success. It has all the tools I need in the language and I like the improvements I'm seeing, the direction the language is taking. The development of D is mostly done by voluteres which mean that I am grateful for all their time and work. I do not expect much in the way of support or that *they* listen to me. In the same way I do not expect it from any other language I use. The few times I have asked for help there has always been someone that can provide it. Last time it was kinke in fixing an ldc bug (thank you). // Joakim
Same for me. I'm very grateful to Walter and to the community to have provided me with such a fantastic language. My favorite one actually. Just take a look at my Github account, and this will be obvious to you : https://github.com/senselogic?tab=repositories But as I said, in my opinion, Go and Crystal focus on web application development have their advantages. For instance, I was interested in implementing Cyclone, my CQL/SQL script runner, in D. But I quickly switched to Genesis, my own variant of Go. The code is simple, concise and performant, and use only the default librairies and the official Cassandra and MySQL database drivers : https://github.com/senselogic/CYCLONE/blob/master/cyclone.gs Try porting this to D in the same way, and then tell me if I was wrong to finally choose Go for that specific tool...
Sep 29
prev sibling parent reply JN <666total wp.pl> writes:
On Sunday, 29 September 2019 at 22:27:40 UTC, Joakim Brännström 
wrote:
 The development of D is mostly done by voluteres which mean 
 that I am grateful for all their time and work.
 I do not expect much in the way of support or that *they* 
 listen to me.
 In the same way I do not expect it from any other language I 
 use.
 The few times I have asked for help there has always been 
 someone that can provide it.
 Last time it was kinke in fixing an ldc bug (thank you).

 // Joakim
This is true. However, given that it's a volunteer project, there is room for improvement. If the workforce is limited, it's spread over the language/libraries surface. If we were to minimize that surface, we can have more work done. I think D shouldn't be afraid to cut some of the language features which aren't used much, or have a viable workaround. This way the language would be smaller and easier to maintain/bugfix. Also, smaller language means lesser chance of bugs occuring in the first place. Right now I feel like D is in that weird spot. It's too afraid to cut or rework existing features for language stability, but then is too brave introducing new concepts which weren't battle-tested before. Main issues with D aren't with the specific features, which often came up as a good idea and solve some problem, but the problem is when these features interact with other features. The result is a lot of unexpected interactions (look at any DIP discussion thread, there's always a case of "yeah but this breaks if I have an immutable shared union with alias this"), added cognitive load for the programmer and harder to write generic code.
Sep 30
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 30/09/2019 8:07 PM, JN wrote:
 I think D shouldn't be afraid to cut some of the language features which 
 aren't used much, or have a viable workaround. This way the language 
 would be smaller and easier to maintain/bugfix. Also, smaller language 
 means lesser chance of bugs occuring in the first place. Right now I 
 feel like D is in that weird spot. It's too afraid to cut or rework 
 existing features for language stability, but then is too brave 
 introducing new concepts which weren't battle-tested before.
I.e. hex strings
Sep 30
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Monday, 30 September 2019 at 07:07:34 UTC, JN wrote:

 This is true. However, given that it's a volunteer project, 
 there is room for improvement. If the workforce is limited, 
 it's spread over the language/libraries surface. If we were to 
 minimize that surface, we can have more work done.

 I think D shouldn't be afraid to cut some of the language 
 features which aren't used much, or have a viable workaround. 
 This way the language would be smaller and easier to 
 maintain/bugfix. Also, smaller language means lesser chance of 
 bugs occuring in the first place. Right now I feel like D is in 
 that weird spot. It's too afraid to cut or rework existing 
 features for language stability, but then is too brave 
 introducing new concepts which weren't battle-tested before.

 Main issues with D aren't with the specific features, which 
 often came up as a good idea and solve some problem, but the 
 problem is when these features interact with other features. 
 The result is a lot of unexpected interactions (look at any DIP 
 discussion thread, there's always a case of "yeah but this 
 breaks if I have an immutable shared union with alias this"), 
 added cognitive load for the programmer and harder to write 
 generic code.
I agree. New features are introduced way too fast, often based on the latest CS fashion of the day ("Look here's a paper on...") or "Rust has it, so we need it too!", regardless of whether or not this will break code. Maybe the reason why (ex-)users (including myself) are sometimes so grumpy and negative is that this implicit disregard of users' code makes users feel as if they and their work didn't count at all, yet D complains that there aren't enough users, yeah right. I don't know about others, but when I was still using D actively I would sometimes see discussions on the forum and say "Holy sh*t! Does this mean I'll have to refactor my code once this new feature becomes part of D?" It's like programming on an ejector seat, and after a while I got just sick and tired of it. Nobody wants to live like that forever, not to mention that it is really annoying if you have to go back to old code to "fix" things that shouldn't be broke in the first place. Ah, c'mon. D is 20 years old and still the same criticism pops up again and again and again and the same answers are given: volunteer effort, do it yourself or PFO. Is it the users' or the language leadership's fault I wonder, after 20 years. Hm. D is theoretically in a good position to do a spring cleaning. It has loads of features. Take what really works (battle-tested features), drop all the half-baked features that only a minority really uses. Improve the stability of the language and set up a proper ecosystem (e.g. out of the box compilation for various platforms / architectures). Atm, I'm mainly using Kotlin and I have to say that a small set of clever and well thought-out features can get you a long way. Do I miss some of D's features? Not really, because Kotlin provides enough useful and battle-tested features that you need 90% of the time [1]. Once I missed `static if`, but I could live without it. Mind you, Kotlin has some restrictions due to the fact that it has to be a 100% compatible with Java/JVM. But even when you use Kotlin/Native (without the Java universe, i.e. modules and libraries) you can get quite far. I think D should aim at that. 1. Take D's great features that are battle-tested 2. See what is not strictly necessary and drop it (dead weight), i.e. figure out what programmers need 90-95% of the time and don't pollute the language with features you only need in the remaining 5-10% of the cases. 3. Set up a sound and stable ecosystem But then again, I fear this will never happen.
Sep 30
next sibling parent reply nkm1 <t4nk074 openmailbox.org> writes:
On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
 D is theoretically in a good position to do a spring cleaning. 
 But then again, I fear this will never happen.
But the big one is nogc and all its associated machinery. This is the killer, the biggest source of all the mess. And getting rid of that is not going to happen. Instead you'll see more and more stuff designed to support nogc. Complaining about it is useless. So I personally don't complain, even though I disapprove of this course and consider it the only real strategic mistake in D. This is, of course, assuming that maximising the number of users is the strategic goal. OTOH, all these "f... off, don't whine, do it yourself" on the forum suggest that it's not actually such an important goal. As Adam Ruppe mentioned, more users, more problems. Which is fair enough, so indeed why whine? It just annoys people and provokes trolling.
Sep 30
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 30 September 2019 at 09:57:59 UTC, nkm1 wrote:
 This is, of course, assuming that maximising the number of 
 users is the strategic goal.
Maximizing the number of users should not be the strategic goal. The strategic goal should be to provide a fertile ground for building an eco-system which becomes a strong contender in at least one niche. I can't think of any language that survives without satisfying that requirement. If you try to maximize the number of users you will end up not being particularly good for any particular purpose. Which means that the language is easy to replace with any upcoming generic language. To be a player in that area the ecosystem is even more important than the language: Java, C#, Python etc. Languages like Kotlin very deliberately try to piggyback on an existing eco systems for that reason. This is not to say that languages disappear, programming languages tend to have a long long dwindling trail (Perl, Fortran, Cobol, etc).
Sep 30
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 30 September 2019 at 10:21:42 UTC, Ola Fosheim Grøstad 
wrote:
 This is not to say that languages disappear, programming 
 languages tend to have a long long dwindling trail (Perl, 
 Fortran, Cobol, etc).
tail, not trail...
Sep 30
prev sibling parent reply nkm1 <t4nk074 openmailbox.org> writes:
On Monday, 30 September 2019 at 10:21:42 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 30 September 2019 at 09:57:59 UTC, nkm1 wrote:
 This is, of course, assuming that maximising the number of 
 users is the strategic goal.
Maximizing the number of users should not be the strategic goal. The strategic goal should be to provide a fertile ground for building an eco-system which becomes a strong contender in at least one niche.
That seems more like tactical or operational goal to me... What do you think of Haskell's "avoid success at all costs" or Lua's constant breakage?
Sep 30
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 30 September 2019 at 10:25:56 UTC, nkm1 wrote:
 That seems more like tactical or operational goal to me... What 
 do you think of Haskell's "avoid success at all costs" or Lua's 
 constant breakage?
Haskell is very successful. It completely dominates the niche it was aiming for, a shared language for functional programming researchers. Sure, it lacks some namespace capabilities needed for writing large programs, but that is not needed for research... I am not particularly fond of Lua, but I am not sure that breakage is a problem for an embedded scripting language as you can just stay with a particular version and even fork the language with low cost. You don't need to focus on interop outside your own application. Lua and Python are the two dominating contenders in that niche (embedded scripting engines).
Sep 30
parent reply Eugene Wissner <belka caraus.de> writes:
On Monday, 30 September 2019 at 10:41:21 UTC, Ola Fosheim Grøstad 
wrote:
 Haskell is very successful. It completely dominates the niche 
 it was aiming for, a shared language for functional programming 
 researchers. Sure, it lacks some namespace capabilities needed 
 for writing large programs, but that is not needed for 
 research...
Last time Haskell was a research language was 10 or 15 years ago. There are now better research functional programming languages than Haskell, like Idris or Agda. Haskell is used by industry much more than D, by big corporations as well as start-ups. The thing with Haskell is that it is a dead simple language. There are algebraic data structures, functions, typeclasses, some syntactic sugar and a few compiler extensions. No „alias this“, no structs and classes, no delegates and functions, no loops, no attributes, no function overloading, no casts – well, some of them may be useful for systems programming, but sure not everything. Instead it provides abstractions that can be used in different situations. D (and the most imperative languages) introduce language features for each use case and languages become bloated (particulary if it is a mainstream language). This joke „Avoid success at all cost“ probably means: Don‘t just follow trends, think about features you‘re going to introduce. As result Haskell has great GC and a compiler which is good at optimizing, it doesn‘t have the greatest infrastructure, but at least a set of libraries, you can build almost everything on. The only language I used, that is as buggy as D is Facebook‘s Hacklang. But well, Facebook is known for low quality software. When I first came to D, I thought: Wow, what a nice, simple language. But after some years it isn‘t simple, it gets terribly complicated. Therefore I like Zig‘s slogan: „Focus on debugging your application rather than debugging your programming language knowledge.“ Even the last DIP says: It is the first step, more is coming later. And I‘m 90% sure, it will be never finished. Not because it is D, but because this „I finish it later“ just never works in engeneering. And this kind of things just doesn‘t happen anymore to Haskell (or at least not to the same extent).
Sep 30
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 30 September 2019 at 16:39:22 UTC, Eugene Wissner 
wrote:
 Last time Haskell was a research language was 10 or 15 years 
 ago. There are now better research functional programming 
 languages than Haskell, like Idris or Agda. Haskell is used by 
 industry much more than D, by big corporations as well as 
 start-ups.
Alright then, in my mind languages like Haskell and ML will always primarily be academic PL references, although they also have commercial applications. Anyway, both Haskell and ML are successful considering the use context they evolved in.
 As result Haskell has great GC and a compiler which is good at 
 optimizing, it doesn‘t have the greatest infrastructure, but at 
 least a set of libraries, you can build almost everything on.
Right, I am not a Haskell programmer, but I think the naming of some functions are odd, although I understand that there are historic FP traditions that has led to it. It does bring with it FP-cultural baggage... It could do better from a usability point of view.
 Even the last DIP says: It is the first step, more is coming 
 later. And I‘m 90% sure, it will be never finished. Not because 
 it is D, but because this „I finish it later“ just never works 
 in engeneering. And this kind of things just doesn‘t happen 
 anymore to Haskell (or at least not to the same extent).
It is not a good idea in software in general, considering that common wisdom says that initial development is only 10% of the overall life-time-costs. If you keep pushing forward without completing existing features I think the ratio will be a lot worse...
Sep 30
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Monday, 30 September 2019 at 09:57:59 UTC, nkm1 wrote:
 On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
 D is theoretically in a good position to do a spring cleaning. 
 But then again, I fear this will never happen.
But the big one is nogc and all its associated machinery. This is the killer, the biggest source of all the mess. And getting rid of that is not going to happen. Instead you'll see more and more stuff designed to support nogc. Complaining about it is useless. So I personally don't complain, even though I disapprove of this course and consider it the only real strategic mistake in D. This is, of course, assuming that maximising the number of users is the strategic goal. OTOH, all these "f... off, don't whine, do it yourself" on the forum suggest that it's not actually such an important goal. As Adam Ruppe mentioned, more users, more problems. Which is fair enough, so indeed why whine? It just annoys people and provokes trolling.
Whine: "3. To complain or protest with a whine or as if with a whine." [1]. "Whining" is not constructive and does not propose any solution. However, _a lot of people_ criticizing D over the years have done so suggesting concrete solutions, and yet they have consistently been labelled as "whiners" or "trolls". If it's true that the D leadership and enthusiasts are not interested in users (and everything hints at that), then why do they complain about "negativity that hinders adoption of D"? Wanna have your cake and eat it? That's a rather schizophrenic attitude: "Don't put off users, but to hell with them, we don't give a damn about users anyway!" Ironically, the D leadership are the real whiners, they've been complaining about low adoption rates for years, and yet treat their target group like unworthy worms. Not a good way to sell a product. Yeah, no, I do wonder why D is not more popular. You're basically saying that there's no cure for D and that it's is beyond hope. I wish the D leadership finally published a statement to this effect on dlang.org. Something like "D is a volunteer effort and serves no purpose other than playing around with features and ideas. It ships with no guarantees of stability or backward compatibility as we pretty much do what we please. Use at your own peril. Complaints will be ignored." [1] https://en.wiktionary.org/wiki/whine
Sep 30
prev sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 30 September 2019 at 09:57:59 UTC, nkm1 wrote:
 On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
 D is theoretically in a good position to do a spring cleaning. 
 But then again, I fear this will never happen.
But the big one is nogc and all its associated machinery. This is the killer, the biggest source of all the mess. And getting rid of that is not going to happen. Instead you'll see more and more stuff designed to support nogc. Complaining about it is useless. So I personally don't complain, even though I disapprove of this course and consider it the only real strategic mistake in D. This is, of course, assuming that maximising the number of users is the strategic goal. OTOH, all these "f... off, don't whine, do it yourself" on the forum suggest that it's not actually such an important goal. As Adam Ruppe mentioned, more users, more problems. Which is fair enough, so indeed why whine? It just annoys people and provokes trolling.
I though this thread was about Nim. Nim hit 1.0 which I think is great because we need alternative systems languages. Instead this thread becomes some kind of panic for the D community because Nim advances and many think D doesn't. The whining is good because it shows that people use the language. What I think is obvious is that many posts seems to complain about the something undefined or that D hasn't become more popular in general. It would be easier if you were more specific about the the deficiencies of D. A lot of negativism while C++ is committing harakiri. One obvious future of D is services inside Linux embedded systems. Recently I was working on a project with web client SW inside a Linux system. The project used C++17 and the code was horrible (also from an aesthetic point of view which cannot be solved), unmaintainable with concurrency bugs waiting to happen. Also C++17 doesn't come with any obvious libraries for this so you have to hunt these down too with licenses that fits and these libraries are often horrible. I did a small test and wrote a portion of the the service in D and the difference was astonishing. First D offers more and better libraries out of the box and addition to that D has Vibe. The code became much more readable and consistent. Memory leakages are gone because of GC (don't hate GC, it is great for most use cases). Some language is going to take that place from C++ and it could several and D is placed in a pretty good spot here. Nim terms of libraries Nim is also a C++ replacement for these kind of use cases, however what I've seen is that the libraries/interfaces are more immature. Rust is the most competitive contender but as complicated Rust can be D can really be an option here. Most companies want a solution quickly and with good quality and D could provide this fast path. For my next project, I will suggest using D instead for those kinds of services. I don't mind GC that much but removing GC from Phobos isn't bad either so the priority is not that high for me. Could someone please explain why nogc is a priority. What I think is one high priority is to get reference counted GC in D because that opens up D for the performance crowd who do not want stop the world GC. Look at the possibilities instead.
Sep 30
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 30 September 2019 at 11:05:58 UTC, IGotD- wrote:
 A lot of negativism while C++ is committing harakiri. One 
 obvious future of D is services inside Linux embedded systems.
That is certainly an option, you might be able build a community around the Linux embedded niche.
 Vibe. The code became much more readable and consistent. Memory 
 leakages are gone because of GC (don't hate GC, it is great for 
 most use cases).
But you can not rely on GC on small embedded systems. Even allocators that doesn't combat fragmentation is a relevant issue. So if embedded is a target niche then such runtime features must be addressed. If not, why would a project manager pick D over Go (beyond syntax preferences)?
 libraries/interfaces are more immature. Rust is the most 
 competitive contender but as complicated Rust can be D can 
 really be an option here.
But D does not provide the same memory management capabilities of Rust. Rust would be the stronger contender if GC isn't an option, and in that case D does not have a comparable memory management solution.
 What I think is one high priority is to get reference counted 
 GC in D because that opens up D for the performance crowd who 
 do not want stop the world GC.
Well, ref counting is too slow for the performance crowd, but it is better for predictable execution and limited memory usage than a GC. Which in some embedded contexts might be sufficient. If embedded is the main target niche then you would want clean and flexible features related to stack allocation and automatic proving upper bounds on stack size. Such features could make any reasonable language a strong contender in this niche. Being generic isn't sufficient to be a strong contender in specialized niches.
Sep 30
parent IGotD- <nise nise.com> writes:
On Monday, 30 September 2019 at 11:40:01 UTC, Ola Fosheim Grøstad 
wrote:
 But you can not rely on GC on small embedded systems. Even 
 allocators that doesn't combat fragmentation is a relevant 
 issue.

 So if embedded is a target niche then such runtime features 
 must be addressed.

 If not, why would a project manager pick D over Go (beyond 
 syntax preferences)?
Bare metal or small embedded systems with a limited OS you cannot often use the standard library anyway. That's often the case with C as well unless you port the clib standard calls which is unusual. Often you have to work with proprietary APIs anyway. For OS agnostic D libraries it makes sense to remove any GC support but for OS related libraries it doesn't matter much as you almost always have some custom API. Go is probably one of the worst choices for bare metal as it relies on a runtime. D has betterC which makes it more suitable for bare metal. Right now I think betterC is a bit limited and I would actually like to see this part expanded, like full class support for example.
Sep 30
prev sibling parent reply JN <666total wp.pl> writes:
On Monday, 30 September 2019 at 11:05:58 UTC, IGotD- wrote:
 I though this thread was about Nim. Nim hit 1.0 which I think 
 is great because we need alternative systems languages. Instead 
 this thread becomes some kind of panic for the D community 
 because Nim advances and many think D doesn't.
While I don't fully subscribe to the language war theory, I don't see Nim as any competition. I just don't see anything going on for Nim right now. I expect it will linger on the same level of popularity as say Pascal, with some dedicated community, support in most online compiler tools, some IDE plugins, but nothing else. Even compared to D... I just don't see Nim ever going big
 libraries/interfaces are more immature. Rust is the most 
 competitive contender but as complicated Rust can be D can 
 really be an option here. Most companies want a solution 
 quickly and with good quality and D could provide this fast 
 path. For my next project, I will suggest using D instead for 
 those kinds of services.
Many people mistakenly assume Rust's popularity comes down to borrow checker & memory safety features. But it is just a bonus. Most of the Rust's popularity comes from active community and good language focus. Lack of language runtime is a plus too, because it makes it a very good language for targeting embedded/WebAssembly.
 I don't mind GC that much but removing GC from Phobos isn't bad 
 either so the priority is not that high for me. Could someone 
 please explain why  nogc is a priority. What I think is one 
 high priority is to get reference counted GC in D because that 
 opens up D for the performance crowd who do not want stop the 
 world GC.
I think no matter what you do, C++ folks will complain. They're just triggered by the word GC. That's why every single discussion thread about D outside of this forums starts at the GC. Then someone will mention nogc or refcounting. Then someone will chime in about how you lose most of the packages and standard library because it assumes GC is present. And then people will just go "oh man, that is so complicated".
Sep 30
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 30 September 2019 at 16:47:51 UTC, JN wrote:
 Many people mistakenly assume Rust's popularity comes down to 
 borrow checker & memory safety features. But it is just a 
 bonus. Most of the Rust's popularity comes from active 
 community and good language focus. Lack of language runtime is 
 a plus too, because it makes it a very good language for 
 targeting embedded/WebAssembly.
Probably true, but I think Rust is the hipster language of imperative languages. The fact that they had a fairly active community before it was usable says something, I think. That hipster-factor came from referencing advanced type theory (the theoretical foundation for the borrow checker) and also providing a ML-ish academicish syntax. C++/D is bread-and-butter in comparison
 And then people will just go "oh man, that is so complicated".
Memory management ought to be integrated into the language semantics and not delegated to libraries though. Otherwise it quickly becomes complicated for the programmer... So, that is a weakness that C++ and D shares.
Sep 30
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 30, 2019 at 04:47:51PM +0000, JN via Digitalmars-d wrote:
[...]
 I think no matter what you do, C++ folks will complain. They're just
 triggered by the word GC. That's why every single discussion thread
 about D outside of this forums starts at the GC. Then someone will
 mention  nogc or refcounting. Then someone will chime in about how you
 lose most of the packages and standard library because it assumes GC
 is present. And then people will just go "oh man, that is so
 complicated".
+1 LOL, that's totally how such discussions tend to go. It's just like Walter himself has said on several occasions. Why bend over backwards to please the non-adopting crowds who will just move on to the next excuse not to use D once you've addressed their current complaint? Rather, we should be concerned about making *existing* users happier -- and there's no shortage of action items there. T -- Unix is my IDE. -- Justin Whear
Sep 30
next sibling parent Chris <wendlec tcd.ie> writes:
On Monday, 30 September 2019 at 18:41:07 UTC, H. S. Teoh wrote:
 It's just like Walter himself has said on several occasions. 
 Why bend over backwards to please the non-adopting crowds who 
 will just move on to the next excuse not to use D once you've 
 addressed their current complaint? Rather, we should be 
 concerned about making *existing* users happier -- and there's 
 no shortage of action items there.


 T
How do you reconcile that with people leaving D again? Anyway, there are two things in the statement above: 1. Walter admits that D only caters for a few users with very specific use cases (niches). There's nothing wrong with that, but please state it _publicly_ on dlang.org. Of course people will be p****d off when they are sold one thing (general purpose language), only to find out later that they don't count at all, that D is only for the "chosen few". Also, the "chosen few" shouldn't go on about how great things are with D, of course it's great for _them_, because they get their pet features implemented. 2. Given 1., it makes even less sense that D is such a mess. If you have a small target audience with a more or less small set of requirements, then D could focus on that and have a sound and compact language for special purposes. In other words, D fails in both ways. It disregards the ordinary programmer, but it doesn't provide its pet users (the "chosen few") with a sound and stable language either. So what is D all about then?
Oct 01
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Monday, 30 September 2019 at 18:41:07 UTC, H. S. Teoh wrote:
 It's just like Walter himself has said on several occasions. 
 Why bend over backwards to please the non-adopting crowds who 
 will just move on to the next excuse not to use D once you've 
 addressed their current complaint? Rather, we should be 
 concerned about making *existing* users happier -- and there's 
 no shortage of action items there.


 T
How do you reconcile that with people leaving D again? Anyway, there are two things in the statement above: 1. Walter admits that D only caters for a few users with very specific use cases (niches). There's nothing wrong with that, but please state it _publicly_ on dlang.org. Of course people will be p****d off when they are sold one thing (general purpose language), only to find out later that they don't count at all, that D is only for the "chosen few". Also, the "chosen few" shouldn't go on about how great things are with D, of course it's great for _them_, because they get their pet features implemented. 2. Given 1., it makes even less sense that D is such a mess. If you have a small target audience with a more or less small set of requirements, then D could focus on that and have a sound and compact language for special purposes. In other words, D fails in both ways. It disregards the ordinary programmer, but it doesn't provide its pet users (the "chosen few") with a sound and stable language either. So what is D all about then?
Oct 01
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 October 2019 at 08:47:19 UTC, Chris wrote:
 1. Walter admits that D only caters for a few users with very 
 specific use cases (niches).
Which niches are these? My impression is that D primarily caters for users that want the feature-set of C++, but find C++ to be too inconvenient or complicated.
Oct 01
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 1 October 2019 at 10:05:31 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 1 October 2019 at 08:47:19 UTC, Chris wrote:
 1. Walter admits that D only caters for a few users with very 
 specific use cases (niches).
Which niches are these? My impression is that D primarily caters for users that want the feature-set of C++, but find C++ to be too inconvenient or complicated.
Look at the companies listed here: https://dlang.org/orgs-using-d.html and the posters who say "everything's great" often work for one of those companies. Weka.io and Symmetry come to mind. It's mostly real time (e.g. Funkwerk, sociomantic) and high throughput stuff (Weka.io etc.). It's mostly cloud / server based (that's why mobile is regarded unimportant). This is perfectly fine, if that's what D wants, but please be clear about it. I think what puts people off is that D is advertised as a general purpose "best language in the world", but is in fact a special interest niche language. Imo, it's this dishonesty that is at the heart of a lot of discontent and rants on this forum, and misunderstandings. Of course, an engineer who works on cloud based real time systems will not (care to) understand the frustrations of a team that wants to make their D program available on Android and iOS. If you look at the list of organizations above, it makes perfect sense why certain aspects - that any modern language needs nowadays - are neglected: mobile (cf. mostly cloud based users), proper tooling (cf. carefully crafted internal tooling in each organization). It calls my attention, though, that at Mercedes-Benz R&D "D is used for software development tools." Apparently, they're not yet convinced, and if you look at the other organizations above, they can afford to use a highly specialized, exotic language like D, because they're not too big and use it for very specific tasks. But once things get bigger, e.g. Mercedes-Benz, the company starts to tread more carefully.
Oct 01
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 October 2019 at 10:43:24 UTC, Chris wrote:
 On Tuesday, 1 October 2019 at 10:05:31 UTC, Ola Fosheim Grøstad 
 wrote:
 Which niches are these?
[...]
 Look at the companies listed here:

 https://dlang.org/orgs-using-d.html

 and the posters who say "everything's great" often work for one 
 of those companies. Weka.io and Symmetry come to mind. It's 
 mostly real time (e.g. Funkwerk, sociomantic) and high 
 throughput stuff (Weka.io etc.). It's mostly cloud / server 
 based (that's why mobile is regarded unimportant). This is 
 perfectly fine, if that's what D wants, but please be clear 
 about it.
That list is a bit difficult to assess as some of the companies have not moved forward with the language, but doesn't some of the those that have gone with D wholesale use their own runtimes? But yes, real time seems to be a niche with some adoption. Batch-dataprocessing seems to be a niche (I assume this accounts for situations where developers have failed to bring Python or other high level language up to the performance they wanted). But there isn't really many features in the language that makes it particularly well suited for real time or dataprocessing. It is mostly on the library/runtime level. So my current impression, from that list, is that there is no particular niche where it is the best option. There is not enough adoption in any particular niche IMO. (Compared to other "new" languages that have significant growth.)
 It calls my attention, though, that at Mercedes-Benz R&D "D is 
 used for software development tools." Apparently, they're not 
 yet convinced, and if you look at the other organizations 
 above, they can afford to use a highly specialized, exotic 
 language like D, because they're not too big and use it for 
 very specific tasks. But once things get bigger, e.g. 
 Mercedes-Benz, the company starts to tread more carefully.
Right, what it suggests is that Mercedes-Benz R&D don't see any obvious solution for what they want to do, so they look at smaller languages. Then they will try it for some task, but the acid test is if they expand as they go forward. Although, I do suspect that many people/managers tend to be inclined to try out languages that looks (syntax and feature wise) like something they already know. So if they look for something C-like it doesn't really tell us much about whether a more esoteric language like Rust would be "better" or "worse" for the task they try to solve. So that Rust is expanding in some niches despite having a syntax that is alien to many makes me more confident that they are carving a niche of their own. It is more difficult to make this argument for languages like Nim and D.
Oct 02
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
Or to phrase it differently:

In  which niche can Nim or D hope to obtain 1% market share of 
within 10 years?

Which niches are out of reach?

Clearly, web, iOS, Android are all out of reach. But maybe there 
are some other niches where a focused effort could lead to 
market-capturing progress.

What would have to change (in terms of technology) to increase 
the probability of capturing one such market?
Oct 02
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 2 October 2019 at 10:16:45 UTC, Ola Fosheim Grøstad 
wrote:
 Or to phrase it differently:

 In  which niche can Nim or D hope to obtain 1% market share of 
 within 10 years?
Pew! That's a tough one.
 Which niches are out of reach?

 Clearly, web, iOS, Android are all out of reach. But maybe 
 there are some other niches where a focused effort could lead 
 to market-capturing progress.
I wouldn't write off Nim here. Nim could be an option for iOS and Android development if you can compile it to C libs or some sort of OS specific format.
 What would have to change (in terms of technology) to increase 
 the probability of capturing one such market?
Something like GraalVM? Write in any language you like and you can interact with any language you like, but I don't really see it for D. Nim, perhaps. I don't know.
Oct 02
next sibling parent reply Rel <relmail rambler.ru> writes:
On Wednesday, 2 October 2019 at 11:12:29 UTC, Chris wrote:
 On Wednesday, 2 October 2019 at 10:16:45 UTC, Ola Fosheim 
 Grøstad wrote:
 Or to phrase it differently:

 In  which niche can Nim or D hope to obtain 1% market share of 
 within 10 years?
Pew! That's a tough one.
 Which niches are out of reach?

 Clearly, web, iOS, Android are all out of reach. But maybe 
 there are some other niches where a focused effort could lead 
 to market-capturing progress.
I wouldn't write off Nim here. Nim could be an option for iOS and Android development if you can compile it to C libs or some sort of OS specific format.
 What would have to change (in terms of technology) to increase 
 the probability of capturing one such market?
Something like GraalVM? Write in any language you like and you can interact with any language you like, but I don't really see it for D. Nim, perhaps. I don't know.
Actually Nim may be pretty fine for web as it compiles to JS as well. I believe that they have a full stack framework already, where you do both backend and frontend in Nim.
Oct 02
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 2 October 2019 at 12:43:30 UTC, Rel wrote:
 I wouldn't write off Nim here. Nim could be an option for iOS 
 and Android development if you can compile it to C libs or 
 some sort of OS specific format.

 What would have to change (in terms of technology) to 
 increase the probability of capturing one such market?
Something like GraalVM? Write in any language you like and you can interact with any language you like, but I don't really see it for D. Nim, perhaps. I don't know.
Actually Nim may be pretty fine for web as it compiles to JS as well. I believe that they have a full stack framework already, where you do both backend and frontend in Nim.
I wouldn't write off Nim here either. Nim has the benefit of being "young", so they've been able to see and adapt to the latest developments (e.g. web client + server, JS etc.).
Oct 02
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 2 October 2019 at 12:53:49 UTC, Chris wrote:
 On Wednesday, 2 October 2019 at 12:43:30 UTC, Rel wrote:
 I wouldn't write off Nim here. Nim could be an option for iOS 
 and Android development if you can compile it to C libs or 
 some sort of OS specific format.

 What would have to change (in terms of technology) to 
 increase the probability of capturing one such market?
Something like GraalVM? Write in any language you like and you can interact with any language you like, but I don't really see it for D. Nim, perhaps. I don't know.
Actually Nim may be pretty fine for web as it compiles to JS as well. I believe that they have a full stack framework already, where you do both backend and frontend in Nim.
I wouldn't write off Nim here either. Nim has the benefit of being "young", so they've been able to see and adapt to the latest developments (e.g. web client + server, JS etc.).
Nim seems to also be plagued by Rust envy, so not sure about it. Thanks to http://pling.jondgoodwin.com/post/cyclone/ I arrived to https://github.com/nim-lang/RFCs/issues/144 The comments regarding dropping GC and mixed mode libraries will feel remarkably familiar.
Oct 02
parent Chris <wendlec tcd.ie> writes:
On Wednesday, 2 October 2019 at 13:45:46 UTC, Paulo Pinto wrote:
 Nim seems to also be plagued by Rust envy, so not sure about it.

 Thanks to http://pling.jondgoodwin.com/post/cyclone/ I arrived 
 to https://github.com/nim-lang/RFCs/issues/144

 The comments regarding dropping GC and mixed mode libraries 
 will feel remarkably familiar.
Hope Nim devs have learned their lesson from D.
Oct 02
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 2 October 2019 at 11:12:29 UTC, Chris wrote:
 I wouldn't write off Nim here. Nim could be an option for iOS 
 and Android development if you can compile it to C libs or some 
 sort of OS specific format.
That is a very good point. If you can compile to C or C++ then you can become part of most existing build chains (as a specialized tool) with limited effort.
Oct 02
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 2 October 2019 at 10:10:56 UTC, Ola Fosheim Grøstad 
wrote:

 That list is a bit difficult to assess as some of the companies 
 have not moved forward with the language, but doesn't some of 
 the those that have gone with D wholesale use their own 
 runtimes?
I don't know, but I'm sure they have carefully crafted special purpose tooling around their D code (else you cannot work with D anyway).
 But yes, real time seems to be a niche with some adoption. 
 Batch-dataprocessing seems to be a niche (I assume this 
 accounts for situations where developers have failed to bring 
 Python or other high level language up to the performance they 
 wanted).
 But there isn't really many features in the language that makes 
 it particularly well suited for real time or dataprocessing. It 
 is mostly on the library/runtime level.
I suppose it's because it's easier to write in D than C/C++ (productivity) and the native performance gave them an edge over companies that use(d) Python for data analysis. D, like Python, is good for fast prototyping and, unlike Python, it is quite fast. But does it really scale? [...]
 Right, what it suggests is that  Mercedes-Benz R&D  don't see 
 any obvious solution for what they want to do, so they look at 
 smaller languages. Then they will try it for some task, but the 
 acid test is if they expand as they go forward.
Apparently, Facebook has dropped active D development. I'm always skeptical when I hear "X is using D now." People often say that D needs a big player behind it, but the big players actually have to be very careful with exotic languages. If it doesn't scale, they cannot use it. It's not that they're all knobs adopting the latest hipster fashion or sticking to old technologies. They simply cannot risk to be stuck with an exotic language. Smaller organizations that operate within very special scenarios can afford to use D and it might give them an edge over their competitors. But that doesn't mean D is a good choice per se, and keep in mind that for standard technologies like XML parsing and the like they might still rely on battle-tested libraries written in C/C++.
Oct 02
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 2 October 2019 at 11:00:41 UTC, Chris wrote:
 I don't know, but I'm sure they have carefully crafted special 
 purpose tooling around their D code (else you cannot work with 
 D anyway).
That is the impression I am getting.
 Apparently, Facebook has dropped active D development. I'm 
 always skeptical when I hear "X is using D now." People often 
 say that D needs a big player behind it, but the big players 
 actually have to be very careful with exotic languages. If it 
 doesn't scale, they cannot use it. It's not that they're all 
 knobs adopting the latest hipster fashion or sticking to old 
 technologies. They simply cannot risk to be stuck with an 
 exotic language.
Right, most larger companies have used multiple languages, but there is a big difference between trying out a new tool on some smaller projects and going for it for larger critical applications.
 Smaller organizations that operate within very special 
 scenarios can afford to use D and it might give them an edge 
 over their competitors.
Startups is not the best canary as startups have less risk-aversion and technology choices are more influenced by the preferences of the initial staff. They usually don't have enough experience with the task at hand when they start out to properly evaluate the tradeoffs, although since they often are cash-restricted they might go with what they think is the cheaper alternative (or "productivity" as you mentioned). How that works out is difficult to assess. No (sane) company will speak in negative terms about their tech-choices publicly of course, as it would undermine themselves in terms of PR. Thus it is also very difficult to assess what they say (they tend to speak positively about the tech they choose) and one has to assess how they expand into the tech platform as time goes on.
Oct 02
next sibling parent reply Rel <relmail rambler.ru> writes:
On Wednesday, 2 October 2019 at 21:31:17 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 2 October 2019 at 11:00:41 UTC, Chris wrote:
 I don't know, but I'm sure they have carefully crafted special 
 purpose tooling around their D code (else you cannot work with 
 D anyway).
That is the impression I am getting.
 Apparently, Facebook has dropped active D development. I'm 
 always skeptical when I hear "X is using D now." People often 
 say that D needs a big player behind it, but the big players 
 actually have to be very careful with exotic languages. If it 
 doesn't scale, they cannot use it. It's not that they're all 
 knobs adopting the latest hipster fashion or sticking to old 
 technologies. They simply cannot risk to be stuck with an 
 exotic language.
Right, most larger companies have used multiple languages, but there is a big difference between trying out a new tool on some smaller projects and going for it for larger critical applications.
 Smaller organizations that operate within very special 
 scenarios can afford to use D and it might give them an edge 
 over their competitors.
Startups is not the best canary as startups have less risk-aversion and technology choices are more influenced by the preferences of the initial staff. They usually don't have enough experience with the task at hand when they start out to properly evaluate the tradeoffs, although since they often are cash-restricted they might go with what they think is the cheaper alternative (or "productivity" as you mentioned). How that works out is difficult to assess. No (sane) company will speak in negative terms about their tech-choices publicly of course, as it would undermine themselves in terms of PR. Thus it is also very difficult to assess what they say (they tend to speak positively about the tech they choose) and one has to assess how they expand into the tech platform as time goes on.
As for startups I really like NoRedInk's story, who started with Ruby and React and eventually gradually switched to Haskell and Elm and never looked back. There are few talks on YouTube by Richard Feldman about this story, which is kinda interesting.
Oct 03
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 3 October 2019 at 07:19:52 UTC, Rel wrote:
 As for startups I really like NoRedInk's story, who started 
 with Ruby and React and eventually gradually switched to 
 Haskell and Elm and never looked back. There are few talks on
That sounds interesting, transitioning to a functional programming setup from Ruby and React. I assume that they use a database backend that works well with FP to then.
Oct 03
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 2 October 2019 at 21:31:17 UTC, Ola Fosheim Grøstad 
wrote:
 Startups is not the best canary as startups have less 
 risk-aversion and technology choices are more influenced by the 
 preferences of the initial staff. They usually don't have 
 enough experience with the task at hand when they start out to 
 properly evaluate the tradeoffs, although since they often are 
 cash-restricted they might go with what they think is the 
 cheaper alternative (or "productivity" as you mentioned). How 
 that works out is difficult to assess. No (sane) company will 
 speak in negative terms about their tech-choices publicly of 
 course, as it would undermine themselves in terms of PR. Thus 
 it is also very difficult to assess what they say (they tend to 
 speak positively about the tech they choose) and one has to 
 assess how they expand into the tech platform as time goes on.
True, true. We never hear about "X dropped D", it's more like "X has command line tool in D now!" Wow! ;) But now that you say that, that might also be the reason for the "Everything's grand, would you PFO !" posts on this forum by people who built their organization / product around D. What if potential investors or clients hear that the technology they're using doesn't scale very well - "scale" as in expansion? The initial "advantage" might come back to bite them once they wanna scale up. As for the big players, I can imagine that they like to play around with D to develop prototypes fast, and then see what other languages they can use to implement the real-world application. A language with a proper and healthy ecosystem. Python is often used for prototyping too, and then the real app is written in C++. This begs the question, is D becoming a native Python?
Oct 03
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2019-10-03 at 08:20 +0000, Chris via Digitalmars-d wrote:
 [=E2=80=A6]
 language with a proper and healthy ecosystem. Python is often=20
 used for prototyping too, and then the real app is written in=20
 C++. This begs the question, is D becoming a native Python?
Wasn't one of the starting points of Nim to be a native Python? (In the sam= e way Crystal is a native Ruby.) --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Oct 03
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 09:03:10 UTC, Russel Winder wrote:

 Wasn't one of the starting points of Nim to be a native Python? 
 (In the same way Crystal is a native Ruby.)
With the difference that Nim has the potential to become a native Python with all that's involved, i.e. rich ecosystem a la Python. But I think it can become much more than that. If you can compile it to C libs then it can become part of many things (mobile, embedded, gaming etc.) Personally, I'd love to see scientists and the like to use Nim instead of Python so you can use their code for production (more or less) immediately.
Oct 03
parent reply LocoDelPueblo <fdp-dyna-hum nowhere.mx> writes:
On Thursday, 3 October 2019 at 09:13:37 UTC, Chris wrote:
 On Thursday, 3 October 2019 at 09:03:10 UTC, Russel Winder 
 wrote:

 Wasn't one of the starting points of Nim to be a native 
 Python? (In the same way Crystal is a native Ruby.)
With the difference that Nim has the potential to become a native Python with all that's involved, i.e. rich ecosystem a la Python. But I think it can become much more than that. If you can compile it to C libs then it can become part of many things (mobile, embedded, gaming etc.) Personally, I'd love to see scientists and the like to use Nim instead of Python so you can use their code for production (more or less) immediately.
Problem is also that people using python don't want to be programmers... they just do stuff in python, and sometimes these stuff become mainstream. So if the idea is to say "use Nim instead of python" you basically kill the "why" the python stuff started being widely used and developed. You fallback in the "no-way" again. I've observed this again two days ago where the UI of for a command line app required python-qt. The application could have been made in cpp, easily, but you know the authors just wanted to make their stuff...but now this ui is available on most linux distribs, no matter the way it's made.
Oct 03
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 09:36:17 UTC, LocoDelPueblo wrote:
 Problem is also that people using python don't want to be 
 programmers... they just do stuff in python, and sometimes 
 these stuff become mainstream. So if the idea is to say "use 
 Nim instead of python" you basically kill the "why" the python 
 stuff started being widely used and developed. You fallback in 
 the "no-way" again.

 I've observed this again two days ago where the UI of for a 
 command line app required python-qt. The application could have 
 been made in cpp, easily, but you know the authors just wanted 
 to make their stuff...but now this ui is available on most 
 linux distribs, no matter the way it's made.
You have a point there. But the good thing about Nim is that you can generate C, C++ and Objective-C: https://nim-lang.org/docs/backends.html This can be done by the developer who works on the actual product. The scientist (or whoever develops the prototype) can do so in Python-like Nim, and then the dev ports or incorporates it with a compiler switch. Say you have great code in Nim and you wanna make an Android or iOS app. Just convert it to C or C++ and compile it for the mobile platform. I've never tried this in practice, but it sounds promising.
Oct 03
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 09:49:57 UTC, Chris wrote:
 You have a point there. But the good thing about Nim is that 
 you can generate C, C++ and Objective-C:

 https://nim-lang.org/docs/backends.html

 This can be done by the developer who works on the actual 
 product. The scientist (or whoever develops the prototype) can 
 do so in Python-like Nim, and then the dev ports or 
 incorporates it with a compiler switch. Say you have great code 
 in Nim and you wanna make an Android or iOS app. Just convert 
 it to C or C++ and compile it for the mobile platform. I've 
 never tried this in practice, but it sounds promising.
Not bad at all: https://nim-lang.org/docs/nimc.html#cross-compilation-for-android https://nim-lang.org/docs/nimc.html#cross-compilation-for-ios
Oct 03
parent reply LocoDelPueblo <fdp-dyna-hum nowhere.mx> writes:
On Thursday, 3 October 2019 at 10:15:49 UTC, Chris wrote:
 On Thursday, 3 October 2019 at 09:49:57 UTC, Chris wrote:
 You have a point there. But the good thing about Nim is that 
 you can generate C, C++ and Objective-C:

 https://nim-lang.org/docs/backends.html

 This can be done by the developer who works on the actual 
 product. The scientist (or whoever develops the prototype) can 
 do so in Python-like Nim, and then the dev ports or 
 incorporates it with a compiler switch. Say you have great 
 code in Nim and you wanna make an Android or iOS app. Just 
 convert it to C or C++ and compile it for the mobile platform. 
 I've never tried this in practice, but it sounds promising.
Not bad at all: https://nim-lang.org/docs/nimc.html#cross-compilation-for-android https://nim-lang.org/docs/nimc.html#cross-compilation-for-ios
My comment earlier was more on the fact that some said that Nim can be seen as a better python, just like D was sold as a better C or C++. It will work to some extant. But what will work, will it work because of the strategy ? I think that a good example for D is the TSV tools. It works and is recognized because it's a serious project, tested, benchmarked, etc. I'm not even sure that the company the author works at plays **that** an important role. The titled terminal made in D, also very popular, but made by a non corporate developer tends to confirm this. The strategy of "Y is a better X" is to make people moving from X to Y. So far in D successes are not movers, it's new projects, corporate or not.
Oct 03
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 10:49:47 UTC, LocoDelPueblo wrote:
 My comment earlier was more on the fact that some said that Nim 
 can be seen as a better python, just like D was sold as a 
 better C or C++. It will work to some extant. But what will 
 work, will it work because of the strategy ?

 I think that a good example for D is the TSV tools. It works 
 and is recognized because it's a serious project, tested, 
 benchmarked, etc. I'm not even sure that the company the author 
 works at plays **that** an important role. The titled terminal 
 made in D, also very popular, but made by a non corporate 
 developer tends to confirm this.

 The strategy of "Y is a better X" is to make people moving from 
 X to Y. So far in D successes are not movers, it's new 
 projects, corporate or not.
A big project, say a huge data mining / processing framework, would definitely help Nim and Python programmers are already familiar with the syntax. But there are other reasons why languages become popular. One reason (among many) why even great projects in D are ignored is D's atrocious ecosystem. In Python and Java for example I can download stuff I need, install dependencies (pip and gradle/maven) and that's usually it.
Oct 03
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 3 October 2019 at 11:14:41 UTC, Chris wrote:
 In Python and Java for example I can download stuff I need, 
 install dependencies (pip and gradle/maven) and that's usually 
 it.
Yeah, I think that is the primarily driving force behind Java and Python, that and platform support. Once you've learned the ins and outs of Python you cannot put it aside because of the swiss-army-knife aspect of it. Basically all platforms support Python in one way or another, even embedded, it has taken the generic high-level position that C has on the low level.
Oct 03
prev sibling parent reply mipri <mipri minimaltype.com> writes:
On Thursday, 3 October 2019 at 11:14:41 UTC, Chris wrote:
 One reason (among many) why even
 great projects in D are ignored is D's atrocious ecosystem.
The rhetorical value of hyperbolic language like this is that it's so rare in these forums. Everyone's just so peppy and ra-ra about D all the time that it's very startling to see any dissent.
 In
 Python and Java for example I can download stuff I need,
 install dependencies (pip and gradle/maven) and that's usually
 it.
Hi. I don't know what you're talking about, because I've done exactly this with dub, but I have some guesses. Option #1: Python and Java are super popular, so anything you happen to need will probably be downloadable and immediately usable. "People don't use D because people don't use D." Potential technical answer to option #1: use D. By this measure you'll contribute to people using D, and by an increment solve the problem of people not using D. Option #2: with Python and Java it's much more common for tools to be written in only Python and Java, and to only depend on other pure-Python and pure-Java libraries, so that when you want something you can just download a bunch of Python or Java code and it works. With D you'll more often hit a requirement to install some system libraries, and then you have to look that up, which is a pain. Potential technical answer to option #2: teach dub about common OS package systems so that it can A) suggest OS dependencies, and B) install OS dependencies. "I noticed that the binary I just built is linking to these libraries, because I ran ldd on it. Then I did a yum whatprovides /path/to/libraries and I found some RPMs. Do you want to add those as CentOS 7 OS dependencies for this project? This won't prevent anyone from installing your library, but it will make installation much easier on CentOS 7." Option #3. There are a bunch of technical inconveniences with dub that you won't describe because you've mentioned them before and nothing happened and now everyone agrees that D has an atrocious ecosystem, right? In the third case, sorry for intruding on your established consensus, but could you at least mention an actual problem with dub when it comes up? Any one of the actual problems, as opposed to the fake problem of "you can't just download D stuff and use it the way you can with Python."
Oct 03
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 3 October 2019 at 11:59:08 UTC, mipri wrote:
 comes up? Any one of the actual problems, as opposed to the fake
 problem of "you can't just download D stuff and use it the way 
 you can with Python."
IMO a package manager is only needed for scripty throw-away programming. I sincerely doubt it has a big effect on serious application development. If you build something with a long horizon you don't need a package manager. The time it takes to download and build libraries from github is negligible compared to the overall development time. Besides, if you build something big you also ought to understand the code you are using and the build process, even if it is a library. You have to be able to maintain the library in case it is abandoned...
Oct 03
next sibling parent drug <drug2004 bk.ru> writes:
On 10/3/19 3:13 PM, Ola Fosheim Grøstad wrote:
 On Thursday, 3 October 2019 at 11:59:08 UTC, mipri wrote:
 comes up? Any one of the actual problems, as opposed to the fake
 problem of "you can't just download D stuff and use it the way you can 
 with Python."
IMO a package manager is only needed for scripty throw-away programming. I sincerely doubt it has a big effect on serious application development. If you build something with a long horizon you don't need a package manager. The time it takes to download and build libraries from github is negligible compared to the overall development time. Besides, if you build something big you also ought to understand the code you are using and the build process, even if it is a library. You have to be able to maintain the library in case it is abandoned...
Totally disagree to you. Package manager is the thing especially if you develop big projects. It allows you easily maintain the infrastructure without manual scripting all dependencies to build your product, test it and deploy. It's really hard to overestimate the value of good package manager.
Oct 03
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2019-10-03 at 12:13 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-d
wrote:
[=E2=80=A6]
=20
 IMO a package manager is only needed for scripty throw-away=20
 programming. I sincerely doubt it has a big effect on serious=20
 application development.
It seems that Python, Ruby, Rust, Go, and D disagree with this position, al= l being based on source code packages. Indeed C++ is catching up and doing something very package like.
 If you build something with a long horizon you don't need a=20
 package manager. The time it takes to download and build=20
 libraries from github is negligible compared to the overall=20
 development time. Besides, if you build something big you also=20
 ought to understand the code you are using and the build process,=20
 even if it is a library. You have to be able to maintain the=20
 library in case it is abandoned...
I think Cargo, Go, and Dub prove this to be wrong. If you end up using a library that was third-party maintained but gets abandoned, do not take the time to take over maintenance, change to another library. There is generally a very good reason the library got abandoned, a= nd there are invariably very good newer replacements. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Oct 03
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 3 October 2019 at 19:54:32 UTC, Russel Winder wrote:
 It seems that Python, Ruby, Rust, Go, and D disagree with this 
 position, all being based on source code packages.
Python have enough libraries that have been maintained for a long time to be reliable, also the language is stable, does not change much and the environment is essentially a VM. So, even if it is not maintained, you can basically keep using it. Sure Go has many packages, but very few I would dare to rely on. The language is still changing, and I also don't want to use libraries on a server from a source I cannot trust. There are so many unmaintained libraries for these new languages that it doesn't look good for people who want to write software that has to be maintained for 15+ years.
 Indeed C++  is catching up and doing something very package 
 like.
Maybe, but if the libraries you use have strong ties to the OS/CPU architecture, then it has to be maintained at a higher frequency (which is more typical for low level programming than high level). What I believe is typical for C++ is to either include C-libraries that have a long track record of reliability, or depend on a small number of solid (commercial grade) C++frameworks, or use very small header libraries (preferably libraries that can be imported as independent single file headers). You really need to be careful with what you pull in when programming in C++ both in terms of being able to debug and build times.
 If you end up using a library that was third-party maintained 
 but gets abandoned, do not take the time to take over 
 maintenance, change to another library. There is generally a 
 very good reason the library got abandoned, and there are 
 invariably very good newer replacements.
That's not really possible in a larger project that has been deployed. That would incur large costs. Besides there might not be another PDF-generating library for you to use, or sound synthesis package that is anywhere near compatible. Even in Python, if I cannot use the PDF library I am using now, I would most likely set up an additional Java service rather than trying to pull in another PDF library written in Python. Besides, in reality you often end up maintaining your own fork anyway, since you usually have to make modifications to the library over time if it is doing something significant and special that you cannot roll on your own. Another reason to not use packages in larger projects is that it makes no sense to import an entire package when you only want one function. Increased build times, harder to read the codebase, and so on. What I find repulsive about the node.js world that use packages at crazy levels of pervasiveness is the security aspect of it.
Oct 03
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 03, 2019 at 08:50:53PM +0000, Ola Fosheim Grstad via Digitalmars-d
wrote:
 On Thursday, 3 October 2019 at 19:54:32 UTC, Russel Winder wrote:
[...]
 If you end up using a library that was third-party maintained but
 gets abandoned, do not take the time to take over maintenance,
 change to another library. There is generally a very good reason the
 library got abandoned, and there are invariably very good newer
 replacements.
That sounds good in theory, but in practice it will usually involve changing to a different API, and translating the old code to the new API (or writing a proxy wrapper) may be non-trivial (if even possible -- some may involve changing the entire operational paradigm that makes it infeasible to rewire). If that library is mission-critical I would not want to take the risk of leaving it up to the whim of whomever is hosting the source code online to remain online when I need it to be. Just imagine the hypothetical case that you have a massive vibe.d project, and suddenly one day for whatever reason vibe.d becomes unmaintained / the repo goes offline or whatever. Well, no problem, there's Adam Ruppe's arsd library with web handling, right? Just change a few lines in dub.json and off you go? The difference in API alone will probably entail rewriting the entire darned codebase before you could even get the thing to compile, let alone fixing all the bugs that were introduced in the process. Drop-in replacement is a pipe dream.
 That's not really possible in a larger project that has been deployed.
 That would incur large costs. Besides there might not be another
 PDF-generating library for you to use, or sound synthesis package that
 is anywhere near compatible. Even in Python, if I cannot use the PDF
 library I am using now, I would most likely set up an additional Java
 service rather than trying to pull in another PDF library written in
 Python.
[...] Exactly. Most non-trivial libraries of equivalent functionality tends to have drastically different APIs. It is not as easy as it sounds, that you just drop in a different library in place of the one that got abandoned. In a large, non-trivial project switching components like that is a big no-no unless there's a very compelling reason to, *and* you have the time and resources to pull it off (and clean up the resulting mess afterwards). T -- WINDOWS = Will Install Needless Data On Whole System -- CompuMan
Oct 03
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 20:50:53 UTC, Ola Fosheim Grøstad 
wrote:

 What I find repulsive about the node.js world that use packages 
 at crazy levels of pervasiveness is the security aspect of it.
The node.js world is crazy, in my opinion. Your whole project depends on some "obscure" packages. It's a big gamble and a maintenance hell. In my experience, such projects are for "instant gratification", it makes the client happy ("Wow! Looks good!"), but it quickly turns into a nightmare for those that have to maintain it. I prefer to invest time in a sound foundation and build on that. Some fancy things are easy to achieve with bog standard JS and CSS (transitions, transformations etc.), this has the advantage that you're in control and you don't depend on some obscure packages. A lot of info is here [1]. [1] https://www.w3schools.com/howto/howto_website.asp
Oct 04
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 October 2019 at 09:34:16 UTC, Chris wrote:
 The node.js world is crazy, in my opinion. Your whole project 
 depends on some "obscure" packages. It's a big gamble and a 
 maintenance hell. In my experience, such projects are for
Yes, although I do use Angular, which also pulls in a lot of dependencies, but then I expect Google to do the maintenance. Anyway, there is a big difference between having many dependencies on something that runs on the server (bad idea) and using a framework that runs client-side in the browser "sandbox".
 foundation and build on that. Some fancy things are easy to 
 achieve with bog standard JS and CSS (transitions, 
 transformations etc.), this has the advantage that you're in 
 control and you don't depend on some obscure packages. A lot of
That's true. I believe the "culture" of using libraries for such things come from around ten years ago when browsers had very different feature sets. The exception is when you implement a UI with a standard look-and-feel. Like Google Material, which has an animated counterpart in Angular.
Oct 04
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 4 October 2019 at 11:54:33 UTC, Ola Fosheim Grøstad 
wrote:
 That's true. I believe the "culture" of using libraries for 
 such things come from around ten years ago when browsers had 
 very different feature sets.
That's definitely one of the reasons. I remember those days. But even MS finally gave in (IE just faded out, devs and users didn't care anymore), nowadays you can use JS and CSS and be confident that it will work (with a few minor exceptions like getting the selected <option> of a <select> element). Another reason is that young people are used to frameworks and packages and often wonder why I didn't just download some fancy packages. But I wonder why I would do that if I can do it with keyframes and JS and 10 lines of code. Sure, web companies like Google and Facebook offer out of the box solutions, because they want devs to create apps and websites as fast as possible, and companies / startups are under pressure to impress clients and investors. Often it's disposable stuff like an app for the Soccer World Cup and the like. So there is demand and I'm not against it, but one has to decide whether or not it's good for your own project(s). Only because it's available and used all over the world doesn't mean it's the right thing for your project(s). It's like fast food. Sometimes it's a good solution, and it's good that we have it, but should you depend on it?
Oct 04
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 October 2019 at 12:33:25 UTC, Chris wrote:
 On Friday, 4 October 2019 at 11:54:33 UTC, Ola Fosheim Grøstad 
 wrote:
 That's true. I believe the "culture" of using libraries for 
 such things come from around ten years ago when browsers had 
 very different feature sets.
That's definitely one of the reasons. I remember those days. But even MS finally gave in (IE just faded out, devs and users didn't care anymore), nowadays you can use JS and CSS and be confident that it will work (with a few minor exceptions like
Right, and the JS APIs are much better too. I sometimes wonder why jquery is still around? Established habits don't change easily...
 like. So there is demand and I'm not against it, but one has to 
 decide whether or not it's good for your own project(s).
Yeah, those frameworks are generally not good for mobil devices, but can be very good for admin-desktop-user-interfaces and the like. Although this might change, some countries have cheap and fast mobil data network providers. For instance I believe there is a scandinavian provider that allows mobile users to download 1000GB per month for around 50USD. And then you have 5G... so the limiting factors do change.
 Sometimes it's a good solution, and it's good that we have it, 
 but should you depend on it?
Right. You usually get much more fluid performance by rolling your own. Then again, how fluid do you ned "preference settings" to be? Different tools for different purposes.
Oct 04
parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2019-10-04 at 13:05 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-d
wrote:
[=E2=80=A6]
=20
 Right, and the JS APIs are much better too.  I sometimes wonder=20
 why jquery is still around? Established habits don't change=20
 easily...
[=E2=80=A6] Isn't jQuery still being used because everyone with jQuery based systems refuses to update them because they work? --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Oct 07
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 7 October 2019 at 16:58:17 UTC, Russel Winder wrote:
 On Fri, 2019-10-04 at 13:05 +0000, Ola Fosheim Grøstad via 
 Digitalmars-d
 wrote:
 […]
 
 Right, and the JS APIs are much better too.  I sometimes 
 wonder why jquery is still around? Established habits don't 
 change easily...
[…] Isn't jQuery still being used because everyone with jQuery based systems refuses to update them because they work?
I don't know... https://meta.stackoverflow.com/questions/383170/how-do-i-ask-a-question-and-exclude-jquery-answers-to-strict-javascript-question *sigh*
Oct 07
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 04/10/2019 12:59 AM, mipri wrote:
 
 In the third case, sorry for intruding on your established consensus,
 but could you at least mention an actual problem with dub when it
 comes up? Any one of the actual problems, as opposed to the fake
 problem of "you can't just download D stuff and use it the way you
 can with Python."
From my experience, there is a tendency from some people especially those that are more experienced in D, to fight how dub wants to do things. Do it dub's way, and it should "just work" for pure-D code bases. That isn't to say it doesn't or shouldn't be improved. It does need to be improved, to cover more advanced use cases.
Oct 03
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 11:59:08 UTC, mipri wrote:
 The rhetorical value of hyperbolic language like this is that 
 it's so
 rare in these forums. Everyone's just so peppy and ra-ra about 
 D all
 the time that it's very startling to see any dissent.
I know that D is "the best language in the world" and anyone who points out serious flaws is a heretic. But thanks for pointing it out.
 Hi. I don't know what you're talking about, because I've done
 exactly this with dub, but I have some guesses.

 Option #1: Python and Java are super popular, so anything you 
 happen
 to need will probably be downloadable and immediately usable. 
 "People
 don't use D because people don't use D."

 Potential technical answer to option #1: use D. By this measure
 you'll contribute to people using D, and by an increment solve
 the problem of people not using D.
I used D for years. Got cured though. I think you get it only once. After that, you are immune.
 Option #2: with Python and Java it's much more common for tools 
 to be
 written in only Python and Java, and to only depend on other
 pure-Python and pure-Java libraries, so that when you want 
 something
 you can just download a bunch of Python or Java code and it 
 works.
 With D you'll more often hit a requirement to install some 
 system
 libraries, and then you have to look that up, which is a pain.
In other words, a mess of dependencies.
 Potential technical answer to option #2: teach dub about common 
 OS
 package systems so that it can A) suggest OS dependencies, and 
 B)
 install OS dependencies. "I noticed that the binary I just 
 built is
 linking to these libraries, because I ran ldd on it. Then I did 
 a yum
 whatprovides /path/to/libraries and I found some RPMs. Do you 
 want to
 add those as CentOS 7 OS dependencies for this project? This 
 won't
 prevent anyone from installing your library, but it will make
 installation much easier on CentOS 7."

 Option #3. There are a bunch of technical inconveniences with 
 dub that
 you won't describe because you've mentioned them before and 
 nothing
 happened and now everyone agrees that D has an atrocious 
 ecosystem,
 right?
There are loads of D users who dislike dub (I always used it for convenience though). I don't know if it's dub itself or just the fact that those who dislike it won't accept anything but make files. I never cared, tbh. The docs used to be hard to read, though, I don't know if that has improved.
 In the third case, sorry for intruding on your established 
 consensus,
 but could you at least mention an actual problem with dub when 
 it
 comes up? Any one of the actual problems, as opposed to the fake
 problem of "you can't just download D stuff and use it the way 
 you
 can with Python."
To be clear, dub is NOT "D's ecosystem", it's a tiny part of it, and most issues are not related to dub but to broken packages due to compiler upgrades and other toolchains. For example, is there a tool to streamline D integration into Android and iOS (cf. Nim)? Where are the plugins for the major IDEs? D doesn't care, but it sure won't scale this way.
Oct 03
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 3 October 2019 at 12:53:58 UTC, Chris wrote:
 For example, is there a tool to streamline D integration into 
 Android and iOS (cf. Nim)?
yes, it already just works on android command line and gui coming very soon
Oct 03
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 13:02:41 UTC, Adam D. Ruppe wrote:
 On Thursday, 3 October 2019 at 12:53:58 UTC, Chris wrote:
 For example, is there a tool to streamline D integration into 
 Android and iOS (cf. Nim)?
yes, it already just works on android command line and gui coming very soon
Care to post the link?
Oct 03
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 3 October 2019 at 13:28:15 UTC, Chris wrote:
 Care to post the link?
https://github.com/ldc-developers/ldc/releases/tag/v1.18.0-beta2 me and another person are working on the ios and android gui stuff in the background.
Oct 03
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 13:39:51 UTC, Adam D. Ruppe wrote:
 On Thursday, 3 October 2019 at 13:28:15 UTC, Chris wrote:
 Care to post the link?
https://github.com/ldc-developers/ldc/releases/tag/v1.18.0-beta2 me and another person are working on the ios and android gui stuff in the background.
Thanks. Good on you. How will it work once it's finished? How hard would it be to integrate it into an Android Studio / Xcode project / toolchain, e.g. could I add it as a dependency or would I have to compile it and package it as an additional lib? Are there any plans for auto generated bridges, e.g. JNI calling rt_init() or something?
Oct 03
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 3 October 2019 at 18:15:10 UTC, Chris wrote:
 How will it work once it's finished?
That's part of what we still need to figure out. What I'm aiming for in the first version is you compile the D code with ldc then work the generated shared object back into your workflow, which won't be modified; you just make the blob then drop it in as if it was a closed-source library. Second pass is possibly a plugin with android studio, or at least the build system. I'm actually totally new to mobile dev (I personally don't even use smartphone apps!) so lots of learning as I go. I'm pretty thankful for the work the ldc people have already done on this, as well as the prior art Joakim did before he left. The iOS thing is being led by someone else (idk if he wants to publicly talk about it yet), but he's very much a competent Mac person so I have no doubt he'll make it work well.
 Are there any plans for auto generated bridges, e.g. JNI 
 calling rt_init() or something?
I do want to put the bindings to the NDK into druntime as well in core.sys.android. The D foundation is officially backing this work which makes that more realistic.
Oct 03
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 03, 2019 at 06:27:46PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
[...]
 That's part of what we still need to figure out. What I'm aiming for
 in the first version is you compile the D code with ldc then work the
 generated shared object back into your workflow, which won't be
 modified; you just make the blob then drop it in as if it was a
 closed-source library.
BTW, I do have an android project that involves a combination of D code and Java code. It's cross-compiled from PC to the Android platform. Although it's not your typical Android project (I eschewed Android Studio in favor of my own SCons-based build script, mainly because I need to compile helper D programs that in turn generate D code for certain repetitive modules, but also because I can't be bothered with a resource-intensive IDE when a text editor works just as well), I'll be happy to provide details on the steps that worked for me. Basically, an APK can include Java bytecode, resources (XML, media, etc.), and, most importantly, a lib/ subdirectory for precompiled .so files. I took the route of using Java to interface with Android OS: there's a C API available that I *could* use if I wanted to, but I didn't want to have to reinvent the Java GUI bindings already available to Java code, so I just have the Java code declare native methods that are implemented by the .so (containing D code) via JNI. Compilation essentially amounts to running ldc on the D code to produce a .so that the build system inserts into the correct location in the APK, and the usual Java compilation and assembly into classes.dex, as required by Android, along with packing up the standard APK resources. Then run the tools in the Android SDK/NDK to process the APK, sign it, and what-not, then it's ready to be uploaded to your device for installation.
 Second pass is possibly a plugin with android studio, or at least the
 build system. I'm actually totally new to mobile dev (I personally
 don't even use smartphone apps!) so lots of learning as I go. I'm
 pretty thankful for the work the ldc people have already done on this,
 as well as the prior art Joakim did before he left.
Yes, my project got off the ground only because of the work Joakim did to make transcompilation to Android possible with LDC. There are some pretty specific details that you have to get right, otherwise your APK won't work. [...]
 Are there any plans for auto generated bridges, e.g. JNI calling
 rt_init() or something?
I do want to put the bindings to the NDK into druntime as well in core.sys.android. The D foundation is officially backing this work which makes that more realistic.
That would be VERY nice. Currently, in my code, I have to take extra care to call rt_init() and rt_cleanup() at the right junctures -- and this stuff is pretty delicate; get it wrong and it will crash at runtime, usually with no useful indication of what went wrong (you just get the "sorry, application crashed" message). I also have the beginnings of a JNI boilerplate auto-generator in my project, basically a template function that lets D code invoke a named Java method on a JNI-wrapped Java object. If you like, I can send you a copy for reference. Though keep in mind it's *very* crude, and I wrote just enough for my own needs, so it will need more work to be suitable for general consumption. But at the very least, it lets me call Java methods like this: // Equivalent to Java: // int ret = classObj.myMethod(123, "abc", 1.0); int ret = callJavaMethod!(int, "myMethod")(jniHandle, classObj, 123, "abc", 1.0); which, if you were to write it manually in terms of JNI calls, would be like a 25-50 line function in itself. (JNI is *very* boilerplate-y.) In theory, this could be expanded upon by wrapping Java class objects received over JNI in a JavaObject wrapper that contains an implicit JNI handle, so that you could actually write the above as: int ret = classObjWrapper.myMethod(123, "abc", 1.0); This can probably be done with good ole opDispatch. But so far, I haven't found the need for it yet, since my focus is mainly on the D code, and calling Java methods from D isn't really a priority except for some unavoidable calls to interact with the Android GUI API. One gotcha to watch out for, if you ever decide to go that route, is that the JNI handle handed to the D code by JNI is NOT guaranteed to be valid across different JNI calls; so if you do wrap your class objects like above, you have to be careful that you don't reuse stale JNI handles you obtained from previous JNI calls. Otherwise you may get random unexplained crashes at runtime. This is one of the reasons I haven't bothered to write such a wrapper just yet -- it's too much trouble to write code to handle the JNI handle correctly at the moment. Another challenge is that you can't deduce the Java return type of a method at D compile-time -- this is why callJavaMethod above requires a compile-time argument to specify the return type -- so you may have to resort to some heavy hackery if you want to be able to just assign the return value to a target variable without needing the user to explicitly specify the type. One approach that comes to mind is a tool that parses Java source code and emits equivalent D declarations that are then introspected by the Java class wrapper to obtain the correct method signatures. But again, a lot of work for something that I don't presently feel an urgent need for right now. (And, to dream on, in the future we could potentially have built-in Java support in D, in a similar style that we interface with C/C++ today: declare Java classes/methods using D equivalents, and have the compiler or a library auto-generate the JNI code for it. Or potentially just ditch JNI and use JNA instead, which is far less boilerplate-y. But as far as Android is concerned, JNA may not be available yet, so for the near future JNI seems to the way to go.) T -- WINDOWS = Will Install Needless Data On Whole System -- CompuMan
Oct 03
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 3 October 2019 at 19:33:37 UTC, H. S. Teoh wrote:
 BTW, I do have an android project that involves a combination 
 of D code and Java code.
ooo i'll take any help i can get. email me later.
Oct 03
prev sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 19:33:37 UTC, H. S. Teoh wrote:

[snip]

That sounds exactly like the nightmare I imagined it to be. I 
looked at Joakim's stuff a few times but realized the solutions 
for D on Android were still way too tricky and delicate. What he 
did is a great piece of engineering, but nothing that 
particularly inspires you to say "Yes, I'll go with D!" I'm glad 
that there is a bit of movement now.

 (And, to dream on, in the future we could potentially have 
 built-in Java support in D, in a similar style that we 
 interface with C/C++ today: declare Java classes/methods using 
 D equivalents, and have the compiler or a library auto-generate 
 the JNI code for it.  Or potentially just ditch JNI and use JNA 
 instead, which is far less boilerplate-y. But as far as Android 
 is concerned, JNA may not be available yet, so for the near 
 future JNI seems to the way to go.)


 T
That'd actually be great. Atm, interfacing D and Java is awkward. I've done it a few times (once I compiled my D code to a lib and used JavaFX for the UI), but it's certainly nothing you look forward to doing ;)
Oct 04
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 18:27:46 UTC, Adam D. Ruppe wrote:
 On Thursday, 3 October 2019 at 18:15:10 UTC, Chris wrote:
 How will it work once it's finished?
That's part of what we still need to figure out. What I'm aiming for in the first version is you compile the D code with ldc then work the generated shared object back into your workflow, which won't be modified; you just make the blob then drop it in as if it was a closed-source library. Second pass is possibly a plugin with android studio, or at least the build system. I'm actually totally new to mobile dev (I personally don't even use smartphone apps!) so lots of learning as I go. I'm pretty thankful for the work the ldc people have already done on this, as well as the prior art Joakim did before he left. The iOS thing is being led by someone else (idk if he wants to publicly talk about it yet), but he's very much a competent Mac person so I have no doubt he'll make it work well.
 Are there any plans for auto generated bridges, e.g. JNI 
 calling rt_init() or something?
I do want to put the bindings to the NDK into druntime as well in core.sys.android. The D foundation is officially backing this work which makes that more realistic.
That all sounds very good. As you probably know, Android Studio uses CMake for the C/C++ libs [1], it's not hard to set up and pretty handy, all my C code is compiled for whatever architecture and version of Android automagically. I realize that it would not be quite as "simple" for D. But something like that, an automatic D build script would be desirable. Also, you might want to have a look at how Kotlin handles multiplatform stuff, especially Android and iOS [2][3]. [1] https://developer.android.com/studio/projects/configure-cmake [2] https://kotlinlang.org/docs/reference/native-overview.html [3] https://play.kotlinlang.org/hands-on/Targeting%20iOS%20and%20Android%20with%20Kotlin%20Multiplatform/01_Introduction
Oct 04
prev sibling parent GreatSam4sure <greatsam4sure gmail.com> writes:
On Thursday, 3 October 2019 at 18:27:46 UTC, Adam D. Ruppe wrote:
 On Thursday, 3 October 2019 at 18:15:10 UTC, Chris wrote:
 How will it work once it's finished?
That's part of what we still need to figure out. What I'm aiming for in the first version is you compile the D code with ldc then work the generated shared object back into your workflow, which won't be modified; you just make the blob then drop it in as if it was a closed-source library. Second pass is possibly a plugin with android studio, or at least the build system. I'm actually totally new to mobile dev (I personally don't even use smartphone apps!) so lots of learning as I go. I'm pretty thankful for the work the ldc people have already done on this, as well as the prior art Joakim did before he left. The iOS thing is being led by someone else (idk if he wants to publicly talk about it yet), but he's very much a competent Mac person so I have no doubt he'll make it work well.
 Are there any plans for auto generated bridges, e.g. JNI 
 calling rt_init() or something?
I do want to put the bindings to the NDK into druntime as well in core.sys.android. The D foundation is officially backing this work which makes that more realistic.
Thanks for the effort. But it must work out of the box. A plugin to the android studio will be best prefer. All the heavy lifting should be done by the plugin. I would like to just install the plugin and would be fine for it. If I can get this, I might consider donating for it.
Oct 04
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On Thursday, 3 October 2019 at 18:15:10 UTC, Chris wrote:

 Thanks. Good on you. How will it work once it's finished? How 
 hard would it be to integrate it into an Android Studio / Xcode 
 project / toolchain, e.g. could I add it as a dependency or 
 would I have to compile it and package it as an additional lib? 
 Are there any plans for auto generated bridges, e.g. JNI 
 calling rt_init() or something?
I can give some answers related to iOS, although I'm not that guy working on the iOS project. The simplest would probably be to add an external build step in Xcode to compile the D code, which should produce a static library. Then just link with that static library. It's a bit simpler on iOS since everything is native code and there are nothin like JNI that needs to be handled. For interfacing between the Swift/Objective-C code either the `extern(C)` or `extern(Objective-C)` can be used. DStep [1] can generate bindings to Objective-C code. I think it should be possible to implement an application completely in D as well. [1] http://github.com/jacob-carlborg/dstep
Oct 04
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Oct 04, 2019 at 02:14:33PM +0000, Jacob Carlborg via Digitalmars-d
wrote:
[...]
 The simplest would probably be to add an external build step in Xcode
 to compile the D code, which should produce a static library. Then
 just link with that static library. It's a bit simpler on iOS since
 everything is native code and there are nothin like JNI that needs to
 be handled.
[...] FYI, on Android there *is* a C API in the NDK that you can use to interface with the OS. IIRC Java/JNI is not strictly necessary, though it's certainly more convenient since a large number of built-in resources are only accessible to Java (esp. the various GUI components). I chose the mixed Java/D route mainly so that I can just leverage off the Java stuff that's already built-in, instead of homebrewing everything from scratch in D. T -- If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen
Oct 04
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 October 2019 at 15:02:36 UTC, H. S. Teoh wrote:
 FYI, on Android there *is* a C API in the NDK that you can use 
 to interface with the OS. IIRC Java/JNI is not strictly 
 necessary, though it's certainly more convenient since a large 
 number of built-in resources are only accessible to Java (esp. 
 the various GUI components).
I wonder how hard it would be to port Flutter to D and bypass Java/Swift entirely. I don't think "modern" Dart is all that different. https://flutter.dev/docs/resources/technical-overview
Oct 04
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 4 October 2019 at 15:18:03 UTC, Ola Fosheim Grøstad 
wrote:
 I wonder how hard it would be to port Flutter to D and bypass 
 Java/Swift entirely. I don't think "modern" Dart is all that 
 different.

 https://flutter.dev/docs/resources/technical-overview
The guy is obviously biased, but he has a point. Kotlin devs will not want to move to Dart, and who knows how long Flutter will last, till the next cool framework comes along? Personally, it's too React-ish and Angular-ish for my liking. https://blog.kotlin-academy.com/flutter-and-kotlin-multiplatform-relationship-890616005f57
Oct 04
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 October 2019 at 17:41:15 UTC, Chris wrote:
 The guy is obviously biased, but he has a point. Kotlin devs 
 will not want to move to Dart, and who knows how long Flutter 
 will last, till the next cool framework comes along? 
 Personally, it's too React-ish and Angular-ish for my liking.
I don't know, but Google is using Dart internally and also control Android, so it might currently be the best option for cross platform. Anyway, if it all is open source, then the code will be there even if they drop it. So, I have no experience with Flutter, but it seems to be more mature than it was a few years ago. It doesn't really matter all that much whether people want to transition or not. If Google don't drop Flutter then the business-cost-savings will be more important than what programmers want or don't want... Anyway, since the layer under Dart is C/C++, then it should be possible to port Flutter to other languages.
Oct 04
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 4 October 2019 at 15:02:36 UTC, H. S. Teoh wrote:
 On Fri, Oct 04, 2019 at 02:14:33PM +0000, Jacob Carlborg via 
 Digitalmars-d wrote: [...]
 The simplest would probably be to add an external build step 
 in Xcode to compile the D code, which should produce a static 
 library. Then just link with that static library. It's a bit 
 simpler on iOS since everything is native code and there are 
 nothin like JNI that needs to be handled.
[...] FYI, on Android there *is* a C API in the NDK that you can use to interface with the OS. IIRC Java/JNI is not strictly necessary, though it's certainly more convenient since a large number of built-in resources are only accessible to Java (esp. the various GUI components). I chose the mixed Java/D route mainly so that I can just leverage off the Java stuff that's already built-in, instead of homebrewing everything from scratch in D. T
JNI is pretty much a requirement for anything that isn't OpenGL, Vulkan, Audio, ISO C or ISO C++ standard libraries, even accessing files outside the APK install directory requires Java due to SAF. Additionally since Android 7 Google has been clamping down the NDK APIs to minimize exploits via native code.
Oct 04
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 October 2019 at 15:34:32 UTC, Paulo Pinto wrote:
 JNI is pretty much a requirement for anything that isn't 
 OpenGL, Vulkan, Audio, ISO C or ISO C++ standard libraries, 
 even accessing files outside the APK install directory requires 
 Java due to SAF.

 Additionally since Android 7 Google has been clamping down the 
 NDK APIs to minimize exploits via native code.
But Flutter is made by Google, so they clearly have a path to a Java-free environment? Or does Flutter depend on Java?
Oct 04
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 4 October 2019 at 15:56:28 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 4 October 2019 at 15:34:32 UTC, Paulo Pinto wrote:
 JNI is pretty much a requirement for anything that isn't 
 OpenGL, Vulkan, Audio, ISO C or ISO C++ standard libraries, 
 even accessing files outside the APK install directory 
 requires Java due to SAF.

 Additionally since Android 7 Google has been clamping down the 
 NDK APIs to minimize exploits via native code.
But Flutter is made by Google, so they clearly have a path to a Java-free environment? Or does Flutter depend on Java?
We're using Flutter at work for one of our applications, so I can answer that. The Flutter project is divided in two parts: engine and framework. The engine is written in a mix of C++, Java and Objective-C where Java and Objective-C are respectively used to access the platform APIs. The framework (what Flutter apps are directly using) is written in pure Dart. Flutter is using a technique called system channels which is basically an RPC-like thing that marshals method calls to/from C/C++/Java/Objective-C from/to C++ and Dart. It's slower than calling the method from the same language. I believe Flutter will be framework of choice for their upcoming Fuchsia OS, but currently Dart is very much a second class citizen on Android (unlike Kotlin), just like it is on iOS. Fortunately, Google have done a stellar job of creating good dev experience by providing a solid CLI and editor plugins that abstract the platform differences.
Oct 04
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 October 2019 at 16:28:31 UTC, Petar Kirov 
[ZombineDev] wrote:
 The Flutter project is divided in two parts: engine and 
 framework. The engine is written in a mix of C++, Java and 
 Objective-C where Java and Objective-C are respectively used to 
 access the platform APIs. The framework (what Flutter apps are 
 directly using) is written in pure Dart.
 Flutter is using a technique called system channels which is 
 basically an RPC-like thing that marshals method calls to/from 
 C/C++/Java/Objective-C from/to C++ and Dart. It's slower than 
 calling the method from the same language.
Ok, it was not apparent from their system overview chart that they go through Java, it basically says that the engine is C/C++ and sits on top of a system specific "embedder" layer. So I guess then that Java is called from the "embedder" layer where the API isn't available otherwise? But rendering is done straight from C/C++? It does use its own renderer, right?
 I believe Flutter will be framework of choice for their 
 upcoming Fuchsia OS, but currently Dart is very much a second 
 class citizen on Android (unlike Kotlin), just like it is on 
 iOS. Fortunately, Google have done a stellar job of creating 
 good dev experience by providing a solid CLI and editor plugins 
 that abstract the platform differences.
Thanks for sharing your experience with Flutter! Being able to do cross-platform apps for iOS, Android and web did peak my curiosity, so downloading now to see how it all works.
Oct 04
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 4 October 2019 at 14:14:33 UTC, Jacob Carlborg wrote:
 I can give some answers related to iOS, although I'm not that 
 guy working on the iOS project.
oh i thought it was you :S
 For interfacing between the Swift/Objective-C code either the 
 `extern(C)` or `extern(Objective-C)` can be used. DStep [1] can 
 generate bindings to Objective-C code.
So it isn't that different than doing a Mac cocoa program? I don't have a mac nor an apple developer license though, just a vm. So I probably couldn't do it even if I tried. (the android thing is painful enough, I don't even know how to do it and most the work is already done for me by others!)
Oct 04
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Oct 04, 2019 at 03:19:48PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
[...]
 (the android thing is painful enough, I don't even know how to do it
 and most the work is already done for me by others!)
Just in case this is helpful, here's an overview of I get from sources to .apk in my mixed Java/D project: 1) Generate R.java from Java sources by running `aapt` (from the SDK/NDK; some Linux distros ship it separately as well -- be aware that the version must match the rest of your environment or you might get strange errors / compatibility issues). 2) Build Java sources by invoking `javac`. 3) Run the `dx` tool to transform the resulting .class files to the classes.dex format required by Android. 4) Cross-compile D sources to the target architecture using LDC (in my case, I target cortex-a8 / armv7 androideabi). In my case, I found that I need to compile to object files first, and link separately (see following step). 5) Link .o files to .so file using the clang compiler from the Android NDK. This is to ensure that you get the right native libs linked to your D code, otherwise you'll end up with link errors and/or runtime problems. Be sure to specify -shared and the right -soname. EXTRA NOTE: In order to optimize the resulting binary size, I also specify -Wl,--gc-sections and -Wl,--version-script=libmyapp.version, where libmyapp.version contains the following: LIBGAME_1.0 { global: Java_*; local: *; }; This is to ensure that --gc-sections deletes all sections not reachable from a symbol that matches the name Java_* (i.e., a JNI entry point). Without this, tons of unused symbols from druntime and Phobos get included in the .so, significantly bloating the APK size. If you're generating a Java-free native app, you'll have to customize the global: line to point to your app's entry point so that it doesn't get GC'd. :-D 6) Create the initial (unaligned) APK file using the following commands: aapt package -f -m -M$manifest_file -S$resource_dir -I$sdkjar -F $target-unaligned.apk aapt add $target-unaligned.apk classes.dex aapt add $target-unaligned.apk path/to/libmyapp.so where: $manifest_file is the Android manifest file for your project; $sdkjar points to platforms/android-$version/android.jar where $version is the Android API version number you're targeting; $resource_dir Points to the subdir (generally called `res`) containing various XML resources and other media. 7) Sign the APK: apksigner sign --ks-pass file:path/to/passwordfile -ks path/to/keystore $target-unaligned.apk (Note: apksigner expects a keystore in the proprietary Java format; if you want to use a different keystore format you'll have to manually do the signing -- google for instructions on how to do this. Be warned that it will not be pretty.) 8) Align the APK: zipalign -f 4 $target-unaligned.apk $target.apk Now $target.apk should be ready for installation. Most of the above steps are customarily hidden from view when you use an IDE like Android Studio, and it's mostly automated by Gradle. Ideally, to make the above more accessible to D users, you'd probably want to create a Gradle plugin that integrates the LDC cross-compilation and linking step into Gradle, or whatever IDE / build system you want to target, so that users can just add the plugin to their build config and build away. I did all of the above manually primarily because I have auxiliary code generators in my project (small D programs running on the host PC that read in a bunch of data files and process them into a form suitable for inclusion into the APK, along the way also generating D wrapper code for working with said data). Doing it manually is also more direct, and has less external dependencies, which makes it faster (using SCons, I can already finish building the darned thing from start to finish in the time it takes just for Gradle to *start up* -- and this, in a fraction of the RAM required to even run Gradle in the first place). Generally, I don't recommend doing all of this manually. :-D So for your general D user who's uncomfortable with writing build scripts manually you probably want to look into Gradle integration of some sort, or whatever IDE or build system you want to target. Note that the current version of dub is unable to handle some of the above steps without heavy hackery / hard-coding of stuff / external scripting. (The cross-compilation step and the need to compile Java are big show-stoppers when it comes to dub.) It would be *very* nice if you could somehow coax dub to do the Right Thing(tm), but I honestly have my doubts about it. You *should* be able to do the cross-compilation and linking step as a Gradle plugin, though, and Gradle will take care of the rest of the APK heavy-lifting for you, so perhaps this could be a first target: get D cross-compilation working in Android Studio. (Unfortunately, I have not bothered to use Gradle to any meaningful degree, so I'm unable to help you on that front.) T -- The best way to destroy a cause is to defend it poorly.
Oct 04
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-10-04 17:19, Adam D. Ruppe wrote:

 oh i thought it was you :S
Unfortunately no. It doesn't look like anyone is working on it [1].
 So it isn't that different than doing a Mac cocoa program?
No, it's the same idea. The underlying operating systems are the same (or very similar). They share many of the non-UI frameworks and other libraries. [1] https://dlang.org/blog/2019/10/04/d-language-foundation-funding-new-platforms-new-bounties/ -- /Jacob Carlborg
Oct 04
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-10-04 16:14, Jacob Carlborg wrote:

 I can give some answers related to iOS, although I'm not that guy 
 working on the iOS project.
 
 The simplest would probably be to add an external build step in Xcode to 
 compile the D code, which should produce a static library. Then just 
 link with that static library. It's a bit simpler on iOS since 
 everything is native code and there are nothin like JNI that needs to be 
 handled.
 
 For interfacing between the Swift/Objective-C code either the 
 `extern(C)` or `extern(Objective-C)` can be used. DStep [1] can generate 
 bindings to Objective-C code.
 
 I think it should be possible to implement an application completely in 
 D as well.
 
 [1] http://github.com/jacob-carlborg/dstep
I can also add that it's not possible to create plugins for Xcode. It does support extensions but so far it's only possible to access and manipulate the source code. Can't add support for new languages, can't add new build types or similar. It's probably possible to build an iOS project without the help of Xcode, just look at the commands Xcode is invoking and replicate those. Can probably use Dub as well with the help of pre and post actions. -- /Jacob Carlborg
Oct 04
prev sibling parent reply mipri <mipri minimaltype.com> writes:
On Thursday, 3 October 2019 at 12:53:58 UTC, Chris wrote:
 On Thursday, 3 October 2019 at 11:59:08 UTC, mipri wrote:
 The rhetorical value of hyperbolic language like this is that 
 it's so
 rare in these forums. Everyone's just so peppy and ra-ra about 
 D all
 the time that it's very startling to see any dissent.
Let's go through this piece by piece: The rhetorical value of hyperbolic language like this I'm guessing this what you replied to. is that it's so rare in these forums. Do you agree with that? Everyone's just so peppy and ra-ra about D all the time Do you think anyone would perceive the forums this way? it's very startling to see any dissent. Did you think anyone would be startled by your remarks? To put it plainly, the forums are characterized by a constant drone of hyperbolic complaints about D and even a week of exposure is enough time to start tuning it out automatically. I don't read "D has an atrocious ecosystem" and think, oh no, someone had better do something about that! Nor do I feel that I should get in front of this unjust attack on D's honor. What I think is, "if I ask this person what he even means by that, is he even going to tell me?"
 To be clear, dub is NOT "D's ecosystem", it's a tiny part of 
 it, and most issues are not related to dub but to broken 
 packages due to compiler upgrades and other toolchains. For 
 example, is there a tool to streamline D integration into 
 Android and iOS (cf. Nim)? Where are the plugins for the major 
 IDEs? D doesn't care, but it sure won't scale this way.
Oct 03
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 13:35:09 UTC, mipri wrote:
 Let's go through this piece by piece:

   The rhetorical value of hyperbolic language like this

 I'm guessing this what you replied to.

   is that it's so rare in these forums.

 Do you agree with that?

   Everyone's just so peppy and ra-ra about D all the time

 Do you think anyone would perceive the forums this way?

   it's very startling to see any dissent.

 Did you think anyone would be startled by your remarks?

 To put it plainly, the forums are characterized by a constant 
 drone of
 hyperbolic complaints about D and even a week of exposure is 
 enough
 time to start tuning it out automatically. I don't read "D has 
 an
 atrocious ecosystem" and think, oh no, someone had better do 
 something
 about that! Nor do I feel that I should get in front of this 
 unjust
 attack on D's honor. What I think is, "if I ask this person 
 what he
 even means by that, is he even going to tell me?"


Er, I've raised some issues, as have others over the years. I don't know what your problem is. I'm not trying to shock or troll. But I think it's ok to talk about D on forum.dlang.org? Ain't it? And I'm learning interesting things and it's interesting to hear what other people (not the fanboys and those with a vested interest) say. True, I'm not a fan of how things have developed, but who cares? If you wanna be sarcastic, try to be less obscure. That might help. Good look to you!
Oct 03
parent reply mipri <mipri minimaltype.com> writes:
On Thursday, 3 October 2019 at 13:44:09 UTC, Chris wrote:
 If you wanna be sarcastic, try to be less obscure.
What you did was rhetorical pattern-matching. if Chris says <bad things about D> Someone else <replies disapprovingly> then deploy prepared comeback: "Aha! You D fanboys are at it again, attacking the messenger!" Read what I say instead of lazily continuing your unproductive bitch-fest into pseudo-conversation with me, and you'll catch obvious sarcasm just fine.
 That might help. Good look to you!
Oct 03
next sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 13:47:57 UTC, mipri wrote:
 On Thursday, 3 October 2019 at 13:44:09 UTC, Chris wrote:
 If you wanna be sarcastic, try to be less obscure.
What you did was rhetorical pattern-matching. if Chris says <bad things about D> Someone else <replies disapprovingly> then deploy prepared comeback: "Aha! You D fanboys are at it again, attacking the messenger!" Read what I say instead of lazily continuing your unproductive bitch-fest into pseudo-conversation with me, and you'll catch obvious sarcasm just fine.
 That might help. Good look to you!
You're a charming chap indeed! Your social skills are amazing. If you don't like the conversation, just ignore it, that's what most people would do. I've quite enjoyed the chat with some of the posters here. And I've learned a lot too. Actually, Nim looks promising.
Oct 03
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 3 October 2019 at 13:47:57 UTC, mipri wrote:
 Read what I say instead of lazily continuing your unproductive
 bitch-fest into pseudo-conversation with me, and you'll catch
 obvious sarcasm just fine.
You went ad-hominem. That has been a plague of these forums for years. Unfortunately there is no real forum moderation policy in place, and frankly key developers have had a tendency to go down this road quite frequently, but moving from something technical to something personal is not in the spirit of engineering, and should be avoided, no matter how much you dislike the presented positions. Most people in this thread have presented reasonable positions. But D is moving slowly in the critical area of memory management, which really is a prerequisite for being a real alternative for many developers. On the other hand, D is moving, so that is a good thing, but I really hope that the D community don't scare off people with the theoretical knowledge to make it work. Without those people there is a very slim chance of getting it right. Other languages are moving to, in this thread Nim has been highlighted, so comparing Nim's situation to D's situation ought to be on-topic for this thread. I don't really understand why you want Chris to sugar-coat his views. Again, I really hope that the D community don't scare off people with the theoretical knowledge to design memory management solutions that works well.
Oct 03
parent reply mipri <mipri minimaltype.com> writes:
On Thursday, 3 October 2019 at 16:57:13 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 3 October 2019 at 13:47:57 UTC, mipri wrote:
 Read what I say instead of lazily continuing your unproductive
 bitch-fest into pseudo-conversation with me, and you'll catch
 obvious sarcasm just fine.
You went ad-hominem.
Suppose a neighbor deliberately poisons your dog. How should you respond? By poisoning the neighbor's dog? What if you're morally opposed to poisoning animals in general? What if the neighbor doesn't have a dog? Offenses can't always be replied to in kind. You shouldn't be so alert for specific forms of offense that seeing them blinds you to earlier interactions. For example, even if I wanted to hold a grudge over this rude post of yours, such that I'd wait for an opportunity to jump in *after* you've stopped arguing with someone to say "woah! Let's all settle down!", followed by mischaracterizations of your behavior in the argument, I just wouldn't remember to do it. And I'm morally opposed to posts such as yours, or to holding petty grudges.
 I don't really understand
 why you want Chris to sugar-coat his views.
This is the timeline: Chris expresses a view that D has an atrocious ecosystem, that you can't just download and use D code like you can in Python and Java, etc. I then complain mildly and indirectly about the hyperbolic language, but mainly: I ask for details on what's so bad about the ecosystem, and write a lot about potential badnesses that Chris could've meant. You probably don't think this is "asking for sugarcoating" yet, right? Chris then sneers that I am saying that D is "the best language in the world" and that I am attacking him as a heretic, which is extra special annoying as this is blatantly a prepared reply to "someone complaining about his D bashing" rather than a reply to what I actually complained about. Interpersonally, this is interrupting someone and smugly rebutting what you think they're trying to say--while being wrong about what they mean to say, while characterizing them as a stupid fanboy. Nothing ad hominen here, I guess? There's then some back and forth about my sarcasm, because Chris offered nothing else to talk about, and I took the bait as I am doing now.
 Again, I really
 hope that the D community don't scare off people with the
 theoretical knowledge to design memory management solutions
 that works well.
Just post about other stuff. Bump other threads. Talk about Nim in the Nim thread instead of about arguments that you didn't pay a lot of attention to. Or if you want to offer some general appeals like your hopes for the D community, do that, and just that. You don't really care the timeline above, right? So why make some non-ad-hominen remarks suggestions that read a bit like "we really need a moderator in here to handle hotheads that insult people so obviously that I notice it after they fail to get someone else to sugarcoat their views"? What part of that didn't you think wouldn't lead to more posts about the thing you're wanting to go away? I've been repeatedly insulted for asking for technical details behind a vacuous and meaningless complaint about D. Because I was interested in them. Because I'm interested in improvements to the thing I saw complained about. I don't feel bad about some mild words like "lazy", "unproductive", or "bitch-fest". What I've learned is to not bother asking for details about vacuous complaints in here. People can show they care about their own stated positions by being at least a little technical or specific at the outset.
Oct 03
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 17:50:09 UTC, mipri wrote:
 On Thursday, 3 October 2019 at 16:57:13 UTC, Ola Fosheim 
 Grøstad wrote:
 [...]
Suppose a neighbor deliberately poisons your dog. How should you respond? By poisoning the neighbor's dog? What if you're morally opposed to poisoning animals in general? What if the neighbor doesn't have a dog? Offenses can't always be replied to in kind. You shouldn't be so alert for specific forms of offense that seeing them blinds you to earlier interactions. For example, even if I wanted to hold a grudge over this rude post of yours, such that I'd wait for an opportunity to jump in *after* you've stopped arguing with someone to say "woah! Let's all settle down!", followed by mischaracterizations of your behavior in the argument, I just wouldn't remember to do it. And I'm morally opposed to posts such as yours, or to holding petty grudges.
 [...]
This is the timeline: Chris expresses a view that D has an atrocious ecosystem, that you can't just download and use D code like you can in Python and Java, etc. I then complain mildly and indirectly about the hyperbolic language, but mainly: I ask for details on what's so bad about the ecosystem, and write a lot about potential badnesses that Chris could've meant. You probably don't think this is "asking for sugarcoating" yet, right? Chris then sneers that I am saying that D is "the best language in the world" and that I am attacking him as a heretic, which is extra special annoying as this is blatantly a prepared reply to "someone complaining about his D bashing" rather than a reply to what I actually complained about. Interpersonally, this is interrupting someone and smugly rebutting what you think they're trying to say--while being wrong about what they mean to say, while characterizing them as a stupid fanboy. Nothing ad hominen here, I guess? There's then some back and forth about my sarcasm, because Chris offered nothing else to talk about, and I took the bait as I am doing now.
 [...]
Just post about other stuff. Bump other threads. Talk about Nim in the Nim thread instead of about arguments that you didn't pay a lot of attention to. Or if you want to offer some general appeals like your hopes for the D community, do that, and just that. You don't really care the timeline above, right? So why make some non-ad-hominen remarks suggestions that read a bit like "we really need a moderator in here to handle hotheads that insult people so obviously that I notice it after they fail to get someone else to sugarcoat their views"? What part of that didn't you think wouldn't lead to more posts about the thing you're wanting to go away? I've been repeatedly insulted for asking for technical details behind a vacuous and meaningless complaint about D. Because I was interested in them. Because I'm interested in improvements to the thing I saw complained about. I don't feel bad about some mild words like "lazy", "unproductive", or "bitch-fest". What I've learned is to not bother asking for details about vacuous complaints in here. People can show they care about their own stated positions by being at least a little technical or specific at the outset.
On Thursday, 3 October 2019 at 17:50:09 UTC, mipri wrote: You do realize that it was you who hijacked this thread about Nim and tried to turn it into a flamewar with ad hominems galore. As for the details, well, anyone who has been on this forum for a while (as most posters here have) knows the details, and honestly, I won't repeat them every time a random poster says "If you don't provide details, I won't take you seriously." Everybody remembers the discussions and issues regarding: ecosystem / tooling, autodecode, GC, ARM support and loads of other stuff that pops up regularly. If you want the details put the aforementioned terms in the forum search engine. Also, if you find Ola's reply "offensive", seriously, I don't know what to say. Again, I wish you good luck.
Oct 03
parent reply mipri <mipri minimaltype.com> writes:
On Thursday, 3 October 2019 at 18:09:06 UTC, Chris wrote:
 You do realize that it was you who hijacked this thread about
 Nim and tried to turn it into a flamewar with ad hominems
 galore.
No, I don't realize that. I very kindly wrote my exact interpretation of what happened here in the timeline that you quoted, in the reply that you're replying to. You offered some remarks about D in this thread about Nim and I asked about them. Suppose you'd just answered the question? Suppose you'd even just said "eh I can't be arsed, just search the forum." All of my replies, past the first one, have been to your insults. Do you not wonder if you might be hijacking the thread with your own insults? Please, wonder a little bit about it.
 Also, if you find Ola's reply "offensive", seriously,
What do you mean 'if'? I wasn't subtle about why I found it offensive. I emphasized that though as it seems to have not even occurred to him that I might've gotten annoyed with you for any reason other than "you are still not sugarcoating your views as I'd wanted". That's all.
 Again, I wish you good luck.
Twice while preparing this reply it was clear to me that you'd just not bothered to read what I'd said earlier, or to take it seriously. Over the course of a very short conversation, that's three strikes. I probably won't remember not to waste further words on you, so if you mean any kindness with these wishes, please keep the luck and just read my actual words next time.
Oct 03
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 3 October 2019 at 18:52:44 UTC, mipri wrote:
 I emphasized that though as it seems to have not even
 occurred to him that I might've gotten annoyed with you for any
 reason other than "you are still not sugarcoating your views as
It doesn't matter why you get annoyed. If technology arguments quickly move to a personal/emotional level than that is something that turns off people with engineering/academic/comp-sci backgrounds who expect technical discussions to stay technical (often with the agreement to disagree). Basically, if things frequently gets emotional they will most likely not stay around and move elsewhere, like Rust.
Oct 04
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 3 October 2019 at 17:50:09 UTC, mipri wrote:
 views"? What part of that didn't you think wouldn't lead to more
 posts about the thing you're wanting to go away?
I really don't care and it isn't about you, I was pointing out a community symptom. The reality is that there have been enough people in the D community in the past 10 years that had the skillset and the knowhow to move D forward in most difficult theoretical areas. But they don't stick around. And getting those things right does take hard work.
Oct 03
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 3 October 2019 at 10:49:47 UTC, LocoDelPueblo wrote:
 The strategy of "Y is a better X" is to make people moving from 
 X to Y. So far in D successes are not movers, it's new 
 projects, corporate or not.
That is an interesting metric. There is at least one larger project moving from Pascal to D, based on what has been stated in public. Although, I guess, most native languages could have been used as the target if you transition from Pascal.
Oct 03
parent reply LocoDelPueblo <fdp-dyna-hum nowhere.mx> writes:
On Thursday, 3 October 2019 at 11:29:35 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 3 October 2019 at 10:49:47 UTC, LocoDelPueblo 
 wrote:
 The strategy of "Y is a better X" is to make people moving 
 from X to Y. So far in D successes are not movers, it's new 
 projects, corporate or not.
That is an interesting metric. There is at least one larger project moving from Pascal to D, based on what has been stated in public. Although, I guess, most native languages could have been used as the target if you transition from Pascal.
Yes indeed, I think that this comment is related to Bastian V. Still not accomplished move I think. Also I didn't deny that it can work "to some extant".
Oct 03
parent LocoDelPueblo <fdp-dyna-hum nowhere.mx> writes:
On Thursday, 3 October 2019 at 11:32:13 UTC, LocoDelPueblo wrote:
 On Thursday, 3 October 2019 at 11:29:35 UTC, Ola Fosheim 
 Grøstad wrote:
 On Thursday, 3 October 2019 at 10:49:47 UTC, LocoDelPueblo 
 wrote:
 The strategy of "Y is a better X" is to make people moving 
 from X to Y. So far in D successes are not movers, it's new 
 projects, corporate or not.
That is an interesting metric. There is at least one larger project moving from Pascal to D, based on what has been stated in public. Although, I guess, most native languages could have been used as the target if you transition from Pascal.
Yes indeed, I think that this comment is related to Bastian V. Still not accomplished move I think. Also I didn't deny that it can work "to some extant".
and the move is not from cpp to D BTW ;)
Oct 03
prev sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 3 October 2019 at 09:36:17 UTC, LocoDelPueblo wrote:
 Problem is also that people using python don't want to be 
 programmers... they just do stuff in python, and sometimes 
 these stuff become mainstream. So if the idea is to say "use 
 Nim instead of python" you basically kill the "why" the python 
 stuff started being widely used and developed. You fallback in 
 the "no-way" again.

 I've observed this again two days ago where the UI of for a 
 command line app required python-qt. The application could have 
 been made in cpp, easily, but you know the authors just wanted 
 to make their stuff...but now this ui is available on most 
 linux distribs, no matter the way it's made.
Actually, I had some time to play around with Nim and it really "feels" like Python. I was thinking if they had an automatic Python to Nim converter (like Kotlin has a Java to Kotlin converter), it'd be much easier to make the transition. It'd be great to be able to do something like this: `nim pyToNim file.py file.nim`.
Oct 03
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 3 October 2019 at 08:20:55 UTC, Chris wrote:
 Python is often used for prototyping too, and then the real app 
 is written in C++. This begs the question, is D becoming a 
 native Python?
I don't know about that, but I think Python works both ways. Some use Python for application-scripting or application-plugins, others use Python for the main program and use C/C++ for "plugins". So there is a lot of flexibility in using Python for prototyping that few other platforms provide. For instance, if you design a vector-drawing-app, you might start by looking for Python libs then set it up with a simple interface then replace each component. Few other languages let you start from that level of "patching things together" (except outdated languages like Perl, Common Lisp or *choke* Visual Basic). Prototyping in Nim or D doesn't sound very attractive to me. They probably should aim for production. At this point TypeScript/node.js/electron/angular would probably be a more likely candidate for prototyping.
Oct 03
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 1 October 2019 at 10:05:31 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 1 October 2019 at 08:47:19 UTC, Chris wrote:
 1. Walter admits that D only caters for a few users with very 
 specific use cases (niches).
Which niches are these? My impression is that D primarily caters for users that want the feature-set of C++, but find C++ to be too inconvenient or complicated.
See what I've found, a very wise man: "[managed languages] will have their share, but native languages will also get a part of the cake. Here most developers seem to be satisfied with the available choices: Go, Rust, C++, C, X (place your favorite one in here). So why should D now (suddenly) get the attention (which it would certainly deserve)? My guess is that it won't be about making D more attractive to new developers. I feel that the mission will be to make D more powerful for a variety of very special scenarios, which will give the language a piece of the cake that [is] not in the mainstream area." (8/29/2015) https://florian-rappl.de/News/Page/310/is-it-d-comeback Funnily enough, it wasn't too long after that, in 2017, that I was getting increasingly frustrated with D and started to look for alternatives to D as I was beginning to realize that D had become a language for "special scenarios" and that other use cases (e.g. mobile) would never happen.
Oct 02
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 2 October 2019 at 09:57:50 UTC, Chris wrote:
 On Tuesday, 1 October 2019 at 10:05:31 UTC, Ola Fosheim Grøstad 
 wrote:
 On Tuesday, 1 October 2019 at 08:47:19 UTC, Chris wrote:
 1. Walter admits that D only caters for a few users with very 
 specific use cases (niches).
Which niches are these? My impression is that D primarily caters for users that want the feature-set of C++, but find C++ to be too inconvenient or complicated.
See what I've found, a very wise man: "[managed languages] will have their share, but native languages will also get a part of the cake. Here most developers seem to be satisfied with the available choices: Go, Rust, C++, C, X (place your favorite one in here). So why should D now (suddenly) get the attention (which it would certainly deserve)? My guess is that it won't be about making D more attractive to new developers. I feel that the mission will be to make D more powerful for a variety of very special scenarios, which will give the language a piece of the cake that [is] not in the mainstream area." (8/29/2015) https://florian-rappl.de/News/Page/310/is-it-d-comeback Funnily enough, it wasn't too long after that, in 2017, that I was getting increasingly frustrated with D and started to look for alternatives to D as I was beginning to realize that D had become a language for "special scenarios" and that other use cases (e.g. mobile) would never happen.
That same wise man has this interesting post. https://florian-rappl.de/News/Page/385/designing-programming-language-for-2019
Oct 02
parent Chris <wendlec tcd.ie> writes:
On Wednesday, 2 October 2019 at 11:00:55 UTC, Paulo Pinto wrote:
 That same wise man has this interesting post.

 https://florian-rappl.de/News/Page/385/designing-programming-language-for-2019
Sounds good, in theory, but even the author can foresee problems: "Great thing about this design is that any version of the language works with any version of the compiler (well, at least if the base part has been done correctly - in practice we will certainly see some dependency here)." But basically I think it's a sound approach.
Oct 02
prev sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 I think no matter what you do, C++ folks will complain. They're 
 just triggered by the word GC. That's why every single 
 discussion thread about D outside of this forums starts at the 
 GC. Then someone will mention  nogc or refcounting. Then 
 someone will chime in about how you lose most of the packages 
 and standard library because it assumes GC is present. And then 
 people will just go "oh man, that is so complicated".
Exactly. ILHO the "BetterC' approach won't help D get new adopters. One the contrary, all the effort spent in removing the GC is useless, as the GC is precisely what makes D a better language over C++. I'm convinced his huge amount of effort should have been spent on making D a better Go/Crystal/etc. As I said earlier, I *REALLY* wanted to implement Cyclone, my CQL/SQL script runner in D. The problem is it was SO MUCH easier to do it in Go, despite is EXTREMELY limited compared to an object oriented language like D : no genericity, no parametric polymorphism, no virtual inheritance, etc. But the language and its standard library provides ALL the building blocks you need to implement web servers (coroutines, HTTP, etc), and the official CQL/SQL database drivers are complete, optimized, well maintained and used extensively. As I already said, it takes you just a few very simple lines of code to implement this script runner in Go, because you can clearly see that the language itself was designed especially for that : manage efficiently HTTP and database connections. Which is nice, because it's the world most developers live in now. Putting so much effort in trying to convince the few developers developing C++ embedded applications to switch to D, while D is a very nice garbage collected language, and so many of us use other ones (Java, C#, JavaScript, Python, PHP, etc) to develop connected applications a completely ineffective strategy, if D wants more contributors. Because as one has said above, with so few contributors working on their spare time or funded by the D sponsors, I think the language should strive to remain as SIMPLE as possible, and first be enhanced to provide what most STANDARD developers need, not to add complicated micro-features which are useless to most of us. And unfortunately, despite their imperfections, it seems that several new languages like Go and Crystal have at least perfectly understood those principles.
Sep 30
next sibling parent reply mipri <mipri minimaltype.com> writes:
On Tuesday, 1 October 2019 at 05:35:22 UTC, Ecstatic Coder wrote:
 As I already said, it takes you just a few very simple lines of 
 code to implement this script runner in Go, because you can 
 clearly see that the language itself was designed especially 
 for that : manage efficiently HTTP and database connections.
I don't disbelieve you, but I also really don't want to learn Go just so that I can understand what D is missing. Do any of these threads ever result in arewexyet type webpages, or even wiki lists of features that D would need to be as good at some role as some other technology? Say, a category of "D Gaps", and pages of the pattern, "I looked at using D for <purpose>, and I missed these conveniences: [list]". Some purposes: 1. data science 2. bioinformatics 3. machine learning 4. scripting Microsoft applications through COM 5. writing CGI scripts 6. writing an Apache module 7. rewriting Python and Perl sysadmin scripts 8. mobile app development 9. desktop app development 10. quick CLI tools that fetch some webpages I've done a lot of these but for bioinformatics f.e. my list of features ends at: * they use 'FASTA files' * they want fast regular expressions * some preferences stemming from them not being 'real programmers' -- not pejoratively, but look at https://www.youtube.com/watch?v=9ZxtaccqyWA occasional remarks about scientists using Python. I bet that a lot of people would deny th things to want to do in the current millennium.
 I think the language should strive to remain as SIMPLE as 
 possible, and first be enhanced to provide what most STANDARD 
 developers need
Are you sure that 'STANDARD developers' even exist? This might be unfair but I see a lot of solipsism in complaints like this. To put it a kinder way, I think you are underestimating how valuable your own experience is in your own industry.
Sep 30
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 1 October 2019 at 06:29:30 UTC, mipri wrote:
 On Tuesday, 1 October 2019 at 05:35:22 UTC, Ecstatic Coder 
 wrote:
 As I already said, it takes you just a few very simple lines 
 of code to implement this script runner in Go, because you can 
 clearly see that the language itself was designed especially 
 for that : manage efficiently HTTP and database connections.
I don't disbelieve you, but I also really don't want to learn Go just so that I can understand what D is missing. Do any of these threads ever result in arewexyet type webpages, or even wiki lists of features that D would need to be as good at some role as some other technology? Say, a category of "D Gaps", and pages of the pattern, "I looked at using D for <purpose>, and I missed these conveniences: [list]". Some purposes: 1. data science 2. bioinformatics 3. machine learning 4. scripting Microsoft applications through COM 5. writing CGI scripts 6. writing an Apache module 7. rewriting Python and Perl sysadmin scripts 8. mobile app development 9. desktop app development 10. quick CLI tools that fetch some webpages I've done a lot of these but for bioinformatics f.e. my list of features ends at: * they use 'FASTA files' * they want fast regular expressions * some preferences stemming from them not being 'real programmers' -- not pejoratively, but look at https://www.youtube.com/watch?v=9ZxtaccqyWA occasional remarks about scientists using Python. I bet that a lot of people would deny th valid things to want to do in the current millennium.
 I think the language should strive to remain as SIMPLE as 
 possible, and first be enhanced to provide what most STANDARD 
 developers need
Are you sure that 'STANDARD developers' even exist? This might be unfair but I see a lot of solipsism in complaints like this. To put it a kinder way, I think you are underestimating how valuable your own experience is in your own industry.
If you disregard Windows as deployment platform, th valid thing to do in currently millennium, given that since Windows Vista COM has been the bread and butter of Windows APIs (nowadays known as UWP), and of recently device drivers as well (universal drivers). Likewise #5 has been reborn as the new fad "serverless computing", again it depends on how long this fad might keep going on the cloud computing generation.
Oct 01
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 01/10/2019 8:45 PM, Paulo Pinto wrote:
 If you disregard Windows as deployment platform, th
 thing to do in currently millennium, given that since Windows Vista COM 
 has been the bread and butter of Windows APIs (nowadays known as UWP), 
 and of recently device drivers as well (universal drivers).
The direct equivalent of COM on *nix is D-Bus. And desktop environments like KDE are pushing a lot of behavior through it. So its written very specifically, but in a more generic form it is entirely valid.
Oct 01
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 1 October 2019 at 05:35:22 UTC, Ecstatic Coder wrote:
 I'm convinced his huge amount of effort should have been spent 
 on making D a better Go/Crystal/etc.

 As I said earlier, I *REALLY* wanted to implement Cyclone, my 
 CQL/SQL script runner in D.

 The problem is it was SO MUCH easier to do it in Go, despite is 
 EXTREMELY limited compared to an object oriented language like 
 D : no genericity, no parametric polymorphism, no virtual 
 inheritance, etc.

 But the language and its standard library provides ALL the 
 building blocks you need to implement web servers (coroutines, 
 HTTP, etc), and the official CQL/SQL database drivers are 
 complete, optimized, well maintained and used extensively.

 As I already said, it takes you just a few very simple lines of 
 code to implement this script runner in Go, because you can 
 clearly see that the language itself was designed especially 
 for that : manage efficiently HTTP and database connections.
But none of this is in any way related to Walter. This is not Walter's area. No matter how many times anyone writes it on the mailing list, Walter will not be writing web servers or database drivers. Your complaint, as written, is a complaint to nobody. This is not a corporation making decisions on where to spend developer time. It is a volunteer project. Sure, you can vent on the mailing list, but you don't have anyone to be the target of your anger. It's ultimately 100% wasted electrons unless you have a proposal to go along with it that will result in the work getting it done. "D should do X" posts do not have any value unless they go a step further to suggest a solution beyond "someone else should do all the work". That is simply reality. Did you even put together a proposal for GSoC or SAoC? It's easy to generate ideas of what some mythical developer should do. It's much harder to actually make it happen.
Oct 01
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
 It's easy to generate ideas of what some mythical developer 
 should do. It's much harder to actually make it happen.
I was just saying that the way the D sponsors funds are used towards C-like application programming doesn't seem optimal to me, as I personally think D is a nice garbage collected language for general application programming. But hey, that's just my two cents...
Oct 01
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 1 October 2019 at 05:35:22 UTC, Ecstatic Coder wrote:
 As I said earlier, I *REALLY* wanted to implement Cyclone, my 
 CQL/SQL script runner in D.
are you familiar with my libraries? your code there looks trivial to do in D, the only piece I don't have sitting on my shelf is the cassandra one, and since there's a C library for that, that'd be easily accessible with my framework. I think it is folly to insist on rewriting everything in your own language/library of choice. I'll agree there - the big guys might be able to do that (or be popular enough to get the other companies to officially support you) but D isn't really in that position. But we do have excellent interop with the lingua franca of apis - C. I have had reliable database code for ages because I just use an interface over the official C client libraries. HTTP I wrote from scratch, but even that got bootstrapped by reusing the existing stuff - the original cgi interface (which btw is now a misnomer, since it does let you do an embedded server) did the bare minimum to talk to apache and iis servers! And the original http client I did called curl. I have since replaced that with scratch too, but I still think curl is a decent way to do it. anyway though i just wonder if you tried it and found it sucked (or didn't try it cuz you saw it and was like "this sux" - to this day my docs are super light) or just didn't see it.
Oct 01
next sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Tuesday, 1 October 2019 at 12:29:59 UTC, Adam D. Ruppe wrote:
 On Tuesday, 1 October 2019 at 05:35:22 UTC, Ecstatic Coder 
 wrote:
 As I said earlier, I *REALLY* wanted to implement Cyclone, my 
 CQL/SQL script runner in D.
are you familiar with my libraries? your code there looks trivial to do in D, the only piece I don't have sitting on my shelf is the cassandra one, and since there's a C library for that, that'd be easily accessible with my framework. I think it is folly to insist on rewriting everything in your own language/library of choice. I'll agree there - the big guys might be able to do that (or be popular enough to get the other companies to officially support you) but D isn't really in that position. But we do have excellent interop with the lingua franca of apis - C. I have had reliable database code for ages because I just use an interface over the official C client libraries. HTTP I wrote from scratch, but even that got bootstrapped by reusing the existing stuff - the original cgi interface (which btw is now a misnomer, since it does let you do an embedded server) did the bare minimum to talk to apache and iis servers! And the original http client I did called curl. I have since replaced that with scratch too, but I still think curl is a decent way to do it. anyway though i just wonder if you tried it and found it sucked (or didn't try it cuz you saw it and was like "this sux" - to this day my docs are super light) or just didn't see it.
Indeed I didn't wanted to spend my week end trying to use low-level C libraries or fixing the Cassandra package because it is incomplete and abandoned since several years. As I say, the easy path to success was to use Go, for all the reasons I've explained. Call this lazyness if you want, but my spare time was limited to a few hours, and IMO D didn't allow me to easily implement this very simple tool with just a few line of high level code like I did in Go. I understand that D's philosophy is that you must put efforts to do this kind of development with it. My philosophy is to take the tool which allows me to program what I need quickly and efficiently. And for anything related to web and database technologies, D is definitely not the path of less friction.
Oct 01
prev sibling parent JN <666total wp.pl> writes:
On Tuesday, 1 October 2019 at 12:29:59 UTC, Adam D. Ruppe wrote:
 are you familiar with my libraries? your code there looks 
 trivial to do in D, the only piece I don't have sitting on my 
 shelf is the cassandra one, and since there's a C library for 
 that, that'd be easily accessible with my framework.
I think the difference is, since Go has libraries like http in standard library, or de facto standard library, even if it's an external package, it's been included in thousands of projects since and went through a lot of testing. Even though I like your libraries and have used them a few times, they haven't been as battletested. There might be missing vital functionalities (which you didn't just need for the moment), or there might be some nasty bugs lurking which just weren't triggered for the usual usecases. And if I were making a real web application, not a hobby project, I want to fully trust the libraries. I want to include the library and make use of it, and move on to more fun stuff. I don't want to debug the library whenever something breaks.
Oct 01
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
 D is theoretically in a good position to do a spring cleaning. 
 It has loads of features. Take what really works (battle-tested 
 features), drop all the half-baked features that only a 
 minority really uses. Improve the stability of the language and 
 set up a proper ecosystem (e.g. out of the box compilation for 
 various platforms / architectures).
In theory, yes, but in order to make it easy for open source contributions to be made the compiler would have to be made modular and basically rewritten from scratch. A spring cleaning should not only focus on the language itself, but focus on attracting new contributors. Quite frankly, a higher regard for basic computer science would go a long way... I think the Rust community has benefitted greatly for taking the field of computer science very seriously (perhaps even a bit too far in that direction, but it builds a very solid group identity).
 1. Take D's great features that are battle-tested
 2. See what is not strictly necessary and drop it (dead 
 weight), i.e. figure out what programmers need 90-95% of the 
 time and don't pollute the language with features you only need 
 in the remaining 5-10% of the cases.
 3. Set up a sound and stable ecosystem

 But then again, I fear this will never happen.
It won't happen, and it would only succeed if you focus on a carefully selected set of use cases. Which basically has been D's main problem since D2. D1 had the advantage of being a simple upcoming alternative to C++, which at that point was a niche with no contenders. Today, you have to provide some use cases where the eco-system has next to no competition and where it excels. There are contenders in most niches... at that point the eco-system is no longer optional... It could be Linux. It could be embedded. It could be games development. It could be scientific computing. It could be web development (although in that case the language has to be made more forgiving). It cannot be iphone, android, database-integration or any other area where the eco-system is incredibly expensive to both build and maintain. (That includes Python's scripting niche, despite D developers saying that they prefer D over Python for scripting tasks.) You really need a niche to grow from to get that ecosystem going. Go is a very good example of this. They kept the language small. And the "owner" Google decided that it was primarily good for writing web services and put a lot of resources into the runtime, not the language. The Go language is not a lot better for writing web services than other languages. The runtime and ecosystem in combination with the basic language is what makes it a strong contender in that space. TypeScript, same story. It is very difficult to make a sales pitch for a language if it does not have an ecosystem that makes it a strong contender in at least one niche. After 20 years... that becomes a problem. Even if the language had been perfect, that lack of a niche where you are a strong contender is problematic. You see this with Kotlin too, it is now a strong contender in the Android niche. That clearly makes a big difference in how the language eco system evolves...
Sep 30
parent reply JN <666total wp.pl> writes:
On Monday, 30 September 2019 at 10:13:13 UTC, Ola Fosheim Grøstad 
wrote:
 It won't happen, and it would only succeed if you focus on a 
 carefully selected set of use cases. Which basically has been 
 D's main problem since D2. D1 had the advantage of being a 
 simple upcoming alternative to C++, which at that point was a 
 niche with no contenders.
D1 wasn't simple, but it had a good set of features. It was a language that felt like C#, yet was native and had pointers. Like the best of two worlds of unmanaged and managed. And compared to C++ it looked amazing.
 Go is a very good example of this. They kept the language 
 small. And the "owner" Google decided that it was primarily 
 good for writing web services and put a lot of resources into 
 the runtime, not the language.  The Go language is not a lot 
 better for writing web services than other languages. The 
 runtime and ecosystem in combination with the basic language is 
 what makes it a strong contender in that space.
And yet people now use it for other things they'd use C/C++ for, because the language and ecosystem is good enough.
 TypeScript, same story.
Good timing and easy transition story. Most people were frustrated with Javascript for a long time and the ECMAScript committee took ages to add new features such as classes, which people were asking from.
Sep 30
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 30 September 2019 at 10:47:14 UTC, JN wrote:
 D1 wasn't simple, but it had a good set of features. It was a 
 language that felt like C#, yet was native and had pointers. 
 Like the best of two worlds of unmanaged and managed. And 
 compared to C++ it looked amazing.
I meant that it was simple compared to C++ and D2. D1 was clearly more complex than Pascal! More importantly, one could prototype things faster in D1 than in C++98, which made it a promising newcomer. Although, I gave up on the first releases of D1 for pragmatic reasons: compiler quality, error messages, code gen, underperforming GC, no real alternative to the GC that improves on C memory management. Yet, at that point that could be seen as baby-illnesses and developers would come back every once in a while to see if D1 was maturing. Unfortunately, the key issues with D1 wasn't fixed and new features was added instead of making the foundation really solid before adding more features. As a result D2 become more like C++, without being compatible and still having the baby-illnesses. I personally think that the D1 feature set was good enough for embedded and simple audio/graphics programming if the rest had been polished thoroughly. There was a lot of enthusiasm for D1 that you don't see for D2, IMHO.
 And yet people now use it for other things they'd use C/C++ 
 for, because the language and ecosystem is good enough.
Yes, but only because hardware has more speed/memory today than when those programs were written in C/C++. So, this is what has been going on for the past 50 years. Code that was written in machine language could be implemented in C, then in Java, then in Python or TypeScript. Some software go from C to Go as well, true, but mostly because that software didn't really require the C feature set.
 TypeScript, same story.
Good timing and easy transition story. Most people were frustrated with Javascript for a long time and the ECMAScript committee took ages to add new features such as classes, which people were asking from.
Right, so I guess we have these "parasitic" transitions for both C++, Kotlin and TypeScript.
Sep 30
prev sibling parent reply JN <666total wp.pl> writes:
On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
 Atm, I'm mainly using Kotlin and I have to say that a small set 
 of clever and well thought-out features can get you a long way. 
 Do I miss some of D's features? Not really, because Kotlin 
 provides enough useful and battle-tested features that you need 
 90% of the time [1]. Once I missed `static if`, but I could 
 live without it.

 Mind you, Kotlin has some restrictions due to the fact that it 
 has to be a 100% compatible with Java/JVM. But even when you 
 use Kotlin/Native (without the Java universe, i.e. modules and 
 libraries) you can get quite far. I think D should aim at that.
I think Kotlin's dependency on Java/JVM is actually a benefit, because they know what worked and didn't work in Java and could work on improving that. Also, they are 100% behind the OOP paradigm, so they can introduce most features that benefit that. For example features like data classes or singleton objects are very useful, even if they are mostly a language syntax sugar for certain design patterns.
Sep 30
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 30 September 2019 at 10:14:52 UTC, JN wrote:
 I think Kotlin's dependency on Java/JVM is actually a benefit, 
 because they know what worked and didn't work in Java and could 
 work on improving that.
Actually, it is a big disadvantage, except for one thing: they can piggyback on the ecosystem and cut down the costs of developing a solid runtime system. In that Kotlin has the same advantage of being able to gradually take over for Java, which is comparable to how C++ could gradually take over for C.
Sep 30
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Monday, 30 September 2019 at 10:14:52 UTC, JN wrote:

 I think Kotlin's dependency on Java/JVM is actually a benefit, 
 because they know what worked and didn't work in Java and could 
 work on improving that. Also, they are 100% behind the OOP 
 paradigm, so they can introduce most features that benefit 
 that. For example features like data classes or singleton 
 objects are very useful, even if they are mostly a language 
 syntax sugar for certain design patterns.
Yeah, I agree, Kotlin has done a great job on that. Kotlin has added a lot of nice features to the old Java/JVM world. Data classes are very useful, and it's really easy to use Singletons. My point was, that the authors of Kotlin cannot do whatever they want due to Java/JVM, and still they managed to come up with a sound language.
Sep 30
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 30 September 2019 at 10:14:52 UTC, JN wrote:
 On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
 Atm, I'm mainly using Kotlin and I have to say that a small 
 set of clever and well thought-out features can get you a long 
 way. Do I miss some of D's features? Not really, because 
 Kotlin provides enough useful and battle-tested features that 
 you need 90% of the time [1]. Once I missed `static if`, but I 
 could live without it.

 Mind you, Kotlin has some restrictions due to the fact that it 
 has to be a 100% compatible with Java/JVM. But even when you 
 use Kotlin/Native (without the Java universe, i.e. modules and 
 libraries) you can get quite far. I think D should aim at that.
I think Kotlin's dependency on Java/JVM is actually a benefit, because they know what worked and didn't work in Java and could work on improving that. Also, they are 100% behind the OOP paradigm, so they can introduce most features that benefit that. For example features like data classes or singleton objects are very useful, even if they are mostly a language syntax sugar for certain design patterns.
If Kotlin wants to stay relevant on the Java/JVM platform (Android is another matter), they cannot come up with incompatible designs that force FFI jumps between platform semantics and whatever they come up with in Kotlin land. Some examples of these impedance mistmatch are already visible, namely memory semantics between Kotlin/JVM and Kotlin/Native, sequences vs JVM streams, Kotlin lambdas vs JVM SAM types. Same applies to whatever reboot might happen with D.
Sep 30
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 29 September 2019 at 20:39:19 UTC, Ecstatic Coder 
wrote:
 And as a "true" C++ alternative, D is far from being the best 
 choice. I'd rather choose Rust, Zig and even Nim for my typical 
 C/C++ use case, despite indeed it's obviously *possible* to use 
 D for that, precisely because I know D's major pain points.
In all fairness, D started out as an alternative to C++, but didn't align it's semantics when C++11 came. That would be necessary to get good integration. At this point it is too late as Rust and other alternatives have reached critical mass. So, I don't think one can argue this only in terms of "what is" and "what isn't", timing is a big factor.
Sep 29
prev sibling parent reply GreatSam4sure <greatsam4sure gmail.com> writes:
On Sunday, 29 September 2019 at 01:29:59 UTC, Benjiro wrote:
 On Friday, 27 September 2019 at 15:11:26 UTC, GreatSam4sure 
 wrote:
 The biggest problem to D adoption is this community IMHO. 
 Almost everything here is negative. The community is 95% 
 negative to the language. There are people here that never see 
 anything good about D yet they are here. The community is 
 damaging to D image.

 It is a community that is out to destroy the language. All the 
 hope of me using D has been almost destroyed.
As one of these negative people that from time to time reads up on multiple languages forums. D was one of the first languages after moving away from Web dev, that i liked from structure point. Even got the book from Ali. But ... the more i worked with it, the more frustration, upon frustration, upon ... kept creeping in with constant issues. * Not user friendly tooling ( somewhat improved, took only a few years ) * Compiler bugs. O those bugs ... * Upgrading the compiler resulting in packages ( like vibe.d going broke ) * Lacking IDE support ( somewhat improved on Visual Studio Code ) * Lacking in packages to easily get going. * Constant and frustrating changing direction. BetterC? First get BetterD doing and when your a big boy, then do this. * The feeling off being looked down when suggestion that D is not user friendly. Especially in the past you constantly got this as a answer: "you have a issue, fix it yourself". Yes, this was the constant answer from everybody. * The snarky and frankly poison comments from regular members. Some of those now seem to have left but D really has some members that got under anybody their skin for daring to mention a issue. * Focus upon C++ crowd, when very few C++ developers have any interest in D. Hell, if a C++ developer wants to switch, they have better alternatives with bigger or better growing communities. * A leadership that seems to be stuck in the 1990's mentality. The world has moved on, people expect more these days, they have choices most old timers did not have. So they are more spoiled with those choices and are not going to put in the time. But when you ignore those "spoiled" people, you never build up a loyal base and you will never motivate them to help out with code or money. You can not run anything worth while with D unless you plan on spending a lot of time writing supporting code yourself. Some companies have no issue with this but little old me can not be bothered with it, when there are plenty of good alternatives that get the job done as good. * I know one of the posters on this forum a bit more personal. We have had some discussions about the different compilers. Just as he used Go for his personal project, i used Crystal for mine. We both found D too much trouble for the advantages it gave. Its a vicious circle and i know it. Lack in people / contributors => No Packaging / Bugs / Issues => New people scared away => Lack in people / contributors .... * D just is not sexy. I know D now from 10/2016 ( when i got Ali's book. Programming in D ). Loved the book and language syntax ( especially if you come from PHP ) but it was all the rest that ruined it for me. And over the years D seems to have been going down a direction that i hated. New features that had no meaning for me, code breaking issues and resources being put in features like BetterC, when all i wanted was a god darn simple HTTP server that worked and kept working on release updates. And more active packages. * On the subject of Programming in D, i noticed a lot of books are old. BetterC, the feature where a lot of resources have gone into, seems to be ignored in every book on the market. ------------------------------ To give you a nice example how much of a irritation D can be even today. Just right now, i tried to install D on Ubuntu because i want to time the current D compile speed, vs a few other languages. And i am following the official order ( https://dlang.org/download.html ): 1. sudo wget http://master.dl.sourceforge.net/project/d-apt/files/d-apt.list -O /etc/apt/sources.list.d/d-apt.list 2. sudo apt-get update && sudo apt-get -y --allow-unauthenticated install --reinstall d-apt-keyring 3. sudo apt-get update && sudo apt-get install dmd-compiler dub Guess what happens on Step 2.
 Err:7 https://netcologne.dl.sourceforge.net/project/d-apt 
 d-apt InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EBCF975E5BA24D5E And this issue was posted a LONG time ago. Yep ... Now try Go, Crystal, Nim, Rust, ... and a lot of other languages. I have installed all those dozens of times and a issue like simply do not show up or are fixed so fast, that it never hits "me". But whenever it involves D, its always one thing or another. ------------------------------ Hopefully this explains things from my point of view, where D simply fails me personally. Its late so i am off to bed.
I can reckon with you in your paid and frustration. It is real. My personal frustration with D is that the language is too good to be where it is today. To me D is the best language I ever known of.I am not in any way ignorant of the languages out there. D packages don't work out of the box. They throw errors here and there. The tooling sets is also weak and little tutorial. Many aspects of D are known to only a few. But the Languages is truly elegant. I also see the leaders have not been able to work with the community coherently. There is too much dichotomy in the forum. Some people have even decided to keep quiet and just observed the trends of things. I really did not blame them. Some have left, like the android guy. It is time to change our attitudes and begin to look for the way forward. Negativity is obviously not the solution. Insult and yelling are out of point. Ways is the way forward a change of philosophy and mindset. A critical examination of why we are the way we are, like a survey that will be back by implementations. Working coherently together as against working individually. I think we need the humility of heart and humbleness of mind to accept that where we are today is far behind. We are behind not much of a cooperate sponsor but of our own making. Harmony is the first step to grow in a community. The division is one major cause of our backwardness and lack of fast progress. We much realize what is against us and correct to move to our desired level. I am willing to help in any capacity I can but I don't know how since my programming skill is still low. I need to grow more. If all D packages can work out of the box, the compiler can minimize breakages and the community can unity D will become the best language in the world. Looking forward to a better D.
Sep 30
parent Meta <jared771 gmail.com> writes:
On Monday, 30 September 2019 at 12:25:46 UTC, GreatSam4sure wrote:
 There is too much dichotomy in the forum. Some people have even 
 decided to keep quiet and just observed the trends of things. I 
 really
 did not blame them. Some have left, like the android guy.
To be clear, the "Android Guy", AKA Joakim, left due to having (one or more, can't remember) over-the-line posts deleted. It was a personal problem on his part, not any kind of problem with the D community (which is by no means perfect, obviously). A better example is Kenji Hara.
 It is time to change our attitudes and begin to look for the 
 way forward. Negativity is obviously not the solution. Insult 
 and yelling are out of point. Ways is the way forward a change 
 of philosophy and mindset. A critical examination of why we are 
 the way we are, like a survey that will be back by 
 implementations. Working coherently together as against working 
 individually.

 I think we need the humility of heart and humbleness of mind to 
 accept that where we are today is far behind. We are behind not 
 much of a cooperate sponsor but of our own making. Harmony is 
 the first step to grow in a community. The division is one 
 major cause of our backwardness and lack of fast progress. We 
 much realize what is against us and correct to move to our 
 desired level.
I don't agree that D is "way behind", but its velocity is certainly slower than Go/Rust/C++. I think this comes down to money=acceleration. However, if you look at what's happened even in just the past 7 years, D has "accelerated" dramatically - a yearly conference, real companies successfully using D and even contributing back to D's development, a far more stable compiler and standard library, a thriving package ecosystem... to quote Andrei, it's an "embarassment of riches".
Sep 30
prev sibling next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 What do you think about it?
I like how they are going to maintain a stable 1.0 branch and continue developing on a 1.1 branch. I wonder if something like that could work for D.
Sep 25
next sibling parent Chris <wendlec tcd.ie> writes:
On Wednesday, 25 September 2019 at 14:58:43 UTC, Dennis wrote:
 On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 What do you think about it?
I like how they are going to maintain a stable 1.0 branch and continue developing on a 1.1 branch. I wonder if something like that could work for D.
I'd say this should be the standard procedure.
Sep 25
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 25 September 2019 at 14:58:43 UTC, Dennis wrote:
 On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 What do you think about it?
I like how they are going to maintain a stable 1.0 branch and continue developing on a 1.1 branch. I wonder if something like that could work for D.
I believe this is the intent behind the `-preview` and `-revert` compiler options, though they work on a feature-by-feature basis rather than affecting the entire language at once.
Sep 25
prev sibling next sibling parent reply Rel <relmail rambler.ru> writes:
It is kinda strange to see, how discussion went from "Nim hitting 
1.0" to "what I dislike about D" in a matter of few posts. 
Obviously programming languages are tools and there is no ideal 
programming language. D is opinionated like many other languages, 
the design and most of the compiler work is mainly done by few 
core members of the team. While I think it would be nice to have 
Rust's automatic memory management at compile time or Go's 
awesome standard library or Zig's error handling enforcement in 
D, in reality core members won't be available to keep up with all 
new trends in programming languages. You don't have to use D for 
everything, use D for stuff that D fits nicely. Or go make D3 
with all the features you like (you can use D2 to bootstrap the 
compiler, use LLVM as a backend and etc).
Oct 01
next sibling parent Samir <samir aol.com> writes:
On Tuesday, 1 October 2019 at 22:18:05 UTC, Rel wrote:
 It is kinda strange to see, how discussion went from "Nim 
 hitting 1.0" to "what I dislike about D" in a matter of few 
 posts. Obviously programming languages are tools and there is 
 no ideal programming language. D is opinionated like many other 
 languages, the design and most of the compiler work is mainly 
 done by few core members of the team. While I think it would be 
 nice to have Rust's automatic memory management at compile time 
 or Go's awesome standard library or Zig's error handling 
 enforcement in D, in reality core members won't be available to 
 keep up with all new trends in programming languages. You don't 
 have to use D for everything, use D for stuff that D fits 
 nicely. Or go make D3 with all the features you like (you can 
 use D2 to bootstrap the compiler, use LLVM as a backend and 
 etc).
This thread in general, and some earlier posts in particular, inspired me to document why I have been using D lately. I wrote it up here: http://samirparikh.com/blog/adventures-in-dlang.html From a beginner's perspective, it's the active community on these lists that have helped me out the most.
Oct 01
prev sibling parent reply JN <666total wp.pl> writes:
On Tuesday, 1 October 2019 at 22:18:05 UTC, Rel wrote:
 It is kinda strange to see, how discussion went from "Nim 
 hitting 1.0" to "what I dislike about D" in a matter of few 
 posts. Obviously programming languages are tools and there is 
 no ideal programming language. D is opinionated like many other 
 languages, the design and most of the compiler work is mainly 
 done by few core members of the team. While I think it would be 
 nice to have Rust's automatic memory management at compile time 
 or Go's awesome standard library or Zig's error handling 
 enforcement in D, in reality core members won't be available to 
 keep up with all new trends in programming languages. You don't 
 have to use D for everything, use D for stuff that D fits 
 nicely. Or go make D3 with all the features you like (you can 
 use D2 to bootstrap the compiler, use LLVM as a backend and 
 etc).
No one claims that. The general idea expressed in this thread is that D isn't opinionated enough. Would it be nice to have those features? Depends on the person. Personally I don't care much about Rust's memory management or Zig's error handling. I don't mind GC. But there are people here who do, and for them it could be appealing. As for D3 with all the features you like, I'd rather see D3 with half the features :)
Oct 02
parent reply tester <tester test.aol> writes:
On Wednesday, 2 October 2019 at 07:20:00 UTC, JN wrote:
 On Tuesday, 1 October 2019 at 22:18:05 UTC, Rel wrote:
 As for D3 with all the features you like, I'd rather see D3 
 with half the features :)
Yup - lets go back to D1 sort of and I am serious aout that.
Oct 02
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 2 October 2019 at 09:57:40 UTC, tester wrote:
 On Wednesday, 2 October 2019 at 07:20:00 UTC, JN wrote:
 On Tuesday, 1 October 2019 at 22:18:05 UTC, Rel wrote:
 As for D3 with all the features you like, I'd rather see D3 
 with half the features :)
Yup - lets go back to D1 sort of and I am serious aout that.
Yes, something like that, but now D2 has too many features that are being used by the organizations that use D. I think some of the (half-baked) features were actually introduced to cater for their needs. I suppose that the organizations that are using D2 now will not accept a trimmed down version of D by now. I'd say it's too late.
Oct 02
parent tester <tester test.aol> writes:
On Wednesday, 2 October 2019 at 10:04:44 UTC, Chris wrote:
 Yes, something like that, but now D2 has too many features that 
 are being used by the organizations that use D. I think some of 
 the (half-baked) features were actually introduced to cater for 
 their needs. I suppose that the organizations that are using D2 
 now will not accept a trimmed down version of D by now. I'd say 
 it's too late.
Well, I guess then it is too late for me to start using D. Best of luck for all of you.
Oct 02
prev sibling next sibling parent reply Jack Applegame <japplegame gmail.com> writes:
On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
 https://nim-lang.org/blog/2019/09/23/version-100-released.html

 Well, finally Nim team released 1.0. Now future releases 
 shouldn't break people's code and this fact should increase 
 language adoption. Still few things seems to be unfinished 
 (like their NewRuntime thing), but I'd like to congratulate 
 Nim's team with this big release. What do you think about it?
I recently tried Nim. The first good impression was quickly replaced by disappointment. No nested types, constants and functions. Poor generics and templates (but macros are great). Primitive modules system. Unclear error messages. But. Nim's GC (including boehm) is much faster then D's one. And Nim compiler creates very compact binaries.
Oct 05
parent reply Chris <wendlec tcd.ie> writes:
On Saturday, 5 October 2019 at 08:01:15 UTC, Jack Applegame wrote:

 I recently tried Nim. The first good impression was quickly 
 replaced by disappointment.

 No nested types, constants and functions. Poor generics and 
 templates (but macros are great). Primitive modules system. 
 Unclear error messages.

 But. Nim's GC (including boehm) is much faster then D's one. 
 And Nim compiler creates very compact binaries.
I suppose Nim is not trying to have all features one can possibly look for in a programming language, rather it's designed as a "native Python" and that'd be great from my point of view. If researchers used Nim to write code that they usually write in Python, it'd speed up the development of real world programs (especially for programs where performance is of the essence). There is a trend (started by Google?) to keep PLs simple so that a) non-programmers can write code too and b) the code is more robust. Go is one example and now definitely Dart, i.e. there's only so much you can do / choose from. C++ is out of the question and D is somewhere between C++ and Python, fast modelling but way too many features for people who are not really into programing.
Oct 07
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 7 October 2019 at 10:38:49 UTC, Chris wrote:
 there's only so much you can do / choose from. C++ is out of 
 the question and D is somewhere between C++ and Python, fast 
 modelling but way too many features for people who are not 
 really into programing.
I don't think features necessarily is a problem. Python has an incredible amount of features and is rather complex if you want to master it all, but you usually don't have to deal with it if you just want to solve a problem. So what is important is to have a smooth curve of incremental learning and keep the features out of the application level programming interface. C++ is at the other end of the spectrum, not because of features, but because you cannot make good use of it (outside the C-subset) without being proficient. So when newbies complain about not understanding the documentation for the standard library of a language, then that could be a sign of not supporting the incremental learning process as well as desired. Sort of.
Oct 07
parent reply Chris <wendlec tcd.ie> writes:
On Monday, 7 October 2019 at 14:20:10 UTC, Ola Fosheim Grøstad 
wrote:
 I don't think features necessarily is a problem. Python has an 
 incredible amount of features and is rather complex if you want 
 to master it all, but you usually don't have to deal with it if 
 you just want to solve a problem. So what is important is to 
 have a smooth curve of incremental learning and keep the 
 features out of the application level programming interface.

 C++ is at the other end of the spectrum, not because of 
 features, but because you cannot make good use of it (outside 
 the C-subset) without being proficient.

 So when newbies complain about not understanding the 
 documentation for the standard library of a language, then that 
 could be a sign of not supporting the incremental learning 
 process as well as desired.

 Sort of.
Yes. However, D is a bit like C++ in the sense that you have to be proficient or else it's very hard to make sense of it. Templates, ranges and lambdas are everywhere.
Oct 07
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 7 October 2019 at 14:38:01 UTC, Chris wrote:
 Yes. However, D is a bit like C++ in the sense that you have to 
 be proficient or else it's very hard to make sense of it. 
 Templates, ranges and lambdas are everywhere.
Yes, it becomes problematic when you need that kind of knowledge to use the std lib API. The questions newbies ask also suggests that having two different types of pointers increases the learning curve. How arrays reallocate when expanded is another surprise for newbies... and so on. By keeping track of what newbies ask about, one could probably learn a lot, but it has always been the case that seasoned D-programmers tend to have more influence over the direction than newbies. Which probably is why the language keeps heading in that direction...
Oct 07
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Mon, 2019-10-07 at 10:38 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]
 There is a trend (started by Google?) to keep PLs simple so that=20
 a) non-programmers can write code too and b) the code is more=20
 robust. Go is one example and now definitely Dart, i.e. there's=20
 only so much you can do / choose from. C++ is out of the question=20
 and D is somewhere between C++ and Python, fast modelling but way=20
 too many features for people who are not really into programing.
I believe the publicly released rationale for Go: =E2=80=93 A modern update on C: remove the obvious cruft of C, add object-b= ased and GC. =E2=80=93 A language very fast to parse and code generate. =E2=80=93 Include modern approach to parallelism and concurrency in the lan= guage: processes and channels on a thread pool. =E2=80=93 Include a modern approach to code reuse =E2=80=93 it is not total= ly clear Go has yet achieved this. =E2=80=93 A language in which Google interns cannot make big errors. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Oct 07
prev sibling parent reply IGotD- <nise nise.com> writes:
One Achilles heel of Nim is that it compiles via C or C++. This 
means in a debugging environment you will be watching the 
environment of the intermediate language. There workarounds for 
this described here.

https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#using-gdb-lldb

However, this doesn't solve everything. Also all the variable are 
intermixed with generated symbols, probably with some ugly hash 
added to it. Languages that directly compiles to the target like 
D will give a better debugging environment.

There is a attempt make Nim compile via LLVM instead.

https://github.com/arnetheduck/nlvm

not sure if it is in any productive state yet. Also Nim seems to 
allow C to intermix and all sorts of built in C features that 
will not work when going via LLVM. Trying to merge Nim with C 
features is a bad decision in my opinion.
Oct 09
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 9 October 2019 at 13:52:18 UTC, IGotD- wrote:
 One Achilles heel of Nim is that it compiles via C or C++. This 
 means in a debugging environment you will be watching the 
 environment of the intermediate language. There workarounds for 
 this described here.

 https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#using-gdb-lldb

 However, this doesn't solve everything. Also all the variable 
 are intermixed with generated symbols, probably with some ugly 
 hash added to it. Languages that directly compiles to the 
 target like D will give a better debugging environment.

 There is a attempt make Nim compile via LLVM instead.

 https://github.com/arnetheduck/nlvm

 not sure if it is in any productive state yet. Also Nim seems 
 to allow C to intermix and all sorts of built in C features 
 that will not work when going via LLVM. Trying to merge Nim 
 with C features is a bad decision in my opinion.
There are some things I'm not happy with either. But I think, as has been mentioned before, the purpose of Nim is to be a "native Python", i.e. it produces fast native stand alone binaries and you don't need Cython or an interpreter (Nim does that in one go). So the route via C/C++ seems acceptable from Nim's point of view. As I have no real world experience with Nim, I don't know how often you'll actually need to go low-level when debugging.
Oct 09
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 9 October 2019 at 14:00:46 UTC, Chris wrote:
 There are some things I'm not happy with either. But I think, 
 as has been mentioned before, the purpose of Nim is to be a 
 "native Python", i.e. it produces fast native stand alone 
 binaries and you don't need Cython or an interpreter (Nim does 
 that in one go).
Interesting that you take that viewpoint, that seems also to be the angle some in the press are going with: https://www.zdnet.com/article/python-inspired-nim-version-1-0-of-the-programming-language-launches/ I personally think that probably won't work out for Python programmers, but it is at least a good marketing strategy. Although if compiled Python is the goal the goal, I'd think that Go would be the best "VM" today.
 So the route via C/C++ seems acceptable from Nim's point of 
 view. As I have no real world experience with Nim, I don't know 
 how often you'll actually need to go low-level when debugging.
What works reasonably well in the JavaScript world for TypeScript is source-maps. So that you step through the TypeScript code, but the debugger executes JavaScript. Something similar ought to be possible for C, but probably takes a commercial-level effort to be usable.
Oct 10
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 10 October 2019 at 08:16:40 UTC, Ola Fosheim Grøstad 
wrote:

 Interesting that you take that viewpoint, that seems also to be 
 the angle some in the press are going with:

 https://www.zdnet.com/article/python-inspired-nim-version-1-0-of-the-programming-language-launches/

 I personally think that probably won't work out for Python 
 programmers, but it is at least a good marketing strategy. 
 Although if compiled Python is the goal the goal, I'd think 
 that Go would be the best "VM" today.
Well, with the advent of GraalVM that already supports Python [1] and R [2], it will be much harder for Nim to convince Python users and data miners who use R to make the switch. If you have one VM that is polyglot you can combine all the widely used tools, e.g. Java/Kotlin for server/backend, desktop and (maybe) apps, Python and R for stats. [1] https://www.graalvm.org/docs/reference-manual/languages/python/ [2] https://www.graalvm.org/docs/reference-manual/languages/r/
Oct 10
parent reply Marek Marczak <siloamx gmail.com> writes:
On Thursday, 10 October 2019 at 10:40:00 UTC, Chris wrote:
 Well, with the advent of GraalVM that already supports Python 
 [1] and R [2], it will be much harder for Nim to convince 
 Python users and data miners who use R to make the switch. If 
 you have one VM that is polyglot you can combine all the widely 
 used tools, e.g. Java/Kotlin for server/backend, desktop and 
 (maybe) apps, Python and R for stats.
Ekm... GraalVM has poor Python support. "Warning: The support for Python is experimental. Experimental features might never be included in a production version, or might change significantly before being considered production-ready."
Oct 18
parent Chris <wendlec tcd.ie> writes:
On Friday, 18 October 2019 at 16:28:47 UTC, Marek Marczak wrote:
 On Thursday, 10 October 2019 at 10:40:00 UTC, Chris wrote:
 Well, with the advent of GraalVM that already supports Python 
 [1] and R [2], it will be much harder for Nim to convince 
 Python users and data miners who use R to make the switch. If 
 you have one VM that is polyglot you can combine all the 
 widely used tools, e.g. Java/Kotlin for server/backend, 
 desktop and (maybe) apps, Python and R for stats.
Ekm... GraalVM has poor Python support. "Warning: The support for Python is experimental. Experimental features might never be included in a production version, or might change significantly before being considered production-ready."
Oh, I know that and they saliently state it on the website. But who knows, in 2 or three years GraalVM may be truely polyglot and take languages like Python to new places. But you never know. Oracle might just kill the whole thing again.
Oct 20