Re: D future ...

2017-02-19 Thread Patrick Schluter via Digitalmars-d

On Sunday, 19 February 2017 at 12:12:07 UTC, timmyjose wrote:
I do love C++11 and newer, but I'd rather not use it for any 
new projects barring some weekend projects of my own. The type 
system is horrendously outdated. If they could make a clean 
break and make C++11 the basis, improve error checking, 
bounds-checking, and warning messages, and get rid of the C 
legacy (of course, that's never going to happen), it would make 
for a fine language.



That language exists, it's called D. ;-)



Re: D future ...

2017-02-19 Thread rikki cattermole via Digitalmars-d

On 20/02/2017 1:25 AM, timmyjose wrote:

On Tuesday, 20 December 2016 at 15:42:16 UTC, bachmeier wrote:

On Tuesday, 20 December 2016 at 15:17:56 UTC, Benjiro wrote:

I do not recall seeing on the C++ and other forums this constant
attitude from fix it yourselves or put it in the libraries or ... Its
mostly on the smaller languages where they lack people. And at the
same time, that is a very scary though for companies who want to use
a language.


I think it's important to be realistic. One of D's limitations is that
it does not have the money of Microsoft or Intel behind it, and it
does not have hundreds of billion-dollar corporations depending on it
for critical business operations. Volunteer organizations will be run
differently from outfits that have large budgets to pay people to do
the ugly work. This is not an excuse, it is simply the current state
of affairs.


I'm completely new to the D scene, but I do want to make a comment here.
One of the reasons why a language like Rust is seeing a surge in
popularity is because the core team in Mozilla are evangelising it like
you wouldn't believe it. Rust is a fairly old language, and yet the way
they present it would fool anybody new to the language. Some things I
noticed about their approach (having been part of the community for a
little while) -

  1). Have a nifty, minimalistic website (D has a pretty good website as
well, but I feel it is a bit overwhelming for newbies).

  2). Present the core strengths of the language on the main page itself
in a brief sentence (even though they are more half-truths than anything
else).

  3). They hired someone like Steve Klabnik to give talk after talk, and
no matter what you may think of him, he is very good at "connecting"
with the younger folks, and like it or not, the next generation is the
target audience that will decide if a language is succesful or not.
In my opinion (also based on posts that some D users have made on
the Rust user group), D is actually a much more coherent and powerful
language than Rust, but most people (including myself) wouldn't have
known about it on face value.

Self-promotion is something that needs to be done, and the Rust group is
very good at it. Go, on the other hand, benefits from the Google name,
of course. I doubt it would have had a quarter of its success just based
on Rob Pike's status and the merits of the language itself.

Also, community-building is something that absolutely needs to be done
to convince users to join in with fresh minds, and start building things
in the language. Only then will a community really flourish, no matter
how good or bad the language is.

  4). Spam the tech arena - have tons of blogs floating around talking
about the "cool" features of the language while downplaying the
complexity hiding around the corner, have a very helpful IRC channel
where people answer even the silliest questions with a smile, and have
active forums and users on Reddit, HN, and the like.


We do try on our Freenode channel, but answering with a smile can be 
quite hard. Especially when simple answers are ignored (I am definitely 
guilty of this).


It really doesn't help that we only have one person with OP rights who 
acts upon them. Its annoying since we get spammed every 6-8 months with 
nothing we can do assuming no Freenode admins are on (this is very common!).




Re: D future ...

2017-02-19 Thread timmyjose via Digitalmars-d

On Tuesday, 20 December 2016 at 15:42:16 UTC, bachmeier wrote:

On Tuesday, 20 December 2016 at 15:17:56 UTC, Benjiro wrote:
I do not recall seeing on the C++ and other forums this 
constant attitude from fix it yourselves or put it in the 
libraries or ... Its mostly on the smaller languages where 
they lack people. And at the same time, that is a very scary 
though for companies who want to use a language.


I think it's important to be realistic. One of D's limitations 
is that it does not have the money of Microsoft or Intel behind 
it, and it does not have hundreds of billion-dollar 
corporations depending on it for critical business operations. 
Volunteer organizations will be run differently from outfits 
that have large budgets to pay people to do the ugly work. This 
is not an excuse, it is simply the current state of affairs.


I'm completely new to the D scene, but I do want to make a 
comment here. One of the reasons why a language like Rust is 
seeing a surge in popularity is because the core team in Mozilla 
are evangelising it like you wouldn't believe it. Rust is a 
fairly old language, and yet the way they present it would fool 
anybody new to the language. Some things I noticed about their 
approach (having been part of the community for a little while) -


  1). Have a nifty, minimalistic website (D has a pretty good 
website as well, but I feel it is a bit overwhelming for newbies).


  2). Present the core strengths of the language on the main page 
itself in a brief sentence (even though they are more half-truths 
than anything else).


  3). They hired someone like Steve Klabnik to give talk after 
talk, and no matter what you may think of him, he is very good at 
"connecting" with the younger folks, and like it or not, the next 
generation is the target audience that will decide if a language 
is succesful or not.
In my opinion (also based on posts that some D users have 
made on the Rust user group), D is actually a much more coherent 
and powerful language than Rust, but most people (including 
myself) wouldn't have known about it on face value.


Self-promotion is something that needs to be done, and the Rust 
group is very good at it. Go, on the other hand, benefits from 
the Google name, of course. I doubt it would have had a quarter 
of its success just based on Rob Pike's status and the merits of 
the language itself.


Also, community-building is something that absolutely needs to be 
done to convince users to join in with fresh minds, and start 
building things in the language. Only then will a community 
really flourish, no matter how good or bad the language is.


  4). Spam the tech arena - have tons of blogs floating around 
talking about the "cool" features of the language while 
downplaying the complexity hiding around the corner, have a very 
helpful IRC channel where people answer even the silliest 
questions with a smile, and have active forums and users on 
Reddit, HN, and the like.


   5). Have regular online meetups and offline and online 
conferences as well.





Re: D future ...

2017-02-19 Thread timmyjose via Digitalmars-d

On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:
As an outsider to the D community but someone who has really 
wanted to love D the last few years I hope to shed some light 
from "outside the bubble" on why I haven't used D and why I use 
what I use and what I'm looking for. I hope this can be well 
received.


I write a lot of C and Go. But they aren't what I truly want in 
"systems" programming languages. I write high performance 
infrastructure code like databases or server software that 
handles millions of requests per second. One of my projects is 
an OSS HTTP server written in C that can serve 10 million 
requests/second.


Let's clarify a couple things about C and Go. C's 
advantages/disadvantages are:
1. Manual memory management. This could also be seen as a 
disadvantage but having the power to tailor memory access is an 
advantage for memory usage, allocation and access 
optimizafions. Let's face it, high perfowmcne code is all about 
memory access.
2. No GC pauses impacting request response times. Java, Go, 
.NET etc all have this problem.

3. Harder to write and write well, safely and securely.
4. Few concepts to learn.
5. Composability of libraries is poor. No package system, often 
not cross platform.
6. A lot of low level fundamental libraries are written in C 
like async I/O libraries or storage engine libraries.

7. Static compilation.

Go's advantages/disadvantages:
1. Static compilation.
2. No manual memory management.
3. Suffers from GC pauses.
4. Great composability of libraries. For example, you can 
easily "go get" a Redis protocol library, an ACID memory mapped 
persisted b+tree library and build a little database quite 
quickly.

5. Few concepts to learn.
6. Performance overhead when calling C libraries like storage 
engines.
7: The statement that Go is mostly used in scripting-like 
contexts isn't correct. It's very popular in the infrastructure 
space like databases and distributed systems implementations.
8. Lack of generics causes a lot of boilerplate code in 
comparison to other modern languages.


As an engineer who works on distributed systems in the scale of 
thousands of nodes I have to point out that GC'd languages need 
to be thought more as in the same category because of how they 
operate in production. You have to spend significant effort 
keeping these processses happy so that the GC's don't pause too 
much hurting response times. I argue all the time that GC'd 
languages are not systems languages. There's not enough control 
and you can't eliminate GC pauses completely and these GC's 
don't scale to modern physical hardware well.


But Go is popular in this category of space despite the 
GC/generics because of how composable infrastructure code is in 
the Go community. "go get" a Raft library, gossip library, 
storage library and you're off and running much faster than in 
other languages. However the overhead of calling C libraries 
and the GC impact performance. Go knows this weakness of the GC 
and has been working hard to eliminate GC pauses as much as 
possible. A great effort into sub-millisecond pauses with large 
heaps was recently achieved: 
https://github.com/golang/proposal/blob/master/design/17503-eliminate-rescan.md


What I really want is what C++ wanted to deliver but it 
doesn't. I want something better than writing C but with the 
same performance as C and the ability to interface with C 
without the performance loss and with easily composable 
libraries.


D in my opinion in some ways is close to these goals. It's 
simpler to understand and write than C++. It has the problem of 
being a GC'd language however and it's unclear to me if the GC 
in D is evolving like the Go GC is. I'm not happy about having 
to use a GC but if I have to I hope to see the one I'm 
investing on evolve because it most certainly impacts 
production systems very much.


The things I really want from D to really sway me would be the 
following (some already exist):

1. Evolve the GC like Go has.
2. No overhead calling C libraries.
3. Easily composable libraries.
4. Good IDE support.

#2 is really why Go has gained a lot of popularity but #1 is 
extremely important on how production systems behave. #2 is 
likely something Go cannot solve and why there's an opportunity 
for another language to jump in with better performance.


The programming community hasn't found a good modern systems 
language yet that aligns with these tradeoffs. I actually think 
D and Swift (no GC, ARC, no calling C overhead) are closest to 
having the potential for the correct tradeoffs to be systems 
languages.


Rust probably is aligned more than anyone with these goals at 
the moment but every time I try to learn rust my head hurts and 
it's not enjoyable.


I hope this sheds some light on why I really like D but as an 
outsider what I'm looking and need in the space I build 
software and why I think D could fill a gap others aren't yet.


Thank you for reading my thoughts.


As 

Re: D future ...

2017-02-19 Thread timmyjose via Digitalmars-d

On Tuesday, 20 December 2016 at 02:24:28 UTC, Ali Çehreli wrote:

On 12/19/2016 06:19 PM, Adam D. Ruppe wrote:

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

Vim: Lets not go there.


Why not? If you already know vim at least, it is very easy to 
use with D

- things just work quite well out of the box.


Try remote editing D and see how much fun it is.


works in vim out of the box...


No need to mention Emacs. If vi[m] can do something so can 
Emacs. :p


Ali


I, for one, concur.


Re: D future ...

2017-02-17 Thread Soulsbane via Digitalmars-d
On Wednesday, 15 February 2017 at 21:07:06 UTC, Arun 
Chandrasekaran wrote:

On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote:
There's little point in having more features if what's already 
there is

half broken and not well-defined.


+1


Indeed.


Re: D future ...

2017-02-17 Thread Ola Fosheim Grøstad via Digitalmars-d
On Friday, 17 February 2017 at 01:29:48 UTC, Guillaume Piolat 
wrote:
For macOS, the prospect of not having to use XCode is rather a 
positive :)


Really? I find XCode 8 to do most of what I need. Refactoring is 
somewhat limited, but otherwise it works fine.


Re: D future ...

2017-02-17 Thread ketmar via Digitalmars-d

Walter Bright wrote:

Something is going on with your newsreader client. It's replies break 
the thread.


ooops. created the content, but forgot to actually send it. ;-)


Re: D future ...

2017-02-16 Thread Guillaume Piolat via Digitalmars-d
On Wednesday, 15 February 2017 at 16:07:18 UTC, Ola Fosheim 
Grøstad wrote:
This trend will continue. Programming for iOS without XCode is 
unthinkable at this point, and similar situations exists for 
other platforms.




For macOS, the prospect of not having to use XCode is rather a 
positive :)




Re: D future ...

2017-02-16 Thread Jonathan M Davis via Digitalmars-d

On Friday, 17 February 2017 at 00:00:09 UTC, Walter Bright wrote:
Something is going on with your newsreader client. It's replies 
break the thread.


