Re: D future ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
Something is going on with your newsreader client. It's replies break the thread.
Re: D future ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
> 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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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