I would point out that if there are issues with threading, and 
you don't quote whoever you're responding to, then it may be 
connected to the wrong post - that and some folks don't even use 
threading in their viewer, so without a quote or a name, it's 
hard to know for sure who you're talking to.


- Jonathan M Davis


Re: D future ...

2017-02-16 Thread Walter Bright via Digitalmars-d

Something is going on with your newsreader client. It's replies break the 
thread.


Re: D future ...

2017-02-16 Thread Astor via Digitalmars-d

On Saturday, 11 February 2017 at 15:52:40 UTC, SC wrote:
People here under estimate the necessity to have EXCELLENT 
editor support




It's not just editor but complete setup, you shouldn't be 
required to download the compiler, then dub, then an editor.
An easy to download and install package including the compiler, 
dub and DLangIDE, plus perhaps a couple demo projects, would be 
great for curious newcomers who just want to take a look at the 
language. IMHO, of course.




Re: D future ...

2017-02-15 Thread ketmar via Digitalmars-d

Jack Stouffer wrote:

Can you please make a bug with a level of regression for your specific 
problem?


yeah.

https://issues.dlang.org/show_bug.cgi?id=17188


Re: D future ...

2017-02-15 Thread Jack Stouffer via Digitalmars-d

On Thursday, 16 February 2017 at 03:46:29 UTC, ketmar wrote:
you want the example? `scope` was added to `_compare_fp_t`from 
"core.stdc.stdlib". thank you for breaking ALL my code thatis 
using `qsort()`. i guess nobody from core dev team really 
used`qsort()` from libc, so it is ok to break the code with it.


Yes, I'm really disappointed with the way that DIP1000 is turning 
out. It was explicitly stated that nothing would be broken right 
away and that everything would be given a deprecation cycle.


Can you please make a bug with a level of regression for your 
specific problem?


Re: D future ...

2017-02-15 Thread ketmar via Digitalmars-d

Jack Stouffer wrote:

And I sincerely hope they work to fix them before adding in a 
bunch of new DIPs which will further complicate matters, 
especially with regard to function signitures.


so far i see that they just like to say: "we won't break user's code", 
and then silently breaking it, even without deprecation stage.


thank you, guys; guessing when "we won't break the code" really means 
something is a fun game.


you want the example? `scope` was added to `_compare_fp_t` 
from "core.stdc.stdlib". thank you for breaking ALL my code that 
is using `qsort()`. i guess nobody from core dev team really used 
`qsort()` from libc, so it is ok to break the code with it.


yeah, this was done in git, not in release. but still.

btw, for a short time compiler was unable to build itself at all,
with all that "scope spam". i.e. nobody really cares about travis, 
or travis cannot properly check commits and is useless (or how else 
patch that did broke travis builds lands in "master"?)


what i really want to say is that spamming code with shiny new stuff is 
done... too fast, and tends to disregard "we won't break users' code" 
mantra. sure, adding new features is fun, i know it, and i like to do 
it too. but please, let's do it consistently! either drop "we won't 
break" and start *really* adding features, or stop adding random 
half-finished things to compiler/druntime/phobos. at least in "master".


p.s.: please, no "don't use git HEAD" blah-blah. it is not about short 
breakages (which is normal with "bleeding edge"). it is all about lack 
of consistency and proper... practices. maybe even proper project 
vision.


p.p.s.: "mostly volunteers", "free", etc. i know. thank you all for 
your hard work. i appreciate it, and that's exactly why i don't want it 
to be spoiled by seemingly small and insignificant things.


Re: D future ...

2017-02-15 Thread Ola Fosheim Grøstad via Digitalmars-d

On Wednesday, 15 February 2017 at 21:46:32 UTC, bpr wrote:
You're missing what I consider to be 'the Big Picture', namely 
that Swift will become popular on non-Apple platforms, and it 
needs to be fairly capable to compete with Go, Java, and C++, 
and others. IBM is already backing server side Swift to some 
degree.


I don't know if that will happen anytime soon. I think the 
functionality that the original creator has suggested for 
system-level programming has to be in place first. Currently the 
language/runtime  is geared towards best practices inherited from 
Foundation/Objective-C/Cocoa/macOS... Which makes sense, but 
makes Swift a second rate citizen in other environments.


Re: D future ...

2017-02-15 Thread Jack Stouffer via Digitalmars-d

On Wednesday, 15 February 2017 at 21:16:51 UTC, Meta wrote:

Isn't that a little uncharitable?


I just spent about 20 minutes list out all of my problems with 
the language, and how somethings are pretty broken. But I deleted 
it and I'm not going to post it.


It was just another rant. One that doesn't change anything. All 
I'll say is the current language maintainers know what's broken. 
And I sincerely hope they work to fix them before adding in a 
bunch of new DIPs which will further complicate matters, 
especially with regard to function signitures.


Re: D future ...

2017-02-15 Thread bpr via Digitalmars-d
On Wednesday, 15 February 2017 at 17:53:43 UTC, Ola Fosheim 
Grøstad wrote:
Typo: I mean't that one cannot assume that Apple hardware has 
more than 2 cores (so one has to write applications that 
perform well with only 2 cores).


You're missing what I consider to be 'the Big Picture', namely 
that Swift will become popular on non-Apple platforms, and it 
needs to be fairly capable to compete with Go, Java, and C++, and 
others. IBM is already backing server side Swift to some degree.




Re: D future ...

2017-02-15 Thread Meta via Digitalmars-d
On Wednesday, 15 February 2017 at 20:53:58 UTC, Jack Stouffer 
wrote:

On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote:
There's little point in having more features if what's already 
there is half broken and not well-defined.


This is what Manu and deadalnix have been saying for the past 
three years. Its fallen on deaf ears.


Isn't that a little uncharitable?


Re: D future ...

2017-02-15 Thread Arun Chandrasekaran via Digitalmars-d

On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote:
There's little point in having more features if what's already 
there is

half broken and not well-defined.


+1


Re: D future ...

2017-02-15 Thread Jack Stouffer via Digitalmars-d

On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote:
There's little point in having more features if what's already 
there is half broken and not well-defined.


This is what Manu and deadalnix have been saying for the past 
three years. Its fallen on deaf ears.


Re: D future ...

2017-02-15 Thread Cym13 via Digitalmars-d
On Wednesday, 15 February 2017 at 16:07:18 UTC, Ola Fosheim 
Grøstad wrote:
I think Go has benefitted some from having limited and stable 
language semantics and continuously improving on the 
implementation. IMO that should make it attractive in the 
server space, i.e. you get low tooling-related maintenance cost 
and still get real benefits from recompiling with new versions 
of the compiler.


That is a very good point, I had never considered the 
consequences of
semantics stabilization on tooling. It strenghtens (along with 
DIP1005)
my opinion that D is fine as it is and that no new feature should 
be
added before at least two years, while fixing the implementation 
should
get the focus. It doesn't mean we can't add anything new, better 
C++
integration or memory management semantics would be fine, as long 
as it

is an already begun project.

There's little point in having more features if what's already 
there is

half broken and not well-defined.


Re: D future ...

2017-02-15 Thread Ola Fosheim Grøstad via Digitalmars-d
On Wednesday, 15 February 2017 at 17:08:37 UTC, Ola Fosheim 
Grøstad wrote:
modelling paradigm? One cannot really assume that Apple 
hardware has more than 2 CPUs.


Typo: I mean't that one cannot assume that Apple hardware has 
more than 2 cores (so one has to write applications that perform 
well with only 2 cores).





Re: D future ...

2017-02-15 Thread Ola Fosheim Grøstad via Digitalmars-d

On Wednesday, 15 February 2017 at 16:41:31 UTC, bpr wrote:
Swift took over quickly because Apple has mandated it. While 
I'm happy about that, there's no denying that Swift wouldn't be 
where it is without the weight of Apple behind it. I'd go as 
far as to say that Swift's success is assured (unless Apple


It may have been assured, but the adoption _rate_ comes from 
having a good match on semantics and existing practices.


Replace Swift with Haskell and the adoption would have been much 
slower.


As a PL, Swift looks nice, but they'll have to come up with a 
more complete story around concurrency.


Do you mean parallell execution (CPU) or concurrency as a 
modelling paradigm? One cannot really assume that Apple hardware 
has more than 2 CPUs. So as a starting point you can presume that 
one core taken by the main UI event loop and the other one taken 
by real time code. Whatever is left is for Apple's "Operation 
Queues" (dispatch queues, basically worker threads working in a 
FIFO manner IIRC).


https://developer.apple.com/library/content/documentation/General/Conceptual/ConcurrencyProgrammingGuide/



Re: D future ...

2017-02-15 Thread Ola Fosheim Grøstad via Digitalmars-d
On Wednesday, 15 February 2017 at 16:28:00 UTC, Jacob Carlborg 
wrote:

On 2017-02-15 17:07, Ola Fosheim Grøstad wrote:


This trend will continue. Programming for iOS without XCode is
unthinkable at this point, and similar situations exists for 
other

platforms.


TextMate on macOS is a native macOS application (Cocoa, C++) 
but does not use Xcode to build, it's using ninja. I guess 
that's expected, to use TextMate to build TextMate.


It certainly is possible to build for macOS/iOS without using 
XCode, but still unthinkable for most. Even JetBrain's commercial 
offering fall short because they lag behind when Apple release a 
new OS version. If the language/framework vendor provides an IDE 
it becomes difficult to break into the market, if for no other 
reason than being sure that timeliness requirements are met.





Re: D future ...

2017-02-15 Thread bpr via Digitalmars-d
On Wednesday, 15 February 2017 at 14:44:55 UTC, Ola Fosheim 
Grøstad wrote:
Another example is Swift. Swift managed to take over 
Objective-C rather quickly IMO, but Swift has also absorbed the 
non-C semantics of Objective-C, thus it did not require 
changing existing practice significantly.


Swift took over quickly because Apple has mandated it. While I'm 
happy about that, there's no denying that Swift wouldn't be where 
it is without the weight of Apple behind it. I'd go as far as to 
say that Swift's success is assured (unless Apple drops it, which 
looks unlikely) and that because Swift has money behind it, more 
money will follow, and so will a thriving ecosystem, on and off 
OS X.


As a PL, Swift looks nice, but they'll have to come up with a 
more complete story around concurrency.






Re: D future ...

2017-02-15 Thread Jacob Carlborg via Digitalmars-d

On 2017-02-15 17:07, Ola Fosheim Grøstad wrote:


This trend will continue. Programming for iOS without XCode is
unthinkable at this point, and similar situations exists for other
platforms.


TextMate on macOS is a native macOS application (Cocoa, C++) but does 
not use Xcode to build, it's using ninja. I guess that's expected, to 
use TextMate to build TextMate.


--
/Jacob Carlborg


Re: D future ...

2017-02-15 Thread Ola Fosheim Grøstad via Digitalmars-d
On Wednesday, 15 February 2017 at 10:38:04 UTC, Russel Winder 
wrote:
It is also "re-tribalising" around the Rust, Go, Swift, C++17 
for native code; Java 8/9, Kotlin, Scala, Groovy, Clojure on 
the JVM; ECMAScript, TypeScript, Elm in the browser, and Python 
in data science and such like. OK not orthogonal dimensions.


Yeah, it isn't orthogonal dimensions. Not quite sure what you 
mean by "re-tribalising". Do you mean that developers have broken 
up from older languages like C++98 and Objective-C and regrouped 
over Rust, Go, Swift and C++17? I guess that is a reasonable 
interpretation.


I am still not sure exactly what Rust's demographic is, but I 
guess it may be catering for those that want a high-level C with 
a preference for functional programming over templated 
programming?



An interesting perspective is who is putting money into IDEs 
and JetBrains are a good measuring device for this. C/C++ with 
CMake got CLion which is now getting a lot of Swift and Rust 
love. Go got a whole new IDE in Goglang. C#, Ruby, JavaScript 
get a lot of push, as do the gamut of JVM languages in IDEA – 
where the Rust plugin gets a lot of push. Python has PyCharm.


I haven't seen Gogland before, too bad I turned down the full 
suite IDE offering from JetBrains recently... VSCode with plugins 
is ok for Go and TypeScript though.


But it is a clear trend that newer languages are more tuned for 
IDE support, i.e. the language design is made with 
text-completion support in mind. This is one primary advantage 
with TypeScript over JavaScript for instance and alone worth the 
switch. Writing Python code with PyCharm is also quite different 
from using emacs, it is almost a "different language".


This trend will continue. Programming for iOS without XCode is 
unthinkable at this point, and similar situations exists for 
other platforms.


Emacs, VIM, SublimeText, Atom, etc. get some love but few 
people really care about them compared to the Eclipse and 
JetBrains IDEs.


The cognitive load is just too high these days to use a regular 
editor if you want to be productive. The APIs are too big, there 
are too many of them, and they change too much and frequently to 
deal with "non-standard" editor issues. Just the automated 
hinting that something is deprecated and suggestions for 
replacements are invaluable time savers when upgrading codebases.


So if we measure traction by IDE and editor effort D is losing, 
along with Fantom, Crystal, Pony, Nim, and all the other 
languages that focus on the language to the expense of the way 
people use the language.


I think IDE support should be part of the core project these 
days. My impression is that Dart had a lot more enthusiastic 
following when they provided a Dart-editor (eclipse fork). 
JetBrains supports Dart, but it isn't really the same thing when 
it isn't free and directly supported by the language provider.


I noticed that the Whiley website says that they are maintaining 
an eclipse plugin as part of the project.


Kingsley started work on the IDEA plugin and Bruno on the 
Eclipse plugin. Some people are working on the IDEA plugin (I 
am supposed to be as well, but I am failing). To get D out 
there with traction, these, not the compiler, should be the 
core focus of attention – the place where lots of resource is 
going in.


One cannot expect volunteers to keep at it for years. And being 
left in the dark at some point in the future is not a very 
enticing prospect when adopting a language. There are currently 
more open source projects on github than (capable) developers... 
so one cannot expect others to take over either. It was different 
back in the day when emacs was the only real alternative.


Community driven development seems to no longer work reliably for 
projects that have high maintenance costs (with notable 
exceptions).


I guess this having something to do with the basic needs being 
met by the Linux ecosystem (the basic Unix toolset being 
available). Maslow's hierarchy of needs?


Ceylon, Kotlin, Rust, Go have some core resource that attracts 
more resource, and there is a snowball effect.


I think Go has benefitted some from having limited and stable 
language semantics and continuously improving on the 
implementation. IMO that should make it attractive in the server 
space, i.e. you get low tooling-related maintenance cost and 
still get real benefits from recompiling with new versions of the 
compiler.


I don't much about Rust and snowball effects? I thought Rust had 
stagnated, but maybe I am wrong?


No matter how good D and the compilers are, without high 
quality IDE support, it will be a peripheral language for the 
core adherents.


But we have been round this time and again, with 
extraordinarily little progress.


The most important factor is the overall composition of the eco 
system and a good IDE makes it all come together. Kinda like a 
carpenter's workbench. You can make small scale stuff without, 
but you wouldn't do 

Re: D future ...

2017-02-15 Thread Ola Fosheim Grøstad via Digitalmars-d

On Wednesday, 15 February 2017 at 11:14:11 UTC, John Colvin wrote:
On Tuesday, 14 February 2017 at 10:22:26 UTC, Ola Fosheim 
Grøstad wrote:
But, the way I see it TypeScript + "native libraries" has the 
potential for covering a lot of ground. The eco system is 
exploding.


Having done a fair amount of professional development in 
typescript over the last 6 months, I have to say I'm not as 
excited about it as I used to be. Don't get me wrong, I still 
think it's the best language in its space, but the javascript 
underneath it shows through in a lot of bad places and the lack 
of real meta-programming makes it hard to get your types 
exactly how you want them. Overall I've found it a frustrating 
when I compare it to working in D, despite it having a bunch of 
cool features I'd love to use in D.


The structural flow type-system of TypeScript takes time to get 
used to and it only provides limited static type checks, so it 
has rather limited generating capabilities (typing is primarily 
for correctness checks and IDE-text-completion support). The 
template-expansion area is a field where D is better off, 
certainly.


What MS did right though was to create something that is not too 
unfamiliar for people that know languages like JavaScript, C#, 
Java or Swift, yet they absorb trendy frameworks like React and 
Angular as well as all existing JavaScript libraries. Not having 
a fixed build system is a weakness, and a bit frustrating, but I 
guess this is deliberately done to absorb as many developers as 
possible with their existing preferences. Objectively a competing 
language like Dart is better, but Dart is different enough to not 
having the ability to absorb developers.


My viewpoint is that this ability to absorb existing practices 
(like build systems and code bases) is probably where TypeScript 
is gaining traction from.


I think D might be a bit like Dart in this regard. It is closely 
related to, but yet too different from C/C++ to absorb the 
existing practices.


Another example is Swift. Swift managed to take over Objective-C 
rather quickly IMO, but Swift has also absorbed the non-C 
semantics of Objective-C, thus it did not require changing 
existing practice significantly.




Re: D future ...

2017-02-15 Thread John Colvin via Digitalmars-d
On Tuesday, 14 February 2017 at 10:22:26 UTC, Ola Fosheim Grøstad 
wrote:
But, the way I see it TypeScript + "native libraries" has the 
potential for covering a lot of ground. The eco system is 
exploding.


Having done a fair amount of professional development in 
typescript over the last 6 months, I have to say I'm not as 
excited about it as I used to be. Don't get me wrong, I still 
think it's the best language in its space, but the javascript 
underneath it shows through in a lot of bad places and the lack 
of real meta-programming makes it hard to get your types exactly 
how you want them. Overall I've found it a frustrating when I 
compare it to working in D, despite it having a bunch of cool 
features I'd love to use in D.


Re: D future ...

2017-02-15 Thread Russel Winder via Digitalmars-d
On Tue, 2017-02-14 at 10:22 +, Ola Fosheim Grøstad via Digitalmars-
d wrote:
> On Saturday, 11 February 2017 at 18:51:31 UTC, Russel Winder 
> wrote:
> > Interesting, but the current competition is between Go, Rust, 
> > C++, and D.
> 
> I don't know, which fields are you thinking about? I believe the 
> market is changing.

It is also "re-tribalising" around the Rust, Go, Swift, C++17 for
native code; Java 8/9, Kotlin, Scala, Groovy, Clojure on the JVM;
ECMAScript, TypeScript, Elm in the browser, and Python in data science
and such like. OK not orthogonal dimensions.

> On OSX/iOS: Swift + Metal is the alternative, throw in some bits 
> of Objective-C/C++ where you have long running tight inner loops.
> 
> On Windows: moving away from C# sounds very risky.
> 
> On Linux: this is more of an open space.
> 
> Embedded: C/C++, maybe Rust for those with courage? I suspect 
> moving out of vendor supported tooling is risky (e.g. 
> system-on-a-chip solutions)
> 
> Numerics: Python + low level libraries, Matlab etc.
> 
> But, the way I see it TypeScript + "native libraries" has the 
> potential for covering a lot of ground. The eco system is 
> exploding.

An interesting perspective is who is putting money into IDEs and
JetBrains are a good measuring device for this. C/C++ with CMake got
CLion which is now getting a lot of Swift and Rust love. Go got a whole
new IDE in Goglang. C#, Ruby, JavaScript get a lot of push, as do the
gamut of JVM languages in IDEA – where the Rust plugin gets a lot of
push. Python has PyCharm.

D has some small effort in IDEA, but it needs the resourcing to get to
the level the Rust, Clojure, Scala, Groovy, Swift, Go, C++, Kotlin
languages get.

It is noticeably that many people are leaving the Eclipse environment
for the JetBrains one, Ceylon is a prime example. But Eclipse remains a
player here (unlike NetBeans?)

Emacs, VIM, SublimeText, Atom, etc. get some love but few people really
care about them compared to the Eclipse and JetBrains IDEs.

So if we measure traction by IDE and editor effort D is losing, along
with Fantom, Crystal, Pony, Nim, and all the other languages that focus
on the language to the expense of the way people use the language.
Kingsley started work on the IDEA plugin and Bruno on the Eclipse
plugin. Some people are working on the IDEA plugin (I am supposed to be
as well, but I am failing). To get D out there with traction, these,
not the compiler, should be the core focus of attention – the place
where lots of resource is going in. Ceylon, Kotlin, Rust, Go have some
core resource that attracts more resource, and there is a snowball
effect.

No matter how good D and the compilers are, without high quality IDE
support, it will be a peripheral language for the core adherents.

But we have been round this time and again, with extraordinarily little
progress.


-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part


Re: D future ...

2017-02-14 Thread Ola Fosheim Grøstad via Digitalmars-d
On Saturday, 11 February 2017 at 18:51:31 UTC, Russel Winder 
wrote:
Interesting, but the current competition is between Go, Rust, 
C++, and D.


I don't know, which fields are you thinking about? I believe the 
market is changing.


On OSX/iOS: Swift + Metal is the alternative, throw in some bits 
of Objective-C/C++ where you have long running tight inner loops.


On Windows: moving away from C# sounds very risky.

On Linux: this is more of an open space.

Embedded: C/C++, maybe Rust for those with courage? I suspect 
moving out of vendor supported tooling is risky (e.g. 
system-on-a-chip solutions)


Numerics: Python + low level libraries, Matlab etc.

But, the way I see it TypeScript + "native libraries" has the 
potential for covering a lot of ground. The eco system is 
exploding.




Re: D future ...

2017-02-11 Thread Russel Winder via Digitalmars-d
On Sat, 2017-02-11 at 15:52 +, SC via Digitalmars-d wrote:
> People here under estimate the necessity to have EXCELLENT editor 
> support
> 
> Without editor, nobody will want to write code in D, there are 
> ton of languages now, all with great editor support (Rust, Go, 
> Kotlin, Scalla, C#, java, C/C++), people have choice

Cannot disagree with this.

> There are 10 IDE/plugin project for d, this is too much, half are 
> already dead, we go nowhere, please focus on one that is 
> crossplatform (IntelliJ)

It isn't the number of different projects that is the problem. The
problem is the lack of effort going in to the Eclipse and the IntelliJ
IDEA plugins. In terms of traction of D, having an excellent Eclipse
perspective, and an excellent IntelliJ IDEA and CLion plugin is
essential.

Personally, I favour the IntelliJ IDEA and CLion IDEs. Work is
progressing on the IntelliJ IDEA but it simply needs more people
contributing actively – to my shame I haven't been able to put time
into this myself, so I am contributing to the problem. This plugin uses
Dub for build management, the CLion version needs to use CMake, so we
need the CMake-D stuff to be up to scratch as well.

I have just tried out the Rust plugin to IntelliJ IDEA, it is
excellent. JetBrains themselves have taken the Go plugin and turned it
into Gogland a complete IDE. It is not half bad. D is very definitely
losing in this IDE race, and thus in the potential for traction in the
C, C++, Go, Rust, D milieu.

> And jetbrains are working on Kotlin native, another big 
> competitor..

Interesting, but the current competition is between Go, Rust, C++, and
D.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part


Re: D future ...

2017-02-11 Thread SC via Digitalmars-d
People here under estimate the necessity to have EXCELLENT editor 
support


Without editor, nobody will want to write code in D, there are 
ton of languages now, all with great editor support (Rust, Go, 
Kotlin, Scalla, C#, java, C/C++), people have choice


There are 10 IDE/plugin project for d, this is too much, half are 
already dead, we go nowhere, please focus on one that is 
crossplatform (IntelliJ)


And jetbrains are working on Kotlin native, another big 
competitor..





Re: D future ...

2017-01-02 Thread keito940 via Digitalmars-d

On Friday, 30 December 2016 at 09:53:25 UTC, keito940 wrote:

...If you improve the standard library, everything OK? If...
Next Version Request.
Add To The F Sharp Like Pipeline Operator(D Language Pipeline 
Syntax is BAD.) & SML(C Language Compatible) Like Function 
Syntax  Like Maybe Monad Execution speed Up.

Plz,Now!!!


I also have to change the specification of the language.
First of all, we have to introduce this system!


Re: D future ...

2017-01-02 Thread keito940 via Digitalmars-d

On Saturday, 31 December 2016 at 08:14:28 UTC, jkpl wrote:
Yes but it's gtk, there's year of work behind the library. For 
a homemade GUI library CSS or not CSS is really just 
bikeshedding around the format. The real stuff is to write the 
rendering engine. It becomes particularly tricky when the 
engine also supports transformations. If something is not well 
done you see it directly after rotation and translation.


rendering engine...hmmm...


Re: D future ...

2016-12-31 Thread jkpl via Digitalmars-d

On Friday, 30 December 2016 at 13:56:30 UTC, Getald wrote:

On Thursday, 29 December 2016 at 21:41:45 UTC, aberba wrote:

Styling is similar to CSS but different. Wished someone would 
just go for a full blown CSS parser. CSS has proven its more 
capable and loved for client side styling/decoration.


Isn't this what GTK is essentially doing already where widget 
rendering is primarily defined by CSS.


Yes but it's gtk, there's year of work behind the library. For a 
homemade GUI library CSS or not CSS is really just bikeshedding 
around the format. The real stuff is to write the rendering 
engine. It becomes particularly tricky when the engine also 
supports transformations. If something is not well done you see 
it directly after rotation and translation.


Re: D Future...

2016-12-30 Thread Bauss via Digitalmars-d

On Friday, 30 December 2016 at 09:49:27 UTC, keito940 wrote:

If you improve the standard library, everything OK? If...
Next Version Request.
Add To The F Sharp Like Pipeline Operator(D Language Pipeline 
Syntax is BAD.) & SML(C Language Compatible) Like Function 
Syntax  Like Maybe Monad Execution speed Up.

Plz,Now!!!


Could you please elaborate and explain exactly what you mean in a 
detailed formal way.


Also this is not the way it works.


Re: D future ...

2016-12-30 Thread Bauss via Digitalmars-d

On Friday, 30 December 2016 at 13:56:30 UTC, Getald wrote:

On Thursday, 29 December 2016 at 21:41:45 UTC, aberba wrote:

Styling is similar to CSS but different. Wished someone would 
just go for a full blown CSS parser. CSS has proven its more 
capable and loved for client side styling/decoration.


Isn't this what GTK is essentially doing already where widget 
rendering is primarily defined by CSS.


Yep it is


Re: D future ...

2016-12-30 Thread Getald via Digitalmars-d

On Thursday, 29 December 2016 at 21:41:45 UTC, aberba wrote:

Styling is similar to CSS but different. Wished someone would 
just go for a full blown CSS parser. CSS has proven its more 
capable and loved for client side styling/decoration.


Isn't this what GTK is essentially doing already where widget 
rendering is primarily defined by CSS.




Re: D future ...

2016-12-30 Thread Bauss via Digitalmars-d

On Friday, 30 December 2016 at 13:26:15 UTC, Bauss wrote:

On Friday, 30 December 2016 at 11:32:50 UTC, aberba wrote:

[...]


Yeah it kinda follows classes right now already.

It follows a little different concept, where it's based on 
selectors and not classes.


So you give your component selectors that it acts on. There are 
of course default selectors on them such as their component 
type, name, states etc.


See:
https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L297

And:
https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L376


And of course: 
https://github.com/PoisonEngine/poison-ui/blob/master/README.md#styling


Re: D future ...

2016-12-30 Thread Bauss via Digitalmars-d

On Friday, 30 December 2016 at 11:32:50 UTC, aberba wrote:

On Friday, 30 December 2016 at 06:22:40 UTC, bauss wrote:

[...]


Yeah. I meant a subset. But widgets will not follow the DOM 
query syntax, it should use class attributes.


.button {
  border-color: red;
}

.container {
  ...
}

auto btn = new Button();
btn.addClass("button");
btn.addStyleFromFile("style.css");

...
container = new ...
container.addStyleFromSource(".container {…}");


Yeah it kinda follows classes right now already.

It follows a little different concept, where it's based on 
selectors and not classes.


So you give your component selectors that it acts on. There are 
of course default selectors on them such as their component type, 
name, states etc.


See:
https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L297

And:
https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L376


Re: D future ...

2016-12-30 Thread aberba via Digitalmars-d

On Friday, 30 December 2016 at 06:22:40 UTC, bauss wrote:

[...]


Yeah. I meant a subset. But widgets will not follow the DOM query 
syntax, it should use class attributes.


.button {
  border-color: red;
}

.container {
  ...
}

auto btn = new Button();
btn.addClass("button");
btn.addStyleFromFile("style.css");

...
container = new ...
container.addStyleFromSource(".container {…}");



Re: D future ...

2016-12-30 Thread keito940 via Digitalmars-d

On Tuesday, 20 December 2016 at 01:45:27 UTC, Tommi wrote:

Improve the standard library!


...If you improve the standard library, everything OK? If...
Next Version Request.
Add To The F Sharp Like Pipeline Operator(D Language Pipeline 
Syntax is BAD.) & SML(C Language Compatible) Like Function Syntax 
 Like Maybe Monad Execution speed Up.

Plz,Now!!!


Re: D Future...

2016-12-30 Thread keito940 via Digitalmars-d

If you improve the standard library, everything OK? If...
Next Version Request.
Add To The F Sharp Like Pipeline Operator(D Language Pipeline 
Syntax is BAD.) & SML(C Language Compatible) Like Function Syntax 
 Like Maybe Monad Execution speed Up.

Plz,Now!!!


Re: D future ...

2016-12-29 Thread bauss via Digitalmars-d

On Thursday, 29 December 2016 at 22:53:51 UTC, Chris Wright wrote:

On Thu, 29 Dec 2016 21:41:45 +, aberba wrote:
Styling is similar to CSS but different. Wished someone would 
just go for a full blown CSS parser. CSS has proven its more 
capable and loved for client side styling/decoration.


CSS is huge. It also brings in some assumptions about the 
layout model.


Supporting a subset of CSS would be reasonable.


This, besides there are things in CSS that only makes sense for 
it and not necessary for this. Like the way it certain styles are 
depending on each other, the dependencies may act differently by 
CSS, than it would by my library, because I do not render things 
with the same mindset or goal as CSS. One thing that especially 
is hard is the selector scheme as it's not based on styling a 
marked up language nor any kind of language structure at all. So 
the same kind of hierarchy doesn't exist with selectors like a 
div with a div isn't a thing, it's just a container that has a 
child component that's a container, but since this targets native 
GUI development then I don't want styling to match such 
inheritance and each component should be decoupled from each 
other. I believe it's much smoother and easier to manage your 
design. The only things that won't be decoupled from components 
and their children and surroundings would be things like 
positions, margins, paddings etc. all which doesn't affect the 
design.


Re: D future ...

2016-12-29 Thread Chris Wright via Digitalmars-d
On Thu, 29 Dec 2016 21:41:45 +, aberba wrote:
> Styling is similar to CSS but different. Wished someone would just go
> for a full blown CSS parser. CSS has proven its more capable and loved
> for client side styling/decoration.

CSS is huge. It also brings in some assumptions about the layout model.

Supporting a subset of CSS would be reasonable.


Re: D future ...

2016-12-29 Thread bauss via Digitalmars-d

On Thursday, 29 December 2016 at 21:41:45 UTC, aberba wrote:

On Thursday, 29 December 2016 at 19:54:43 UTC, bauss wrote:

[...]


Styling is similar to CSS but different. Wished someone would 
just go for a full blown CSS parser. CSS has proven its more 
capable and loved for client side styling/decoration.


I would love to implement that and actually looked at 
implementing a sass like syntax, but decided it wasn't the 
importance right now, so maybe at a later point.


Re: D future ...

2016-12-29 Thread aberba via Digitalmars-d

On Thursday, 29 December 2016 at 19:54:43 UTC, bauss wrote:

On Wednesday, 28 December 2016 at 12:33:58 UTC, Satoshi wrote:

[...]


I know this is kinda late to the game

If you want to do GUI development and don't want to use any of 
the existing things because they're outdated or anything you 
could always help contribute to my project if you want. 
Although it's nowhere near stable and not close to anything 
being usable, I'd appreciate anyone willing to help. I'm 
currently put up with tons of other work that are way more 
important, so haven't been able to do anything on it myself. If 
you're going to help or for the matter if anyone is then please 
don't modify the graphics and picture modules, as I plan on 
rewriting them as they were kinda just winged together through 
the development and they definitely need a stronger core to 
them. Overall it works though.


It can be found here: http://poisonengine.github.io/


Styling is similar to CSS but different. Wished someone would 
just go for a full blown CSS parser. CSS has proven its more 
capable and loved for client side styling/decoration.


Re: D future ...

2016-12-29 Thread Arun Chandrasekaran via Digitalmars-d

On Thursday, 29 December 2016 at 19:54:43 UTC, bauss wrote:


It can be found here: http://poisonengine.github.io/


404, here is a working link -- 
https://github.com/PoisonEngine/poison-ui


Re: D future ...

2016-12-29 Thread bauss via Digitalmars-d

On Thursday, 29 December 2016 at 19:54:43 UTC, bauss wrote:

It can be found here: http://poisonengine.github.io/


I apologize I meant here: 
https://poisonengine.github.io/poison-ui/




Re: D future ...

2016-12-29 Thread bauss via Digitalmars-d

On Wednesday, 28 December 2016 at 12:33:58 UTC, Satoshi wrote:

On Wednesday, 28 December 2016 at 12:03:53 UTC, YAHB wrote:
Just think to your strategy and try to be wise. Even Qt 
sources are available. There's at least 10 ways to waste a 
freelance commercial project.
Qt is out of dated crap mostly useless for fast GUI 
development. Anyway, it's my project and I don't want to 
release source codes. No, it's not a freelance project, I got 
some money for dev and I already have clients waiting for 
stable release. There will be info soon.




I know this is kinda late to the game

If you want to do GUI development and don't want to use any of 
the existing things because they're outdated or anything you 
could always help contribute to my project if you want. Although 
it's nowhere near stable and not close to anything being usable, 
I'd appreciate anyone willing to help. I'm currently put up with 
tons of other work that are way more important, so haven't been 
able to do anything on it myself. If you're going to help or for 
the matter if anyone is then please don't modify the graphics and 
picture modules, as I plan on rewriting them as they were kinda 
just winged together through the development and they definitely 
need a stronger core to them. Overall it works though.


It can be found here: http://poisonengine.github.io/


Re: D future ...

2016-12-28 Thread Chris Wright via Digitalmars-d
On Wed, 28 Dec 2016 22:10:22 +, Satoshi wrote:
> It's not so simple. I actually must know which functions can be called
> by CTFE and which not. auto functions should have stripped body with
> replaced auto for a specific type, etc.

Currently, D header files don't support either of those features. You 
probably need a custom header generator, one that pays attention to UDAs 
(assuming you want to annotate functions according to whether they can be 
called at compile time; otherwise, there's a fair bit more work).

Unfortunately, DMD's json output doesn't even write UDAs, so you can't 
use that to write your own header generator.


Re: D future ...

2016-12-28 Thread Laeeth Isharc via Digitalmars-d
On Wednesday, 28 December 2016 at 06:48:09 UTC, Chris Wright 
wrote:

On Wed, 28 Dec 2016 03:21:03 +, Jerry wrote:
There's only so much time and money someone can give. It isn't 
that appealing when virtually no other language out there 
suffers from this problem cause they have an actual market 
behind them.


Most languages have this problem. Most languages you actually 
hear about don't, because the marketing follows the money, and 
you hearing about a language follows the marketing.


D is unusual in how complete it's become without significant 
corporate backing, and how popular it is despite lacking a 
killer application.


Reminds me of markets.  A stock that has obvious disadvantages 
people will not stop talking about that keeps making new highs - 
that's not a stock you want to be short.





Re: D future ...

2016-12-28 Thread Laeeth Isharc via Digitalmars-d

On Wednesday, 28 December 2016 at 03:21:03 UTC, Jerry wrote:
On Tuesday, 27 December 2016 at 16:36:10 UTC, Laeeth Isharc 
wrote:

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
So if you want to improve the language and its ecosystem, the 
best way is to contribute pull requests or $$$s - the 
Foundation now accepts individual donations, and it's also 
open to corporate sponsorship, I believe.



Editor support:


Sublime text and sometimes vim work well enough for me, though 
these things are very personal.  For the others, have you 
contributed anything - time or money in making them better?  
If wishes were horses, beggars would ride.  And contribution 
of either has a higher value than just the thing itself, 
because it also tends to energise the project - look at the 
frustration Basil experienced regarding his IDE project.  It's 
good to have high standards, but one should have some 
appreciation also for the gift that people make of their time, 
work, and energy in ways that don't always lead to the 
gratitude that one might expect.


There's only so much time and money someone can give.


True.  I really have very little time myself, but I was more 
annoyed by seeing the docs wrong and took the twenty minutes or 
so it took to fix them (slow, because I wasn't used to the 
process).  My point is it's a continuum - not a question either 
of donating $500k and all of one's time or zero.


It isn't that appealing when virtually no other language out 
there suffers from this problem cause they have an actual 
market behind them.


One picks one's poison and lives with the consequences.  D's 
advantage isn't shiny marketing, documentation, and polish.  Yet 
its user base seems to be growing and people are building their 
businesses around it.  I wonder why that is.


In my experience it doesn't do much good to complain about a 
problem that is well understood unless one is going to do 
something about it too.  And if one isn't contributing code, 
energy or resources in some other way that will at least make a 
dent in the problem, one shouldn't be so surprised if one's own 
preferences don't perfectly coincide with the preferences of 
those who are.


Those markets fuel money being poured into the tools of the 
lanugage. It doesn't really matter how many users you have, it 
depends on the demographic of those users. If they are all 
students still in school, then you haven't really created a 
market.


People are using D to do real work, and there's more money 
supporting D than ever before.  It might not yet be gazillions, 
but give it time.


Rome wasn't built in a year.  Great things are achieved by 
taking baby steps, compounded over time.  And if one does what 
little one can, others are inspired by it.  Enthusiasm and a 
constructive attitude are infectious in my experience.


D isn't a year old though. If the steps you take are too small, 
you can also end up being left behind.


Tis possible, but I would happily bet against your view.



Re: D future ...

2016-12-28 Thread Andrei Alexandrescu via Digitalmars-d

On 12/28/16 8:17 AM, rikki cattermole wrote:

If you don't hear about any fixes coming from a core dev in the next day
or so, contact Walter directly.


Yes please. Myself too. -- Andrei


Re: D future ...

2016-12-28 Thread Andrei Alexandrescu via Digitalmars-d

On 12/28/16 3:35 AM, Satoshi wrote:

I'm working on a commercial IDE and GUI framework for a year and half
and I'm not able to release any version due to this bug[1].


I'll ask the student in charge with the bug to give it priority. -- Andrei


Re: D future ...

2016-12-28 Thread Satoshi via Digitalmars-d

On Wednesday, 28 December 2016 at 19:51:38 UTC, Jerry wrote:
You don't need the source of the GUI framework to use a 
compiled program. If you are developing both the GUI and the 
IDE, then you don't need interface files. You can just use the 
D source code. Once you compile the IDE no one will have access 
to the interface files anyways, unless (like i mentioned above) 
for third party plugin developers.
No, GUI framework is one part of project like Qt, GTK or WPF and 
IDE is an another part.


That's including all the actual code bodies, you could probably 
write a regex to detect and select them. It wouldn't take as 
long as you think when you start erasing hundreds of lines of 
code with a single backspace. Anyways point is, it isn't really 
a showstopper. You could still have released your IDE without 
interface files to be used as an IDE and you could have made 
the interface files yourself if you really wanted to release 
the GUI.


It's not so simple. I actually must know which functions can be 
called by CTFE and which not. auto functions should have stripped 
body with replaced auto for a specific type, etc.


Main part of the project is GUI framework not IDE itself. IDE is 
made just for simplify GUI development by D'n'D Interface 
Builder. Like in VS or XCode or Qt Creator.


Actually I want to release pre-alpha version of GUI framework 
just for a few people to show them progress, let them test it and 
get some feedback.


I can generate header files and then fix it manually but first I 
need a full coverage tests to recognize where bugs are. But 
still, patching header files every time when I change something 
is not real.


Re: D future ...

2016-12-28 Thread Jerry via Digitalmars-d

On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:

On Wednesday, 28 December 2016 at 09:37:06 UTC, Jerry wrote:
Personally I'm not really looking for an IDE, I've settled for 
a text editor with a plugin for it. IDEs tend to be bulky and 
not be very good at manipulating text or rather lacking 
features to do so.


It depends on specific IDE.

I don't see how the interface generator is stopping you from 
releasing the IDE anyways.


It's GUI framework (set of libraries) what I cannot release. 
IDE is without the libs quite useless.


You don't need the source of the GUI framework to use a compiled 
program. If you are developing both the GUI and the IDE, then you 
don't need interface files. You can just use the D source code. 
Once you compile the IDE no one will have access to the interface 
files anyways, unless (like i mentioned above) for third party 
plugin developers.


Wouldn't be that hard but the project have 200k lines of code. 
Making header files manually is a wast of time what i don't 
have.


That's including all the actual code bodies, you could probably 
write a regex to detect and select them. It wouldn't take as long 
as you think when you start erasing hundreds of lines of code 
with a single backspace. Anyways point is, it isn't really a 
showstopper. You could still have released your IDE without 
interface files to be used as an IDE and you could have made the 
interface files yourself if you really wanted to release the GUI.


But the point is that D compiler specification[1] looks like 
this part works without a problem and is usable but it's a lie 
and nobody cares about it. Actually it will not ruin my project 
but complicates it. And this is not the way in which should 
business be made. 10 years of development and still some key 
features won't work properly.


[1] https://dlang.org/dmd-osx.html#interface-files


It's a feature that probably a few people actually use, odds are 
they forget about it when adding new features and potentially 
there are no tests for it either.




Re: D future ...

2016-12-28 Thread Chris Wright via Digitalmars-d
On Wed, 28 Dec 2016 16:09:28 +, Chris Wright wrote:

> On Wed, 28 Dec 2016 11:36:33 +, Satoshi wrote:
> 
>> On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote:
>>> On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: On
>>> Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
 Making header files manually is a wast of time what i don't have.
>>>
>>> Write your own header generator.
>> Yes, why not to write my own language.
> 
> It should be significantly easier with dmd's json output.

My apologies; dmd's json output suffers the same problem.


Re: D future ...

2016-12-28 Thread Chris Wright via Digitalmars-d
On Wed, 28 Dec 2016 11:36:33 +, Satoshi wrote:

> On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote:
>> On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: On
>> Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
>>> Making header files manually is a wast of time what i don't have.
>>
>> Write your own header generator.
> Yes, why not to write my own language.

It should be significantly easier with dmd's json output.


Re: D future ...

2016-12-28 Thread Satoshi via Digitalmars-d

On Wednesday, 28 December 2016 at 12:55:17 UTC, YAHB wrote:
Sorry, to be honest I didn't take you seriously. Your bug 
report, so the starter of this off topic fork, is barely 
understandable: impossible to understand if it was a language 
issue, an issue of the header function generator...
Sorry, I didn't want to start OT I just want to point on some 
aspects of D from my view.
My english is bad so I'm not able to express things as 
professionally as in my native language. But I think people here 
are enough intelligent to take me seriously regardless on how I 
write. Sorry...


Re: D future ...

2016-12-28 Thread rikki cattermole via Digitalmars-d

On 29/12/2016 2:08 AM, Satoshi wrote:

On Wednesday, 28 December 2016 at 12:43:03 UTC, bachmeier wrote:

On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote:

I'm working on a commercial IDE and GUI framework for a year and half
and I'm not able to release any version due to this bug[1].


...


Please, stop adding new features to D and start fixing existing ones.

- Satoshi

---
[1] https://issues.dlang.org/show_bug.cgi?id=16590


You've got things reversed. The point of a company like Google or Sun
backing a language is that things get done, like this bug fix, so that
the language can be used for whatever that company needs it to do.

You claim you want to make money off the language, yet you are
demanding that volunteers immediately fix a bug that is holding you
back. That's an odd business model. You have three options: pay to fix
it yourself, use a different language that allows you to benefit from
work paid for by more profitable companies like Google, or wait for
volunteers to do it on their schedule.

This is not unique to D. I'm reminded of Visual Studio not supporting
C99 or Firefox not supporting certain HTML 5 features.


I know that :/  I'm just responding to people who wants shift D to
commercial companies but are doing different steps than they should do.

Yes, it's true that I want to make money off the language so I should
paid for that fix but in other way you want to promote D to others and
this is the thing what's holding me back to do the same. And the bug
will be fixed anyway, so.


If you don't hear about any fixes coming from a core dev in the next day 
or so, contact Walter directly.




Re: D future ...

2016-12-28 Thread Satoshi via Digitalmars-d

On Wednesday, 28 December 2016 at 12:43:03 UTC, bachmeier wrote:

On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote:
I'm working on a commercial IDE and GUI framework for a year 
and half and I'm not able to release any version due to this 
bug[1].


...

Please, stop adding new features to D and start fixing 
existing ones.


- Satoshi

---
[1] https://issues.dlang.org/show_bug.cgi?id=16590


You've got things reversed. The point of a company like Google 
or Sun backing a language is that things get done, like this 
bug fix, so that the language can be used for whatever that 
company needs it to do.


You claim you want to make money off the language, yet you are 
demanding that volunteers immediately fix a bug that is holding 
you back. That's an odd business model. You have three options: 
pay to fix it yourself, use a different language that allows 
you to benefit from work paid for by more profitable companies 
like Google, or wait for volunteers to do it on their schedule.


This is not unique to D. I'm reminded of Visual Studio not 
supporting C99 or Firefox not supporting certain HTML 5 
features.


I know that :/  I'm just responding to people who wants shift D 
to commercial companies but are doing different steps than they 
should do.


Yes, it's true that I want to make money off the language so I 
should paid for that fix but in other way you want to promote D 
to others and this is the thing what's holding me back to do the 
same. And the bug will be fixed anyway, so.




Re: D future ...

2016-12-28 Thread YAHB via Digitalmars-d

On Wednesday, 28 December 2016 at 12:44:38 UTC, Satoshi wrote:

On Wednesday, 28 December 2016 at 12:14:02 UTC, YAHB wrote:
But what's the real issue ? You want to release a 
pre-compiled static library with headers ?

Yes.


you'll be in front of another issue then: "dmd_personality"... 
unless you release the static library for DMD, LDC, GDC, + 
each version for each, basically debug + release...so already 
6 ;]


Nope :)
Rikarin Studio is a package of precompiled druntime, phobos, 
Rikarin Framework (Async core, GUI AppKit, basic bindings...) 
bundled with LDC and own build tool distributed as a toolkit. 
User will not be able to choose between compilers :)


This is what people need, not 800 variants of every tool where 
at least one cannot work properly.


Sorry, to be honest I didn't take you seriously. Your bug report, 
so the starter of this off topic fork, is barely understandable: 
impossible to understand if it was a language issue, an issue of 
the header function generator...


You can open a bounty for this.


Re: D future ...

2016-12-28 Thread YAHB via Digitalmars-d

On Wednesday, 28 December 2016 at 12:43:03 UTC, bachmeier wrote:

On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote:
I'm working on a commercial IDE and GUI framework for a year 
and half and I'm not able to release any version due to this 
bug[1].


...

Please, stop adding new features to D and start fixing 
existing ones.


- Satoshi

---
[1] https://issues.dlang.org/show_bug.cgi?id=16590


You've got things reversed. The point of a company like Google 
or Sun backing a language is that things get done, like this 
bug fix, so that the language can be used for whatever that 
company needs it to do.


You claim you want to make money off the language, yet you are 
demanding that volunteers immediately fix a bug that is holding 
you back. That's an odd business model. You have three options: 
pay to fix it yourself, use a different language that allows 
you to benefit from work paid for by more profitable companies 
like Google, or wait for volunteers to do it on their schedule.


This is not unique to D. I'm reminded of Visual Studio not 
supporting C99 or Firefox not supporting certain HTML 5 
features.


That was what I thought to propose to him: he could found a 
bounty. Bounties are for a product but the founder doesn't have 
to be in the company or, like here, in the organization.


Re: D future ...

2016-12-28 Thread Satoshi via Digitalmars-d

On Wednesday, 28 December 2016 at 12:14:02 UTC, YAHB wrote:
But what's the real issue ? You want to release a 
pre-compiled static library with headers ?

Yes.


you'll be in front of another issue then: "dmd_personality"... 
unless you release the static library for DMD, LDC, GDC, + each 
version for each, basically debug + release...so already 6 ;]


Nope :)
Rikarin Studio is a package of precompiled druntime, phobos, 
Rikarin Framework (Async core, GUI AppKit, basic bindings...) 
bundled with LDC and own build tool distributed as a toolkit. 
User will not be able to choose between compilers :)


This is what people need, not 800 variants of every tool where at 
least one cannot work properly.


Re: D future ...

2016-12-28 Thread bachmeier via Digitalmars-d

On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote:
I'm working on a commercial IDE and GUI framework for a year 
and half and I'm not able to release any version due to this 
bug[1].


...

Please, stop adding new features to D and start fixing existing 
ones.


- Satoshi

---
[1] https://issues.dlang.org/show_bug.cgi?id=16590


You've got things reversed. The point of a company like Google or 
Sun backing a language is that things get done, like this bug 
fix, so that the language can be used for whatever that company 
needs it to do.


You claim you want to make money off the language, yet you are 
demanding that volunteers immediately fix a bug that is holding 
you back. That's an odd business model. You have three options: 
pay to fix it yourself, use a different language that allows you 
to benefit from work paid for by more profitable companies like 
Google, or wait for volunteers to do it on their schedule.


This is not unique to D. I'm reminded of Visual Studio not 
supporting C99 or Firefox not supporting certain HTML 5 features.


Re: D future ...

2016-12-28 Thread Satoshi via Digitalmars-d

On Wednesday, 28 December 2016 at 12:03:53 UTC, YAHB wrote:
Making header files manually is a wast of time what i don't 
have.


Write your own header generator.

Yes, why not to write my own language.


Pfff...too hard to use an AST visitor. And that wants to 
release a commercial IDE.

Compiler design is not my business.

Personally I don't get the point of writing an IDE if at a 
time or another you don't start working a bit around you 
know...D syntax, D grammar.

Actually, I written an OS in D.


True...an Outrageous Scam...

So funny...
https://github.com/Rikarin/Trinix

Instead you seem to get stuck on first issue related to the 
language.
First issue? Developers of LDC can respond and fix issue in a 
real time but developers of D frontend not. And that's the 
thing what pissed me off.


But what's the real issue ? You want to release a 
pre-compiled static library with headers ?

Yes.


Then you could license the sources, simply.

No, thanks.


Just think to your strategy and try to be wise. Even Qt sources 
are available. There's at least 10 ways to waste a freelance 
commercial project.
Qt is out of dated crap mostly useless for fast GUI development. 
Anyway, it's my project and I don't want to release source codes. 
No, it's not a freelance project, I got some money for dev and I 
already have clients waiting for stable release. There will be 
info soon.


Personally I've been client of a commercial GUI framework, 
and we get the sources with the license. It worked, I mean 
that the developer had clients.

I don't need to follow same rules as others do.


Re: D future ...

2016-12-28 Thread YAHB via Digitalmars-d

On Wednesday, 28 December 2016 at 11:36:33 UTC, Satoshi wrote:

On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote:

On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
But what's the real issue ? You want to release a pre-compiled 
static library with headers ?

Yes.


you'll be in front of another issue then: "dmd_personality"... 
unless you release the static library for DMD, LDC, GDC, + each 
version for each, basically debug + release...so already 6 ;]


Re: D future ...

2016-12-28 Thread YAHB via Digitalmars-d

On Wednesday, 28 December 2016 at 11:36:33 UTC, Satoshi wrote:

On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote:

On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
Making header files manually is a wast of time what i don't 
have.


Write your own header generator.

Yes, why not to write my own language.


Pfff...too hard to use an AST visitor. And that wants to release 
a commercial IDE.




Personally I don't get the point of writing an IDE if at a 
time or another you don't start working a bit around you 
know...D syntax, D grammar.

Actually, I written an OS in D.


True...an Outrageous Scam...



Instead you seem to get stuck on first issue related to the 
language.
First issue? Developers of LDC can respond and fix issue in a 
real time but developers of D frontend not. And that's the 
thing what pissed me off.


But what's the real issue ? You want to release a pre-compiled 
static library with headers ?

Yes.


Then you could license the sources, simply.

No, thanks.


Just think to your strategy and try to be wise. Even Qt sources 
are available. There's at least 10 ways to waste a freelance 
commercial project.




Personally I've been client of a commercial GUI framework, and 
we get the sources with the license. It worked, I mean that 
the developer had clients.





Re: D future ...

2016-12-28 Thread Satoshi via Digitalmars-d

On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote:

On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
Making header files manually is a wast of time what i don't 
have.


Write your own header generator.

Yes, why not to write my own language.

Personally I don't get the point of writing an IDE if at a time 
or another you don't start working a bit around you know...D 
syntax, D grammar.

Actually, I written an OS in D.

Instead you seem to get stuck on first issue related to the 
language.
First issue? Developers of LDC can respond and fix issue in a 
real time but developers of D frontend not. And that's the thing 
what pissed me off.


But what's the real issue ? You want to release a pre-compiled 
static library with headers ?

Yes.


Then you could license the sources, simply.

No, thanks.

Personally I've been client of a commercial GUI framework, and 
we get the sources with the license. It worked, I mean that the 
developer had clients.





Re: D future ...

2016-12-28 Thread YAHB via Digitalmars-d

On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
Making header files manually is a wast of time what i don't 
have.


Write your own header generator. Personally I don't get the point 
of writing an IDE if at a time or another you don't start working 
a bit around you know...D syntax, D grammar. Instead you seem to 
get stuck on first issue related to the language.


But what's the real issue ? You want to release a pre-compiled 
static library with headers ? Then you could license the sources, 
simply. Personally I've been client of a commercial GUI 
framework, and we get the sources with the license. It worked, I 
mean that the developer had clients.


Re: D future ...

2016-12-28 Thread Satoshi via Digitalmars-d

On Wednesday, 28 December 2016 at 09:37:06 UTC, Jerry wrote:
Personally I'm not really looking for an IDE, I've settled for 
a text editor with a plugin for it. IDEs tend to be bulky and 
not be very good at manipulating text or rather lacking 
features to do so.


It depends on specific IDE.

I don't see how the interface generator is stopping you from 
releasing the IDE anyways.


It's GUI framework (set of libraries) what I cannot release. IDE 
is without the libs quite useless.



All it would really stop is
potentially third party plugins. Even then you can just write 
the interface files yourself. Wouldn't be that hard, just 
coping the source file and removing function bodies for the 
most part. What you'd need to do if you were writing C++ code, 
but you would keep the header and source files in sync as you 
were developing.


Wouldn't be that hard but the project have 200k lines of code. 
Making header files manually is a wast of time what i don't have.


But the point is that D compiler specification[1] looks like this 
part works without a problem and is usable but it's a lie and 
nobody cares about it. Actually it will not ruin my project but 
complicates it. And this is not the way in which should business 
be made. 10 years of development and still some key features 
won't work properly.


[1] https://dlang.org/dmd-osx.html#interface-files


Re: D future ...

2016-12-28 Thread Jerry via Digitalmars-d

On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote:
I'm working on a commercial IDE and GUI framework for a year 
and half and I'm not able to release any version due to this 
bug[1].
But nobody cares about fixing it because it doesn't give any 
benefits in opensource way to D or what.


I don't know how there can be any others closed 
source/commercial libraries for D when the one of the key 
features won't work.


Actually I wasted one and half year of developing project that 
I cannot release due to the bug. When I started I didn't even 
know that future existence of my project can depend on the 
compiler itself. Please, stop adding new features to D and 
start fixing existing ones.


- Satoshi

---
[1] https://issues.dlang.org/show_bug.cgi?id=16590


Personally I'm not really looking for an IDE, I've settled for a 
text editor with a plugin for it. IDEs tend to be bulky and not 
be very good at manipulating text or rather lacking features to 
do so.


I don't see how the interface generator is stopping you from 
releasing the IDE anyways. All it would really stop is 
potentially third party plugins. Even then you can just write the 
interface files yourself. Wouldn't be that hard, just coping the 
source file and removing function bodies for the most part. What 
you'd need to do if you were writing C++ code, but you would keep 
the header and source files in sync as you were developing.




Re: D future ...

2016-12-28 Thread Satoshi via Digitalmars-d

On Wednesday, 28 December 2016 at 03:21:03 UTC, Jerry wrote:
On Tuesday, 27 December 2016 at 16:36:10 UTC, Laeeth Isharc 
wrote:

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
So if you want to improve the language and its ecosystem, the 
best way is to contribute pull requests or $$$s - the 
Foundation now accepts individual donations, and it's also 
open to corporate sponsorship, I believe.



Editor support:


Sublime text and sometimes vim work well enough for me, though 
these things are very personal.  For the others, have you 
contributed anything - time or money in making them better?  
If wishes were horses, beggars would ride.  And contribution 
of either has a higher value than just the thing itself, 
because it also tends to energise the project - look at the 
frustration Basil experienced regarding his IDE project.  It's 
good to have high standards, but one should have some 
appreciation also for the gift that people make of their time, 
work, and energy in ways that don't always lead to the 
gratitude that one might expect.


There's only so much time and money someone can give. It isn't 
that appealing when virtually no other language out there 
suffers from this problem cause they have an actual market 
behind them. Those markets fuel money being poured into the 
tools of the lanugage. It doesn't really matter how many users 
you have, it depends on the demographic of those users. If they 
are all students still in school, then you haven't really 
created a market.


Anyways most of the IDEs out there are made by a small team or 
only one person. Not only that but they almost all (if not all) 
rely on the same projects to get the features you would expect 
in an IDE. The DCD, DScanner, DFix, DFmt etc... All those tools 
also seem to be developed primarily by the same single person. 
Rust seems to be in a similar situation but at least it seems 
the rust team has plans for adding IDE support into the 
compiler itself. Something that is probably unrealistic for D.


Seb posted a massive list of modules that can be standard 
candidates. And the response is more or less ignore it. 
People who work on Standard libraries are more motivated. 
Bring  them into the fold. But it seems that they simple get 
ignored.


Rome wasn't built in a year.  Great things are achieved by 
taking baby steps, compounded over time.  And if one does what 
little one can, others are inspired by it.  Enthusiasm and a 
constructive attitude are infectious in my experience.


D isn't a year old though. If the steps you take are too small, 
you can also end up being left behind.



I'm working on a commercial IDE and GUI framework for a year and 
half and I'm not able to release any version due to this bug[1].
But nobody cares about fixing it because it doesn't give any 
benefits in opensource way to D or what.


I don't know how there can be any others closed source/commercial 
libraries for D when the one of the key features won't work.


Actually I wasted one and half year of developing project that I 
cannot release due to the bug. When I started I didn't even know 
that future existence of my project can depend on the compiler 
itself. Please, stop adding new features to D and start fixing 
existing ones.


- Satoshi

---
[1] https://issues.dlang.org/show_bug.cgi?id=16590


Re: D future ...

2016-12-27 Thread Chris Wright via Digitalmars-d
On Wed, 28 Dec 2016 03:21:03 +, Jerry wrote:
> There's only so much time and money someone can give. It isn't that
> appealing when virtually no other language out there suffers from this
> problem cause they have an actual market behind them.

Most languages have this problem. Most languages you actually hear about 
don't, because the marketing follows the money, and you hearing about a 
language follows the marketing.

D is unusual in how complete it's become without significant corporate 
backing, and how popular it is despite lacking a killer application.


Re: D future ...

2016-12-27 Thread Jerry via Digitalmars-d

On Tuesday, 27 December 2016 at 16:36:10 UTC, Laeeth Isharc wrote:

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
So if you want to improve the language and its ecosystem, the 
best way is to contribute pull requests or $$$s - the 
Foundation now accepts individual donations, and it's also open 
to corporate sponsorship, I believe.



Editor support:


Sublime text and sometimes vim work well enough for me, though 
these things are very personal.  For the others, have you 
contributed anything - time or money in making them better?  If 
wishes were horses, beggars would ride.  And contribution of 
either has a higher value than just the thing itself, because 
it also tends to energise the project - look at the frustration 
Basil experienced regarding his IDE project.  It's good to have 
high standards, but one should have some appreciation also for 
the gift that people make of their time, work, and energy in 
ways that don't always lead to the gratitude that one might 
expect.


There's only so much time and money someone can give. It isn't 
that appealing when virtually no other language out there suffers 
from this problem cause they have an actual market behind them. 
Those markets fuel money being poured into the tools of the 
lanugage. It doesn't really matter how many users you have, it 
depends on the demographic of those users. If they are all 
students still in school, then you haven't really created a 
market.


Anyways most of the IDEs out there are made by a small team or 
only one person. Not only that but they almost all (if not all) 
rely on the same projects to get the features you would expect in 
an IDE. The DCD, DScanner, DFix, DFmt etc... All those tools also 
seem to be developed primarily by the same single person. Rust 
seems to be in a similar situation but at least it seems the rust 
team has plans for adding IDE support into the compiler itself. 
Something that is probably unrealistic for D.


Seb posted a massive list of modules that can be standard 
candidates. And the response is more or less ignore it. People 
who work on Standard libraries are more motivated. Bring  them 
into the fold. But it seems that they simple get ignored.


Rome wasn't built in a year.  Great things are achieved by 
taking baby steps, compounded over time.  And if one does what 
little one can, others are inspired by it.  Enthusiasm and a 
constructive attitude are infectious in my experience.


D isn't a year old though. If the steps you take are too small, 
you can also end up being left behind.


Re: D future ...

2016-12-27 Thread Laeeth Isharc via Digitalmars-d

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

D has not market:
-

A lot of times people complain that D has no real audience / 
market. Is D the perfect system. No... But lets compare to 
those other languages shall we? Now this is my opinion, so take 
it with a bit of salt.


People who are complaining that D has no market aren't using the 
language on the whole - or are using it for private projects and 
would like to use it for work but don't know of any professional 
opportunities where they can do so.  The latter is a high quality 
problem to have for an emerging language because it means people 
find some reason to want to use the language, and those who care 
about using good tools tend to be better programmers than those 
who don't.


Still, it's not true that D has no real market, because the 
userbase is demonstrably growing.  A complex creature matures 
more slowly than a simple one - what's significant is not that D 
does not have an official corporate sponsor of the kind that Go 
has (Sociomantic plays a different role, as I understand it), but 
that it is flourishing in spite of not having one and in spite of 
the absence of any kind of marketing orientation.  That says 
quite a lot about its intrinsic merits, and we're in an era where 
the pendulum is shifting from shiny things sponsored by large 
corporations to giving a greater chance to more grass-roots 
organic developments.


When you have a small market share, it's easy to win.  You don't 
need to appeal to "a lot of C++ people" - just a few of them, a 
few frustrated Python guys, and so on.  D fits quite well the 
Innovator's Dilemma described by Clayton Christensen.  It's a 
positive not a negative that many prefer to dismiss it since it 
makes it easier for it to gain a hold in certain niches, draw 
energy from such and then spread into adjacent niches.


I see a lot of people arguing a lot about D and sorry to say 
but at times it sounds like a kindergarten.


People who care about excellence will tend to argue a lot - see 
Andy Grove's 'constructive confrontation', Charles Koch's 'market 
based management', and Ray Dalio's 'Principles'.  The key thing 
is what happens in response to that.  The language and its 
documentation are better now than a year ago, and a year ago were 
better then the previous year.  It's not perfect, but life never 
is.


Maybe its because people who use D are more into proprietary 
software, that
there is less community response with work going into the 
library.


If that's true (and I think it might be), that's a very positive 
thing, because most software is proprietary software, and 
adoption by companies when successful will tend to provide a 
future source of support and energy for the ecosystem.  You can 
see this already with Sociomantic's sponsorship, but they aren't 
the only ones.  I've paid for some small improvements in dub's 
shared library support myself (-fPIC did not propagate which made 
using dub to build shared libraries on linux a bit tricky, but it 
does now, or will do once PRs are accepted), and you get to 
excellence from many little improvements of this sort.


So if you want to improve the language and its ecosystem, the 
best way is to contribute pull requests or $$$s - the Foundation 
now accepts individual donations, and it's also open to corporate 
sponsorship, I believe.  One should be a bit patient in expecting 
changes from the creation of the Foundation - it's an awful lot 
of work to set something up, and once that's done to figure out 
how to deploy resources to efficiently make a difference.  It's 
quite impressive what has been done already - very smart approach 
to start with institutions one has a personal/national connection 
with and where great people are much more available than in some 
other countries.


And on the other hand, pull requests don't need to take much 
energy.  I don't have much time, but I noticed the curl examples 
were out of date - string vs char[] if I recall right, and they 
were annoying me, so I fixed them and they were pulled pretty 
much immediately.


Most D users don't spend much time on the forums or IRC because 
they haven't time for it since they are actually using D to get 
stuff done.  Look at the list of corporate users, and look at the 
small share of the people working on D in these companies in 
forum discussions.  And that's only a subset of commercial D 
users.


Languages reach explosive takeoff not when they make a big change 
in strategy but when external conditions change in such a way 
that the problem the language solves suddenly becomes much more 
important.  Just as Japanese cars didn't used to be very good - 
and who would want a rinky dink thing like they used to be.  But 
then energy prices exploded in the 70s, and peoples' priorities 
changed - and the poor US auto-makers, complacent and bloated in 
their prior success didn't know what had hit them.  I've written 
a bit 

Re: D future ...

2016-12-26 Thread WebFreak001 via Digitalmars-d

On Monday, 26 December 2016 at 19:37:34 UTC, David Gileadi wrote:

On 12/24/16 5:11 PM, WebFreak001 wrote:
On Thursday, 22 December 2016 at 04:47:06 UTC, Chris Wright 
wrote:

CTFE ( Stefan is dealing with that ), Documentation,
better Editor support...


I think code-d could potentially be extended to install its
dependencies, which would improve the situation there.


It does already do that though :/


Will it auto-update them as new versions are released, or when 
code-d is updated?


it will only update workspace-d and only when the plugin updates 
and requires a new version


Re: D future ...

2016-12-26 Thread David Gileadi via Digitalmars-d

On 12/24/16 5:11 PM, WebFreak001 wrote:

On Thursday, 22 December 2016 at 04:47:06 UTC, Chris Wright wrote:

CTFE ( Stefan is dealing with that ), Documentation,
better Editor support...


I think code-d could potentially be extended to install its
dependencies, which would improve the situation there.


It does already do that though :/


Will it auto-update them as new versions are released, or when code-d is 
updated?


Re: D future ...

2016-12-24 Thread WebFreak001 via Digitalmars-d

On Thursday, 22 December 2016 at 04:47:06 UTC, Chris Wright wrote:

CTFE ( Stefan is dealing with that ), Documentation,
better Editor support...


I think code-d could potentially be extended to install its 
dependencies, which would improve the situation there.


It does already do that though :/


Re: D future ...

2016-12-21 Thread Walter Bright via Digitalmars-d

On 12/21/2016 7:57 PM, Chris Wright wrote:

You can implement write barriers as runtime calls, but omit them in @nogc
code.


@nogc code is code that doesn't allocate from the gc. It can still write to gc 
allocated objects, however, so that idea won't work.




However, this would be costly -- it's an expensive technique in
general; the current GC mallocs each object instead of mmaping a range of
memory; and in D you can't move heap objects safely,


You can if using a "mostly copying" generational collector, which is what I did 
long ago. It works.



so you can't
distinguish generations based on pointers (you'd have to mark GC data
structures, and it's O(log n) to find the right one).

You can implement write barriers with mprotect. However, this won't give
you good granularity. You just know that someone wrote something to an 8
kilobyte block of memory that has a pointer in it somewhere. This
requires the GC to use mmap instead of malloc, and it is strongly
encouraged not to put pointer-free objects in the same page as objects
with pointers.


Using mprotect works, and I wrote a generational collector using it long ago, 
but it is even slower.




Re: D future ...

2016-12-21 Thread Walter Bright via Digitalmars-d

On 12/21/2016 6:50 AM, thedeemon wrote:

Have you seen this one?
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html


Although I had called them write gates, write barriers are the same thing. Yes, 
that's the problem with implementing a generational collector in D.


I once tried to implement write barriers by using the hardware VM system. I'd 
mark the old generation pages as read-only. When the program would write to 
those pages, a seg fault happened. This would then run a handler in the GC code 
which would mark that page as "dirty", then write-enable the page, and restart 
the program at the point where it seg faulted.


This worked great. The only trouble was that the seg faulting path at runtime 
was so slow it ruined the speed advantage of not have write barriers. So I had 
to abandon it.


But that was long ago. Maybe the tradeoff is better these days with modern 
hardware. But I suspect that if other GC developers are not using this 
technique, it is still too slow.


Re: D future ...

2016-12-21 Thread Walter Bright via Digitalmars-d

On 12/21/2016 3:36 AM, thedeemon wrote:

Bad news: without complete redesign of the language and turning into one more
C++/CLI (where you have different kinds of pointers in the language for GC and
non-GC), having C performance and Go-style low-pause GC is not really possible.
You have to choose one. Go chose GC with short pauses but paid with slow speed
overall and slow C interop. D chose C-level performance but paid for it with a
slow GC.


The trouble with a better GC is it usually entails changing the code generator 
to emit a "write gate" that goes along with assignments via a pointer. This 
write gate signals the GC that a particular block is being written to, so that 
block can be marked as "dirty". (Paging virtual memory systems do this 
automatically.)


What this implies is better GC performance comes at a cost of worse performance 
of the non-GC code. This strategy is effective for a language that makes very 
heavy use of the GC (like Java does), but for a language like D that uses the GC 
lightly, it's a much more elusive benefit.


Re: D future ...

2016-12-21 Thread Chris Wright via Digitalmars-d
> Library Standardization:
> 
> 
> Some of the proposals sounds very correct. The library needs to be
> split. Every module needs its own GIT. People need to be able to add
> standard modules ( after approval ).

I can't agree with you there. There are a lot of dependencies between 
modules.

> No offense but where is the standard database library for D? There is
> none. That is just a load of bull. Anybody who wants to program in any
> language expect the language to have a standard database library! Not
> that you need to search the packages for a standard library. I have seen
> one man projects that have more standard library support then D.

Go, Java, and C# each have database _interfaces_ in their standard 
libraries. Most other languages don't.

These interfaces don't let you connect to any database. You still need a 
library to connect to a specific database.

With the rise of document databases and alternate query systems, it's 
harder to define a generic database library. It's still possible to write 
one for SQL databases.

> I do not use 3th party packages

The standard library needs a rigorous approval process. That takes time 
and human attention for the review and to address concerns identified 
during review.

D is marginal, and that means we simply don't have the time to get these 
things done.

> Documentation:
> --
> 
> I do not use it. Its such a mess to read with long paragraphs

Long paragraphs describing the details of what a thing does is generally 
a good thing. MSDN's documentation is like that.

The "mess" part is when we have five hundred identifiers documented in 
one web page. dpldocs.info is much better about this.

> and a LOT of stuff not even documented.

There's no excuse for that.

> This automated documentation generation is the same  i see in other
> "new" languages.

The documentation is hand-written. We don't have a tool capable of 
annotating, say, std.string.detab with "Replace each tab character in s 
with the number of spaces necessary to align the following character at 
the next tab stop." without human intervention. That would be impressive, 
though.

The HTML is generated by a tool.

> Editor support:
> ---
> 
> What a struggle. Visual Studio C is probably the editor with the best
> 3th party support.

VS Code isn't terrible. It's got the disadvantage that it tries to 
autocomplete every possible thing -- so you get __monitor and __vptr 
first, and the other options include things you can't access.

> Too many need 3th party to do something that D needs to support from
> itself:
> 
> dcd - Used for auto completion
> dfmt - Used for code formatting
> dscanner - Used for static code linting ...
> 
> This needs to be in the default installation of dmd! It makes no sense
> that these are not included.

>From a usability standpoint, I agree.

>From a political standpoint, it's unsurprising that they're not included.

> Future:
> 
> 
> You want D to have traction.

That's *a* goal, but it's not the goal that's closest to most of our 
hearts, I think. Popularity doesn't exactly bring enjoyment -- it can 
remove some annoyances, but it's easier to work around those annoyances. 
It isn't fulfilling. And it doesn't pay the bills.

> Marketing, more library support, less focus
> on adding even more advanced features, fixing issues (
> like better GC ),

There are huge barriers to bringing D's GC to the state of the art. Some 
improvements could be made, though. For instance, the GC currently scans 
heap objects scattered about the whole heap. Using separate virtual 
address ranges for objects with pointers and objects without might 
improve efficiency somewhat.

> CTFE ( Stefan is dealing with that ), Documentation,
> better Editor support...

I think code-d could potentially be extended to install its dependencies, 
which would improve the situation there.

> Walter / Andrei:
> 
> 
> No offense guys, just something that i see in a lot of posts. The
> hinting at people to add more to the standard libraries. That little
> push. But frankly, its annoying when nothing gets done.
> 
> People complain about x feature. You tell people to add to the standard
> library or bring the project in. But anybody who has ever read this
> forum sees how adding things to the language is LONG process and a lot
> of times idea's get shot down very fast.

The language is *very* conservative. The standard library is merely 
cautious. But since there's no cost to adding a package to dub, that 
doesn't prevent code from being written and reused. Except by those who 
refuse to go outside the standard library, and for those people, I would 
recommend Java or C#.

> For the standard library there is no process as far as i can tell.
> Experimental at best, where code seems to have a nice long death.

It could be much better documented.

The process for small changes:

* Make the change.
* Make a pull request.

The process 

Re: D future ...

2016-12-21 Thread thedeemon via Digitalmars-d

On Thursday, 22 December 2016 at 03:57:10 UTC, Chris Wright wrote:

You can implement write barriers as runtime calls, but omit 
them in @nogc code.


That means redefining what @nogc means. Currently it basically 
means "does not GC-allocate" and you want to change it to "does 
not mutate GC-allocated objects" which is very different and 
hardly possible to check in compiler without further changing the 
language.


However, this would be costly -- it's an expensive technique in 
general;


Yep, that's what I'm saying. Fast GC has a price on the rest code 
speed. Fast code has a price on GC. Unless you separate them very 
clearly by language means.





Re: D future ...

2016-12-21 Thread Chris Wright via Digitalmars-d
On Wed, 21 Dec 2016 11:36:14 +, thedeemon wrote:
> Bad news: without complete redesign of the language and turning into one
> more C++/CLI (where you have different kinds of pointers in the language
> for GC and non-GC), having C performance and Go-style low-pause GC is
> not really possible. You have to choose one. Go chose GC with short
> pauses but paid with slow speed overall and slow C interop. D chose
> C-level performance but paid for it with a slow GC.

You can implement write barriers as runtime calls, but omit them in @nogc 
code. However, this would be costly -- it's an expensive technique in 
general; the current GC mallocs each object instead of mmaping a range of 
memory; and in D you can't move heap objects safely, so you can't 
distinguish generations based on pointers (you'd have to mark GC data 
structures, and it's O(log n) to find the right one).

You can implement write barriers with mprotect. However, this won't give 
you good granularity. You just know that someone wrote something to an 8 
kilobyte block of memory that has a pointer in it somewhere. This 
requires the GC to use mmap instead of malloc, and it is strongly 
encouraged not to put pointer-free objects in the same page as objects 
with pointers.


Re: D future ...

2016-12-21 Thread Chris Wright via Digitalmars-d
On Tue, 20 Dec 2016 08:20:32 +, LiNbO3 wrote:
> And have the patch wait in the PR queue until the end of time,
> not even acknowledged at all ?

When I've put in PRs for doc improvements, they've been reviewed 
relatively quickly.


Re: D future ...

2016-12-21 Thread Walter Bright via Digitalmars-d

On 12/21/2016 6:24 AM, Mark wrote:

I do not think that this would be a bad use of the
foundation's funds.


That is one of the purposes of the Foundation.


Re: D future ...

2016-12-21 Thread Jon Degenhardt via Digitalmars-d

On Wednesday, 21 December 2016 at 14:50:31 UTC, thedeemon wrote:
On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko 
wrote:
On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon 
wrote:
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers 
wrote:

[...]


Bad news: without complete redesign of the language and 
turning into one more C++/CLI (where you have different kinds 
of pointers in the language for GC and non-GC), having C 
performance and Go-style low-pause GC is not really possible. 
You have to choose one. Go chose GC with short pauses but 
paid with slow speed overall and slow C interop. D chose 
C-level performance but paid for it with a slow GC.


If this is true, a blog post about it with more details is 
very welcome --Ilya


Have you seen this one?
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html


A recent blog post regarding the Go garbage collector with 
pertinent info: 
https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e


Re: D future ...

2016-12-21 Thread Ilya Yaroshenko via Digitalmars-d

On Wednesday, 21 December 2016 at 14:50:31 UTC, thedeemon wrote:
On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko 
wrote:
On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon 
wrote:

[...]


If this is true, a blog post about it with more details is 
very welcome --Ilya


Have you seen this one?
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html


Thanks for the link, will read


Re: D future ...

2016-12-21 Thread thedeemon via Digitalmars-d
On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko 
wrote:

On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers 
wrote:

[...]


Bad news: without complete redesign of the language and 
turning into one more C++/CLI (where you have different kinds 
of pointers in the language for GC and non-GC), having C 
performance and Go-style low-pause GC is not really possible. 
You have to choose one. Go chose GC with short pauses but paid 
with slow speed overall and slow C interop. D chose C-level 
performance but paid for it with a slow GC.


If this is true, a blog post about it with more details is very 
welcome --Ilya


Have you seen this one?
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html


Re: D future ...

2016-12-21 Thread Mark via Digitalmars-d

On Tuesday, 20 December 2016 at 16:22:43 UTC, Walter Bright wrote:
D is quite a bit less formal, but still, if you want action 
consider that you aren't going to get it with any organization 
unless you're willing to:


1. pay others to do it

2. convince others that your important issues are more 
important than everyone else's important issues that they are 
already working on


3. put some effort into it yourself

This includes C, C++, Java, Go, Rust, basically every language 
in existence.


---

Note that pretty much every day in the D forums, people post 
lists of their most important issues they want other people to 
work on. And the lists are always different.


When people invest time into solving the problems they complain 
about, that's evidence that those issues are more important. 
It's the same in C++ land - a common sentiment among the C++ 
stars is that if someone isn't willing to make an effort to 
write a proposal to the C++ Committee, it isn't an issue worth 
their time, either.


It really can't be any other way.


What about the first way in your list ("pay others to do it")? 
From what I gather, this was one of the reasons for founding the 
D Foundation.


There are many "boring" tasks that few people seem interested in 
doing: improving the documentation, maintaining the website, 
improving the forum system (it lacks many important features 
IMHO), improving IDE support for D (I have no idea how one would 
go about doing this but it's important), etc. (The vision 
document in the D wiki contains many more such "boring" tasks).


And the few people that do work on the "boring" stuff seem to be 
the "wrong" people. One does not need to be a compiler expert or 
a metaprogramming guru to work on the tasks mentioned. That would 
be a bad use of that person's time - his/her skills lie 
elsewhere. If no one is interested in doing this stuff then maybe 
it's a good idea for the D Foundation to hire some people who'll 
dedicate their time to these issues. I do not think that this 
would be a bad use of the foundation's funds.


Re: D future ...

2016-12-21 Thread Ilya Yaroshenko via Digitalmars-d
On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko 
wrote:

On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers 
wrote:

[...]


Bad news: without complete redesign of the language and 
turning into one more C++/CLI (where you have different kinds 
of pointers in the language for GC and non-GC), having C 
performance and Go-style low-pause GC is not really possible. 
You have to choose one. Go chose GC with short pauses but paid 
with slow speed overall and slow C interop. D chose C-level 
performance but paid for it with a slow GC.


If this is true, a blog post about it with more details is very 
welcome --Ilya


You may want to open PR for Mir Blog: 
https://github.com/libmir/blog


Re: D future ...

2016-12-21 Thread Ilya Yaroshenko via Digitalmars-d

On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers 
wrote:

[...]


Bad news: without complete redesign of the language and turning 
into one more C++/CLI (where you have different kinds of 
pointers in the language for GC and non-GC), having C 
performance and Go-style low-pause GC is not really possible. 
You have to choose one. Go chose GC with short pauses but paid 
with slow speed overall and slow C interop. D chose C-level 
performance but paid for it with a slow GC.


If this is true, a blog post about it with more details is very 
welcome --Ilya


Re: D future ...

2016-12-21 Thread thedeemon via Digitalmars-d

On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:
What I really want is what C++ wanted to deliver but it 
doesn't. I want something better than writing C but with the 
same performance as C and the ability to interface with C 
without the performance loss and with easily composable 
libraries.


D in my opinion in some ways is close to these goals. It's 
simpler to understand and write than C++. It has the problem of 
being a GC'd language however and it's unclear to me if the GC 
in D is evolving like the Go GC is. ...


The things I really want from D to really sway me would be the 
following (some already exist):

1. Evolve the GC like Go has.
2. No overhead calling C libraries.
...


Bad news: without complete redesign of the language and turning 
into one more C++/CLI (where you have different kinds of pointers 
in the language for GC and non-GC), having C performance and 
Go-style low-pause GC is not really possible. You have to choose 
one. Go chose GC with short pauses but paid with slow speed 
overall and slow C interop. D chose C-level performance but paid 
for it with a slow GC.


Re: D future ...

2016-12-21 Thread ikod via Digitalmars-d

On Wednesday, 21 December 2016 at 09:35:31 UTC, Andrey wrote:

On Wednesday, 21 December 2016 at 07:47:08 UTC, O-N-S wrote:

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
I split this from the "Re: A betterC modular standard 
library?" topic because my response is will be too much 
off-topic but the whole thread is irking me the wrong way. I 
see some of the same argument coming up all the time, with a 
level of frequency.




Five stars of five!

Regards, Ozan


Read all branche of topic. See ability to make social research.

Age'meter)))

Andrei,Walter > 45;
Benjiro,Dicebot 20-27;
others - difficult to say right now; need more time;

don't want to upset anyone, just a joke )))


How do you use language is more important than your age. 
Scientist or AI developer expect highest performance for 
number-crunching and don't care about fast and easy 
development/deployment/etc. Devops (like me) don't care about 
super-performance, but care about easy development (read - 
libraries availabilty, easy debugging, etc) and deployment, 
gamedev probably care about GC and I don't know what else. 
Language core team can choose to care about every or only about 
some specific categories of developers.


And one note on volunteer model of language development - it have 
obvious pro and contra. how much this "contra" affect language 
progress depends on the language creators and community goals.




Re: D future ...

2016-12-21 Thread Andrey via Digitalmars-d

On Wednesday, 21 December 2016 at 07:47:08 UTC, O-N-S wrote:

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
I split this from the "Re: A betterC modular standard 
library?" topic because my response is will be too much 
off-topic but the whole thread is irking me the wrong way. I 
see some of the same argument coming up all the time, with a 
level of frequency.




Five stars of five!

Regards, Ozan


Read all branche of topic. See ability to make social research.

Age'meter)))

Andrei,Walter > 45;
Benjiro,Dicebot 20-27;
others - difficult to say right now; need more time;

don't want to upset anyone, just a joke )))


Re: D future ...

2016-12-20 Thread O-N-S via Digitalmars-d

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
I split this from the "Re: A betterC modular standard library?" 
topic because my response is will be too much off-topic but the 
whole thread is irking me the wrong way. I see some of the same 
argument coming up all the time, with a level of frequency.




Five stars of five!

Regards, Ozan


  1   2   3   >