Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote: On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote: [...] Yes, I'm the typical lazy convenient Windows user scared of the terminal window. [...] I am happy for Posix users. Theoretically the process is the same on Windows. [...] This will need Linux subsystem as a Windows feature installed. Bash scripts do not work on Windows. Or other third party applications that are not listed as prerequisites on wiki. [...] make -fwin32.mak release Error: don't know how to make 'release' Ok, let's skip this, make it without "release". Now test it: cd test make all -j8 Command error: undefined switch '-j8' Why are you adding -j8 ? Does it say to do so in the instructions ? Try without it. (I can't test here as typing from my phone).
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote: On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote: On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote: And personally, depending on the problem, C# is better to program in than D. I still don't know why C# programmers are willing to give up C# and prefer to use D. C# is vastly surperior for what it does. Because, even the language creators seem to not recognize this, D looks like C# with *native compilation*, the syntax is 95% identical. Basically, if my source code doesn't use any .NET framework function, it will compile successfully with dmd without any (major) change. I suppose that every C# programmer is enthusiastic on the first contact with the D language, but fails to keep his enthusiasm when he sees Phobos. C# programmer's mind is locked in the OOP world and Phobos looks like a mess from his point of view. The problem is that D stagnates and in the same time C# evolves. Sometimes I feel like the C# language team is using D as inspiration for the new features, starting with C# 7.0, a lot of D concepts were introduced in the language: local functions, '_' as digit separator, binary literals, ref returns, tuples, templates, immutability. Guess what the next version of C# has on the table: slices. In the same time, D delegates new features (and sometime existing ones) to library implementation, instead of assume them in the language syntax. My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly. It's a good thing not bad that other languages are inspired by what works. Languages aren't in a vicious battle to the death, a Hobbesian war of all against all. If C# gets better, that's great! I don't think D is stagnating at all - on the contrary, it's amazing to see the ecosystem flourishing, no matter where you look - documentation, adoption, libraries, commercial adoption. I think it's reasonable to disagree with the strategic decision made to move capabilities from compiler to libraries. But you really have to make an argument about why you disagree if you are you expect to be persuasive because there is a thought-through argument for the choices made, which I am sure you must be familiar with. I don't think it matters much whether you are right about what happens to C# programmer interest in D dies as soon as C# native cross-platform is ready because D is quite an ambitious language and doesn't need to depend on adoption from any one community to continue growing at an impressive rate. As it happens though, as an empirical matter I doubt it. C# slices look great. I wanted to use them for generating wrappers for our analytics. Not that easy for that purpose, from what I could see. Looks like the primitives are stack only, and I tried to figure out how to use them elsewhere and gave up because it wasn't that easy. If Phobos looks like a mess to C# programmers, so much the worse for C# programmers. However I doubt they this is true in the general case. It's better in many ways, but different and unfamiliar and everything unfamiliar is disconcerting in the beginning.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. Funnily enough, becoming a significant contributor to the ecosystem - compiler or Phobos - demonstrably does not require even a complete graduation from high school or any industrial programming experience. I know of what I speak, but I don't say who as it's not for me to say. I was in Munich over new year and I asked someone else who has been a star contributor how he got involved. It was really easy for him to start contributing, so he did. But different people find different things easy. You don't need to have subsystem for Linux to use bash. Just the standard git client for Windows is enough. I agree the Windows experience could be easier upfront. Still, it's better than it used to be and next year it will be better again. You can't really compare the C# ecosystem to the D ecosystem because they are organised around different principles. Yes, the pain is upfront with D, and it's not for everyone. However on the basis of rational calculation the pain in learning something new is a small part of the total cost of the technology choice and for some people by far not the most relevant question. And it's an advantage in hiring because the D community filters for people who have a tolerance for discomfort upfront. It would be wonderful to be able to wave a wand and make all of life's little frustrations disappear. But in my experience, that's not what is possible - one picks from the choices available and the new ones one thinks up. People have a tendency to think that leadership has more power to just change things then is actually the case. I'm going to be building standard developer images from scratch programmatically. Transform froma Windows ISO into a VM image.Maybe I could open source those scripts and then it's easier to get to the bottom of any install and build problems and one can replicate difficulties.
Re: Question over C++ to D conversion
On Monday, 12 March 2018 at 01:10:41 UTC, Richard wrote: The second is that mbed uses C++ class's for it's API most of this is just headers such I was wondering if there are any other ways that are known about for translating C++ into D, or accessing C++ libraries. Many Thanks Richard See Gooberman fork of binderoo. It only worked on Windows and X Box before, but now it should work on Linux. That's for C++ talking to D. C# to follow. For conversion of C headers, watch this space. C first, C++ eventually. Might be a talk at Dconf on it. Also see the tool in Visual D, which I haven't yet used myself.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote: It would be nice if you could actually just copy-n-paste a C header into an extern(C) block in D and have it Just Work(tm), but practically all C headers are dependent on macros one way or another that it would require including an entire C processor inside the D compiler, which is not exactly an inviting proposition. Watch this space...
Re: Which language futures make D overcompicated?
On Friday, 9 February 2018 at 19:01:30 UTC, H. S. Teoh wrote: If somebody *paid* me to work on dub, then perhaps I will. But right now, my level of motivation and interest in doing so is pretty low, and is on the losing side of the competition against the myriad other projects that I could be working on. T I've paid John Colvin in the past out of my own pocket to work on dub. Some of our pull requests were accepted, some are stuck in the queue. We have too much to do currently for core people to work on it, but if there are things that would make a difference for us and others we could explore sponsoring further development. If we could make a list of what needs doing that is interesting to you to fix and order of magnitude how long things might take, I could consider that. I think you have my email. Laeeth
Re: Quora: Why hasn't D started to replace C++?
On Thursday, 8 February 2018 at 00:09:47 UTC, Ali wrote: On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu wrote: https://www.quora.com/Why-hasnt-D-started-to-replace-C++ Andrei my modest opinion about this D currently is a small player, that have an attractive proposition for some * it is like C++ (that is close to the power of C++) but simpler * it have some unique advanced feature related to meta programming D's best hope is to be a bigger player, it is unrealistic to replace c++ Any improvement made to D will help make it a bigger player And while some D features can be better advertised (like Design by Contract, DbC is a big deal, and few other languages are know to have it) I think D need to constantly add features, the idea that D is big enough, or that it needs more idioms rather than features, is in my opinion wrong D need to constantly add features, because all of it competitions are constantly adding features As D add features, it may have a breakthrough, at some point Maybe features help, but there's also just a natural process of maturation that we don't notice because it happens slowly. In 2014 when I started using D it wasn't unusual for the compilers to segfault. And since I didn't know D, or even modern compilers, their flags etc (beyond a bit of work in visual studio in the late 90s, I mostly learnt to program C on 8 bit CP/M, which was a bit different then),it was quite a confusing experience. I couldn't have recommended D to somebody else then. The documentation also was not very accessible to people who didn't think formally and were used to Python material. I tried working with one chap, a trader who knew a bit of python and he was absolutely terrified of the D documentation. The situation there is also rather better today. Then again, how can I trust the compiler. It means something that Liran at Weka said they haven't had any data corruption bugs, because data on they scale tends to find problems and bring them to the fore. From what I have seen, big changes, much more than is generally appreciated are often not a consequence only of one big causal factor, but lots of little things aligned and coming together. However if you want a big thing just consider growth in data set sizes and storage capacity and related that to trends in processor power and memory speed. Guido says python is fast enough because you are bottlenecked on I/O and network. But in my office I have a test infiniband network where the 40 Gbps switch cost about 600 quid (that's old technology now). NVMe drives do pretty decent throughput. Json parsing is not the cleverest thing one can do with data but how does that compare with the throughput from just a couple of nvme drives? And according to the ACM a fundamental assumption that held true since the dawn of computing is in the process of being overturned. With storage class memory and newer network technology (there's a road map to get to 1Tbps) the bottleneck from here isnt storage or network - it's CPU. I guess that won't hurt the adoption of D. Not tomorrow, but slowly over time.
Re: Quora: Why hasn't D started to replace C++?
On Wednesday, 7 February 2018 at 21:02:11 UTC, data pulverizer wrote: On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu wrote: https://www.quora.com/Why-hasnt-D-started-to-replace-C++ Andrei The Betamax Problem When you introduce something new, how do you know that it is going to be compelling enough for people to move from whatever it is they are doing and use your new thing? It is not an easy question to answer but in the realm of programming languages it's a very tough question, because people are going to have to learn a whole new language, and its going to come with costs and potentially unquantifiable risks for any company that attempts to shift to that language. So whatever it is you are offering has to be tremendously compelling compared to what is already there. A great deal of confusion in the world arises from failing to make distinctions between things that appear to be the same but really aren't when you look closely. Also, in about 1870 odd there was a revolution in economic thought that took place more or less simultaneously in Vienna, Lausanne and Cambridge. The Marginal Revolution had yet to be fully digested in the way people think about social phenomena. My director of studies at Cambridge, Lord Eatwell, Labour spokesman in the House of Lords, was known for his devotion to the work of Pierro Sraffa, a man known principally for a rather hostile book review of a book by Hayek and a rather slim book of his own, Production of Commodities by Means of Commodities, a book that tried to draw insights about the economy from a model with two goods, corn and gold. And I think considering firms as homogeneous, with the same cultural values and facing the same situation will be about as insightful as I think Sraffa's work ended up being - not very. Life is risk. It's risky to get out of bed in the morning, but it's also risky not to get out of bed. And it's true that an agent acting on behalf of someone else - ie a manager who has no stake in the business - will often think about things first in terms of not taking a decision that might lead him to be blamed. But most firms are not large enterprises, and in the US small and medium sized firms over time create more than 100% of job growth, last I checked. And a manager who is also at least to some extent a principal ie an owner in the business knows that to be conservative in a time of change is not necessarily prudent, and it may well also not be the profit maximising choice. As someone who is both a manager and a part owner I disagree that a new technology choice needs to be overwhelmingly compelling to be considered. And I don't get paid to make decisions about things that are easily quantifiable - what for you need me for if the numbers are straightforward? The reality is that firms are very different, in a dynamic industry even within the same sector they are different. And at any one time there are a bunch of people close to trying D or more. You don't need to persuade everyone to grow. You just need to persuade a few more people to tip over the margin. And there are often plenty of safe ways to take risks. You just need to make sure you have a plan B. Listen to Manu's talk for a real example of what I mean. And note that he said Finns are very conservative. An important question is what problem set does D solve? It's very hard to sell a language to industry without convincingly answering that question. If you are selling them a 'better' language - that's a tougher sell. If you are selling a solution to a particular problem set - you stand better a chance. But really who is selling D to anyone? We are very far from that stage right now. Did someone sell D to Microsoft COM team, Remedy or to Weka? Nope. People who had earned the authority to decide became aware of the language end decided to use it. And they did so because for them it solved their particular problems better then anything else they could think of. For a manager to consider D as the successor to C++, it doesn't just have to be a better language design than C++, it has to have the best language design of any compiled language and demonstrate the best performance. Why? Best in what way? Best for whom and for what kind of problems? I completely disagree with that. It needs just to be better in the situation then the conceivable alternatives. And situations and challenges are really quite different between firms. Is the former really true? Are various language features that have been inherited from C++/Java the best way forward? For instance does D have the best approach to object oriented programming, or templates? Or any important set of features you care to mention? Are there things that C++ does better than D? How straightforward is it to get great performance from D? Is how do you 'tune' your D code for high performance obvious or well
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: You want to produce Excel's? Excel-d but it faces the same issue as being the only native project. What if the author ... Since you mention this, there isn't just single author of excel-d. If something happened to me, most likely Atila would want to and continue to be paid to work on it. If Atila decided he wanted to work from an office and write modern C++ instead of D (approximately snowball hell survival chance), we would certainly have someone else take over. And Ilya Yaroshenko understands at least enough of it to have made pull requests (and I imagine he understands it all rather well, but limiting myself to saying what I am certain of). It's also not rocket science, the Excel API, and Microsoft can't afford to move quickly and break the API given their user base. What is D even targeting? You’re attributing an intent and plan to a decentralised open source project. It doesn't work like that. It's like saying who should Britain target in trading post Brexit. There's no central plan, because in Britain we don't have central planning that much for such things. Who we end up trading with will be the result of many dispersed decisions made by people acting on the basis of local knowledge. Well at least our Prime Minister can pretend that she is directing things in that way. Andrei and Walter can't order anyone to do anything, for the most part. They have significant influence, and can attract people to work on things but I don't see why you think there is a central plan for D. These categories you mention, they don't capture real world organising principles from what I've seen. When you don't have an enormous market share it's pretty easy to grow it. You don't need to have a high appeal to everyone. You just have to have a high enough appeal to just incrementally more people wherever they may be found. So it's not relevant whether most C++ developers are receptive to D or not (Ethan Watson says the games industry is an industry in search of salvation... from C++, and if every thing were hunky dory why the excitement about Jai, for example). You don't need to appeal to most people to grow, just a few more. Read the Innovators Dilemma if you are serious about understanding how this works. " It feels like D does not even know who its targeting." How can it? Why should it? At this point all that's necessary is to do more of what's working, which is something that's happening with the passage of time. The way to grow is to appeal a bit more to your best customers or to those who are really close, using your for some things but are held back by some small impediments. For example Remedy Games with Quantum Break. "In my opinion the focus seems to be with C++ developers with most not giving a darn about D." If most C++ developers were deeply familiar with D, it would be a very different conversation. Since this isn't the case, and given the number of people using C++, it's an advantage not a disadvantage what you point out. The job of an innovative challenger is long term an easier one. And strategically its by far the best if you get no respect until the last minute when it's too late for the challenger to respond. Strategically you want a growing number of people to be finding D useful, but most people to be dismissive. That happens to get the case though it was never planned. Maybe D isn't for you right now. That's okay - come back in a bit and maybe you will feel differently. It doesn't need to appeal to everyone. Other languages have slogans, they have selling points. Yeah, and some people don't like slogans and aren't influenced by them or find them irritating. The unpolished aspect of the D world isn't a bad thing in this respect. When i hear D, you hear ... ... ... ... Advantages: D has a lot of advantages like CTFE, Generics, betterC etc over Go. But the resources seem to be spread so much over so much code, that information about how to properly use those Technics is spread thin. I skipped C++ because I didn't find it appealing when I learnt to program as a boy, and my career took me in a different direction. I picked up programming again in Dec 2013 after a very long break, and I didn't know what generics were (sort of, but I had never written them), the only metaprogramming I had done was in a Forth clone I wrote in the 80s, and so on. But if wasn't difficult to pick things up with D,and the documentation was worse then. I agree it could still be better, and better organised, but it's not that bad. It makes D its learning curve also much higher. Really? I found D easier to learn than Python (to be fair I already knew C well). I started out writing it like C and progressively adopted language features. I learnt from Stefan Koch and Adam Ruppe when they were helping me before, and I still learn from John
Re: An idea for commercial support for D
On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote: This is an idea I've been kicking around for a while, and given the need for commercial support for D, would perhaps work well here. [...] By the way, in case you are interested in this path personally still, I'd be willing to pay for D support, tuition, help with getting stuck, code review etc for colleagues. Not for patches that aren't immediately open sourced, but we fixed windows paths on DMD for example, and there might be scope for occasional paid work on dmd and dub like that. Also porting headers.
Re: How programmers transition between languages
On Tuesday, 30 January 2018 at 09:20:37 UTC, aberba wrote: On Sunday, 28 January 2018 at 18:54:34 UTC, Laeeth Isharc wrote: On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote: I do worry that, having been using D for about 3 1/2 years now, that the perceptions of D outside of this community don't seem to be changing much. It does seem to make a huge difference to have a big company behind a language, purely for the "free advertisement". Most people at my university, outside of the computer science department, that are using languages like Python and R and MATLAB the most, are very aware of Rust and Go, but not D. I wonder if we do need to pay more attention to attracting new users just to get people talking about it. That's what you would expect, because D is a very ambitious language, which means its natural user base is much more spread out and less highly concentrated. And beyond that, most code is enterprise code that's closed source, and whilst the web guys talk a lot and influence the culture, enterprise guys talk much less and just do their thing quietly. Even in our world, how often do you see the people using D get involved in forum discussions? Sociomantic, Weka, Ebay, and so on. (Or Microsoft - did you know that D was used in their COM team? They didn't exactly send out a press release...) A little bit, but only a little in relation to their use of the language. If you're trying to accomplish something in a representative enterprise context with lean resources, you don't have much time to talk about what you are doing. That's one big potential mistake. Enterprises care about making money with whatever will help them do that (impress investors). Its developers who care about languages that help them write code that suites their requirements. The focus should be on developers not companies. People using D cannot be represented by Microsoft, Sociomantic, Weka, etc. employees. Its of no use chasing after companies... make it useful and everyone else will come. Who said anything about chasing after companies? There's not much chasing after anyone, companies or developers. One reason the quality of people here is so high. We have a filter that fortuitously selects for people with good taste and who don't care about superficial things as much. Learning costs and discomfort are amortised, and from an expected value perspective are trivial from a long run perspective. And I suggest it's almost a negative cost because one is forced to learn things that are good to learn. I speak very personally when I say this, because the value to me of what I have learnt is beyond calculation, and let's say that it is a very big number by the standards of the industry. And I don't accept the distinction between developers and companies particularly for small and medium sized companies. Liran at Weka, I'd call him a pretty serious developer, no? But he is also a co-founder and leader of his company. The Sociomantic guys - that goes without saying. Bastiaan same story. I don't know what role the technical leadership of Funkwerk play in running the company, but that was I think a decision adopted at a senior level - they have been using D for a decade and their product is everywhere. The train you took doesn't say timetable powered by D, but maybe in some years it will, haha. An interesting looking stock chart by the way. EMSI - founder developers adopted D. Personally I'm in charge of tech for a 95 person company and involved in other areas of management beyond tech and I'm also a developer. Every language is based on different principles. The way D will be adopted is via people who are principals giving it a try because it solves their problems. There is no point trying to spend much time appealing to those in management who can't make decisions themselves and need to consider social factors because we have a much better product than we do marketing. That's okay, the social appeal will come later and in truth when it does it will be a mixed blessing because the quality of the community will change. If you want to draw people to the language (and, honestly, I wonder why it matters so much to many here Its a simple math well understood since long ago. The larger the army/workforce the better. Things get done. Walter always say here "Its left with someone to do the work". There other stuff he doesn't address including those outside language internals. Sure, but you are I think mistaking ends for means. Things develop at their own pace and I don't think can be forced. I've noticed that changes tend to happen when they are good and ready and not when we wish they would. So in that context it makes sense to focus on what you can control and influence and not on what one wishes might be the case. If wishes were horses beggars would ride. But they don't... So that doesn't mean that one shouldn't work on
Re: How programmers transition between languages
On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote: I do worry that, having been using D for about 3 1/2 years now, that the perceptions of D outside of this community don't seem to be changing much. It does seem to make a huge difference to have a big company behind a language, purely for the "free advertisement". Most people at my university, outside of the computer science department, that are using languages like Python and R and MATLAB the most, are very aware of Rust and Go, but not D. I wonder if we do need to pay more attention to attracting new users just to get people talking about it. That's what you would expect, because D is a very ambitious language, which means its natural user base is much more spread out and less highly concentrated. And beyond that, most code is enterprise code that's closed source, and whilst the web guys talk a lot and influence the culture, enterprise guys talk much less and just do their thing quietly. Even in our world, how often do you see the people using D get involved in forum discussions? Sociomantic, Weka, Ebay, and so on. (Or Microsoft - did you know that D was used in their COM team? They didn't exactly send out a press release...) A little bit, but only a little in relation to their use of the language. If you're trying to accomplish something in a representative enterprise context with lean resources, you don't have much time to talk about what you are doing. If you want to draw people to the language (and, honestly, I wonder why it matters so much to many here - it's clearly taking hold, has momentum and will continue to grow for decades; an acorn will become an oak tree, and fretting about how much it's grown in the past year might be missing the point, so long as it's healthy enough), why not just focus on both improving the language itself (pull requests, documentation) and on accomplishing something useful and worth doing with it? Of course there are the usual trolls who don't seem to write much D, but seem to be drawn like vampires to the energy of those who do. Sad. On Sunday, 28 January 2018 at 17:23:12 UTC, Paulo Pinto wrote: This has been mentioned multiple times, D really needs some kind of killer application. Why? It's a generalist language for getting stuff done in an age where people have succumbed so much to Stockholm Syndrome that they think it's a positive thing in a language that you can only use it to do something special. Yet trends in performance and performance demands point to the rising importance of efficiency (and I suspect there will be a return to the recognition of the importance of being a generalist - in programming, as in other fields). There was a tweet by the author of Musl libc observing that software today runs slower than software twenty years ago, and linking the bloat to the insane pressure to maximise CPU performance over all else. The era of that kind of ruthless optimization is over because it's not the only thing that matters, and we start to see the price of it. And generalism - in a dynamic business environment, there's considerable value to have capabilities that aren't adapted to particular narrow skills when what you need is always changing and may be unknown even to you. My generation was privileged because very quickly if you wanted to get anything interesting done you had to learn assembly language (maybe write your own assembler or disassembler), had to learn a bit about hardware, and could never pretend the CPU was this perfect platonic abstraction. And for a while that changed, but I think the past is returning again, as it often does. So I see a value in hiring hacker / generalist types who can figure things out. For example: https://hackaday.com/2017/01/26/a-personal-fight-against-the-modern-laptop/ https://www.youtube.com/watch?v=Fzmm87oVQ6c Back in 2007, most finance types would have said how completely impracticable and unreasonable. But I say, with GK Chesterton, that "all progress depends on the unreasonable man". And someone like that doesn't succumb to helplessness once they are outside of their shiny IDE, knows that in the end everything is just code, and you can change it if you want to, and there is strategic value from building organisational capabilities from hiring such people. Usually I'm a couple of years ahead, and I think others will follow. If you hold a contrarian point of view, you know you're right when surprises start coming in your direction, and people still can't see it. And I think that's been the case since 2014. Anyway - so D is a general purpose language, and I think we are likely seeing a nascent return in recognizing the value of generalist tools and people. On my line of work having Go on the skills list is slowly becoming a requirement, due to Docker and Kubernetes adoption on cloud infrastructures. That's great. Walter says that good code should
C++ function mangling Linux GCC
Am I missing something, or should extern(C++) just work for
binding to gcc C++ on Linux. It works fine for primitives but
fails for pointer type arguments. Extern "C" works fine.
Does D know how to mangle function names based on pointer types?
I have created matching types on both sides.
Though I am using typedefs. Eg struct Foo_; typedef struct Foo_
Foo; and on D side struct Foo {}
Could that be why?
What the best way to see the types of library file function
arguments for a libfoo.a file on Linux? Sorry for the dumb
question.
Thanks.
Laeeth
Re: __traits(documentation, X)
On Wednesday, 17 January 2018 at 02:19:11 UTC, Seb wrote: What ``` /// my fancy string enum documentedEnum = 1; enum funcDoc = __traits(documentation, documentedFunc); assert(funcDoc == "my fancy string") ``` See https://github.com/dlang/dmd/pull/6872 for better examples Status --- The naive implementation leads to a small, but noticeable increase of DMD's compilation time. Andrei's words: I'd say keep it on the back burner until we find a couple of good ideas for using it. Discussing it in the forum may help. So do you have a good use cases for this? If this is a useful feature, the implementation can be improved to be zero-cost for normal runs. Post here or at https://github.com/dlang/dmd/pull/6872 In my case might be useful for generating foreign doc strings for automatically generated wrappers in other languages and for D functions intended for use directly but also mounted into an interpreted DSL.. You could duplicate docstring with attributes but hardly pretty.
Re: C++ Interop
On Saturday, 6 January 2018 at 11:17:56 UTC, Seb wrote: On Friday, 5 January 2018 at 13:02:12 UTC, qznc wrote: I'm exploring [0] C++ interop after watching Walter's presentation [1]. [...] I know about this: https://github.com/Remedy-Entertainment/binderoo https://github.com/dlang/druntime/pull/1802 Binderoo currently is Windows only. I am talking to Ethan about extending it to work on Linux too. Let me know if any other features helpful to add (no promises, but we can see).
Re: Any free stock market data API?
On Thursday, 4 January 2018 at 23:04:44 UTC, Amorphorious wrote: Most are in other languages: https://www.alphavantage.co/ https://iextrading.com/ are two free ones. I'm just hoping for a more D'ish solution. I wrote a simple api for quandl.com and somewhere I have one for yahoo. Neither being used right now so might have broken. https://github.com/Laeeth/d-quandl/blob/master/quandl.d
Re: What do you want to see for a mature DLang?
On Saturday, 30 December 2017 at 03:07:57 UTC, IM wrote: On Friday, 29 December 2017 at 17:29:47 UTC, Adam D. Ruppe wrote: On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote: -- Better compiler errors, better compiler errors, better compiler errors. This is the only thing I greatly care about anymore. Biggest problem D has in real world use. Please allow me to give an example of how first impressions of maturity really matter! Recently at some company, a group of engineers started advocating for using Rust. They wrote a doc explaining the differences and benefits of Rust over C++ (which is heavily used). People started experimenting, and immediately the maturity and good user experience of rustc and cargo were quite obvious. The result was that Rust is now more appealing, some new projects were written in Rust, some old ones have or are being migrated from C++ to Rust. (**This is a real story by the way**) Now, given the fact that I love D despite some of the annoying issues I encounter with it frequently, I would like to call my colleagues to give it a try and experiment with it. People start getting interested. They start writing some code, and eventually they hit one of those unhelpful compile error messages, which could indicate one of the following: - An error in the engineer's knowledge of the language which the compiler didn't help to understand what it is so that s/he goes to look it up. - A bug in Phobos. - An actual compiler bug or inconsistency. Remember, those engineers are experimenting with D to use it for serious projects at work, not personal toy projects. What do you think? Is it likely that they decide to invest a lot of time and resources migrating projects to D? Looking forward to seeing more of that in the compiler, which is the single most important thing in a programming language, the reason it exists, the thing I interface with most of the time. Remember, those engineers are experimenting with D to use it for serious projects at work, not personal toy projects. What do you think? Is it likely that they decide to invest a lot of time and resources migrating projects to D? Then probably you did the right thing in not suggesting they move to using D at work at the current time. There are all kinds of coordination costs in adopting D immediately for serious projects where the people involved don't know the language yet and where the benefits of D don't seem compelling at this point. It's much better if the people involved start using D on the side for things that aren't mission critical or that don't have a tight deadline, unless D solves a particular sort of problem you have or theres much receptivity to it. I don't think D is at a point where it should be sold. People need to be receptive and ready to move towards you. And they need to be able to take decisions on the basis of intrinsic merits and not have to consider social factors. They means that the natural sphere of adoption is startups run by creative and independent minded people, smaller firms and small groups within large firms where people have autonomy. That's really quite okay - in the US, more than 100% of new jobs are created by smaller firms. Its a mistake to use a language you don't know for a mission critical project with a tight deadline, unless it solves so many problems that it is worth the inevitable teething problems. Doing so is a recipe for brittleness because it's hard to anticipate any difficulties and hard to plan for them. D naturally is spread much thinner than many other languages because it's more ambitious and is useful for many different domains, so if you're in a particular one of them then you will know many fewer people using D then would be the case for languages that are more adapted for particular domains. Also, there's much difference in how much people in different areas tend to talk about what they are doing. Web guys talk a lot; finance guys not do much. The people I have met who use D at work mostly don't develop open source stuff at work and they don't post all that much in the forums. We are rewriting our core analytics used across the firm (about 95 people) to D. Why? Because they need to be accessible from other languages so C ABI is necessary and it's not even a contest, D vs C++. And the person in charge of that project is a Fellow in Maths at Cambridge, and the one helping him is also a Cambridge mathematician so they realise how important beauty is in taming complexity, and D does exceptionally well on that front. We can then programmatically generate wrappers for other languages and we can connect the analytics and some micro services with a little domain specific language written using pegged. So it's highly unusual sets of people like that, or like the founders of Sociomantic, or like the EMSI guys, or Liran's guys at Weka that are likely to be D adopters in the
Re: How do you use D?
On Thursday, 4 January 2018 at 15:52:15 UTC, Andre Pany wrote: On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote: [...] I am working for a german software company. There are various programming languages used. I created several non customer facing tools in D for the projects I am involved. Also I tried to make advertisements for the D Programming Language by creating internal wiki pages, recordings, video channel with screencams and telling everyone about that nice programming language called D. [...] Very interesting. Have a look at pegged and the work done by Bastian who has also been building a pascal parser - for a different dialect.
Re: D downloads
On Saturday, 30 December 2017 at 00:14:45 UTC, codephantom wrote: On Saturday, 23 December 2017 at 21:04:52 UTC, Laeeth Isharc wrote: http://erdani.com/d/downloads.daily.png Bad data, one off spike, or something else? https://successfulsoftware.net/2015/05/14/the-mystery-of-the-chinese-downloads/ Maybe we should produce two charts, one filtering out Chinese IPs
Re: D downloads
On Thursday, 28 December 2017 at 22:02:16 UTC, Walter Bright wrote: On 12/24/2017 7:33 AM, Laeeth Isharc wrote: (The first person to receive Bitcoin was Hal Finney, a prominent member of both the extropians and cypherpunks lists). Hal was in the dorm room next to mine when I was a freshman. He was one of the smartest people I've ever known, by a wide margin. Also one of the nicest. I've always suspected Hal of being Satoshi :-) A grand joke like that is something he'd do. Some people reasonably well placed to have an idea think he was part of the group mind that Satoshi became... I dug out the archives recently for both mailing lists. Amazing the high level of discussion back then, and how those fringe ideas became mainstream. It took a while though!
Re: structs inheriting from and implementing interfaces
On Friday, 29 December 2017 at 12:59:21 UTC, rjframe wrote:
On Fri, 29 Dec 2017 12:39:25 +, Nicholas Wilson wrote:
On Friday, 29 December 2017 at 12:03:59 UTC, Mike Franklin
wrote:
The problem is that interfaces are a runtime thing (e.g. you
can cast a
class to an interface)
structs implement compile time interfaces via template duck
typing
(usually enforced via an if()).
you could probably write a wrapper that introspected an
interface and
enforced that all members were implemented.
I've actually thought about doing this to get rid of a bunch of
if qualifiers in my function declarations. `static interface
{}` compiles but doesn't [currently] seem to mean anything to
the compiler, but could be a hint to the programmer that
nothing will directly implement it; it's a compile-time
interface. This would provide a more generic way of doing stuff
like `isInputRange`, etc.
Atila does something like this
https://code.dlang.org/packages/concepts
Re: Maybe D is right about GC after all !
On Thursday, 28 December 2017 at 00:36:32 UTC, Dan partelly wrote: On Wednesday, 27 December 2017 at 22:36:08 UTC, Walter Bright wrote: On 12/27/2017 8:57 AM, Laeeth Isharc wrote: It's much better to have a monopoly of some niche or set of niches and to use energy from success to expand out from there, than to have a small market share of an enormous market. Back in the 80's, Zortech made a killing because we had the only C++ compiler that would generate 16 bit Windows code. I found this out by asking the sales guys what feature of ZTC++ was closing the deal - X, Y, Z, all the features I held dear. They'd say nope. Customers wanted to use C++ for Win16, ZTC++ supported that, sold! I learned a lot from that. That a product which fulfils a need in a total void sells? No disrespect, but aint it a bit tautological ? Can you find a similar void today which is to be filled by D ? Better yet can you create one ? Read Peter Thiel's Zero To One, and maybe Walter's point will become clear. If you don't want to read it, that's fine too, but it's hard to have a discussion if someone isn't familiar with the background of how challengers very often tend to succeed and isn't interested to learn about it. Yes, evidently enough people using D believe it fills a need. See list of companies using D. Most of them have better things to do than post in the forum however. From my point of view, D already has a monopoly, as I don't see an alternative that's in the same league for what I want to do. I'm not going to spell out all the reasons here. By far the best thing if you want to form an assessment of the language for your own needs is to watch a bunch of dconf videos, read the bits of Phobos that appeal to you, read lots of other D code and start trying to solve your own problems. I don't think it's a language suitable for everyone, but I do think most people for whom it's suitable today will quickly get why if they take some of those steps I suggested...
Re: D as a betterC a game changer ?
On Thursday, 28 December 2017 at 02:21:09 UTC, Dan Partelly wrote: On Thursday, 28 December 2017 at 01:09:34 UTC, codephantom wrote: But honestly, the best way to learn about a programming language, is to start using it. Sure , **if** you decide it worth to be learned. And honestly, almost everybody knows that to get better at a task you must perform the task itself. So I ask you...what have you written in D lately? My problem currently is that I have no freaking idea what niche D serves, since as I said I perceive multiple personalities in it. I like a lot in the language, but I do not like that I perceive it as a indecisive language. This is one of the reasons I asked Walter in this thread what is the future of the language ? Where does it to go ? No clear answer yet. It's a practical language for getting stuff done in a way thats plastic, efficient, powerful. So I think the ecological niche is restricted mostly by capabilities of the people using it (it wasn't designed as golang was as a restricted and simple language for people who have limited experience, though I personally found it easy enough to learn), by the tolerance people have for discomfort upfront, by the ability to pay upfront costs in wrapping any necessary libraries, by the ability to pick your own tools rather than needing to persuade others first. It's not as polished as more mature languages. It has fewer targets, so for example it doesn't yet have a production ready ARM 64 or web assembly target, and if you run it on Alpine Linux, FreeBSD or SmartOS it will probably work but you might have some work to do yourself. Embedded targets will need you to do work. If it's super important not to use the GC probably you will have some work to do. If you work with younger people who expect Python style docs and an abundance of Stack Overflow answers you may have some work to do there. Beyond that, it's pretty good for many things,from scripting to applications to numerical code, to systems programming. That's really the point. It's also especially good as glue because of ctfe and compile time reflection. Pegged and other parser generators mean that it's a pretty nice language for writing DSLs in.
Re: D as a betterC a game changer ?
On Wednesday, 27 December 2017 at 18:23:37 UTC, Dan Partelly wrote: On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder wrote: It is all about differentiation. Forget competing against C, C++, and Rust. D is the C++ inspired language with GC that isn't Go. So what I hear is: if D wants a future embrace one personality only. Given current state of affairs, it should compete against the like of Java, C# and Eiffel. Embrace GC and forget anything like better C and competing against zero cost abstraction languages. For this to happen D must focus all its energy on implementation of a second to none GC. This of course , has both sense and sensibility, but given that D has been unable to commit to one personality in it's life-spawn, how likely is to happen ? Walter, what says you ? Where do you actually want to go with D ? What you and D foundation wants, not Russel or I or whatever else ? 'Competition is for losers', according to Peter Thiel. It's completely the wrong mindset to succeed in a free society. What you're supposed to do is create a monopoly that you earn and keep earning every day. Economic quasi-rent, or pure profit, is the reward for noticing ways to better organise resources to serve customers needs in a way that others have overlooked. (See the work of Israel Kirzner and Schumpeter). D shouldn't compete against anything any more than it has tried to compete in the past. The way to success is to listen to people who like what you are doing anyway and would like you to develop along the path of development that already exists and maybe are willing to encourage that in some way. [Of course stealing useful ideas that fit what you are doing is always good, patent and IP law permitting]. If you do that, it becomes a ridiculous question to ask 'how are you differentiated from other languages; what is your edge?' because it's obvious to anyone with eyes and the willingness to study a bit what that is. In my view, this is also good career advice I have taken myself and that I have found personally to be profitable, as well as the right way for a language to develop. And it's what Walter has done anyway based on his long experience in flourishing as a one-man band in a market where Microsoft - with its very large resources - was then the dominant player. People also continue to think and write as if the D Foundation has this inexhaustible fund of resources (pecuniary and people) that it can command to work on whatever Andrei and Walter think best. It's open source! It doesn't work like that. If you want people to work on something, write a proof of concept and talk about it. Talking to the aether about what people ought to be doing will be less effective than finding one guy who agrees with you and working on the project together. And if not working on it yourself, then organising a fund and making an initial contribution towards a prize for someone who will. And if one isn't willing either to work on something oneself, or to contribute financially towards its development, just how likely is it you will persuade somebody else to do the work in a community of highly intelligent, spirited, and independent-minded people?
Re: Maybe D is right about GC after all !
On Sunday, 24 December 2017 at 21:27:12 UTC, Russel Winder wrote: On Sun, 2017-12-24 at 16:58 +, Laeeth Isharc via Digitalmars-d wrote: Programming languages are tools for solving problems, and people face different problems and they also have different capabilities and tastes, which means even for people facing identical problems, the right tool for the job may not be the same because they aren't identical as groups and as individuals. Thinking of a programming language as a domain specific language for solving problems in a domain helps with this. Along with can a language enable creation of a DSL for solving my problems. Creating functions is creating a DSL in any language. That's an extremely odd way to conceive of D, IMO, like conceiving of a banana as being like an apple, only it tastes like a banana and has a different shape. If a general purpose programming language is to be conceived of as a domain specific language, what's the difference between a true domain specific language and a regular programming language? That's really the whole point about D. It's an era where people start out assuming that using the right tool for the job means that one tool can't do two different kinds of job well. But, as Walter has said elsewhere I think, in some cases that's because the tools people are used to using are limited, whereas in fact there's no need for that - just use one tool that's good at both. It's going to be a struggle to recognise such a tool if you start with the presumption it cannot exist. And talking about languages as identical with DSLs only encourages this misconception, I think. How does prestige develop? From tangible consequences produced by able and virtuous people acting together to create something. There's a long lead time on that one, but it's not something that can be rushed. And sales and marketing. Arguably C was the last language that got traction based solely on technical benefit and tribalism. All other languages with traction since have had serious marketing behind them. I don't think I suggested that tribalism in the everyday sense of the word is favourable to the adoption of a language. But that aside, C is quite a big example, and I don't see that it has no relevance to the present, even though conditions are of course different. Was Python adopted because of a big marketing budget? If so, I didn't know that - who paid for it? How about R? I think you also need to consider consequences of beliefs if you are wrong and the choices available in circumstances (unless you can figure out how to create new choices). You write as if adoption is flatlining. It isn't - it's growing at a healthy pace, as best I can see. Human perception doesn't deal very well with compound growth. It's disappointing for a long time, and all of a sudden it's surprising. It's by far best at this point to get across successful stories about the adoption of D to people who are already receptive to them because they have some problems that D might help with than to try to get people to listen to you who have no interest in listening. Persuasion works when people are ready to move towards you. You can't compel that.
Re: Maybe D is right about GC after all !
On Wednesday, 27 December 2017 at 16:53:16 UTC, Dan Partelly wrote: On Wednesday, 27 December 2017 at 16:38:35 UTC, Laeeth Isharc wrote: A fair amount of D's design is based on psychology. I'd love to hear more about this sometime. I never thought of this in the context of programming languages, but behavior is strongly modulated genetically, epi-genetically, and ***environmentally** (this includes the social component). Japanese cars were dismissed and laughed at for the longest time. When the price of energy went bananas in the 1970s US auto makers were not laughing any more. (And strategically it would have been terrible for the Japanese if US manufacturers had taken them seriously earlier). So big relative price shocks have something to do with adoption. https://www.quora.com/Python-programming-language-1/Why-is-Python-so-popular-despite-being-so-slow/answer/Laeeth-Isharc https://queue.acm.org/detail.cfm?id=2874238 "For the entire careers of most practicing computer scientists, a fundamental observation has consistently held true: CPUs are significantly more performant and more expensive than I/O devices. The fact that CPUs can process data at extremely high rates, while simultaneously servicing multiple I/O devices, has had a sweeping impact on the design of both hardware and software for systems of all sizes, for pretty much as long as we've been building them. ***This assumption, however, is in the process of being completely invalidated.*** "
Re: Maybe D is right about GC after all !
On Sunday, 24 December 2017 at 20:58:51 UTC, Russel Winder wrote: On Sun, 2017-12-24 at 17:13 +, Laeeth Isharc via Digitalmars-d wrote: […] New things grow at the fringes. See the work of Clayton Christensen and his book the Innovator's Dilemma. A head-on assault is ill-advised. People looking for salvation are easier to talk to than those who don't see anything wrong with what they're doing currently. Not my experience in the JVM-related community, and to an extent the Python community, at least in the UK. Head on collisions create debate, and get you remembered. The debate generally leads to change, even if not the change initially envisaged. At least the status quo gets perturbed. Just dealing with the fringes and solving their problems rarely get serious traction. cf. Golo, Gosu, Fantom, Crystal, Pony, all of which solve definite problems but none of which have any serious traction to move programming on. It's much better to have a monopoly of some niche or set of niches and to use energy from success to expand out from there, than to have a small market share of an enormous market. And niche in this case is not something simple - it's people who have a certain set of kinds of problems and certain capabilities and who have the ability to make decisions on merits for them rather than primarily social factors. See Peter Thiel's Zero to One for another expression of the same point. From a strategic perspective, it's by far better for the challenger not to be taken seriously for the longest possible time until the moment is ripe, if it's possible to achieve that. It takes a long time for a programming language to be adopted. And the more ambitious the language, perhaps the longer it takes to mature and the longer it will be for it to achieve wide adoption. D is a pretty ambitious language! I can appreciate that if one's business involves teaching people a language then this is frustrating. But I'd suggest taking a step back and looking at things from the point of view of the language itself, which is an organic creature not wholly under the control of its creators. (See node.js).
Re: Maybe D is right about GC after all !
On Wednesday, 27 December 2017 at 16:44:25 UTC, Laeeth Isharc wrote: On Wednesday, 27 December 2017 at 16:29:02 UTC, Russel Winder wrote: On Wed, 2017-12-27 at 02:13 -0800, Walter Bright via Digitalmars-d wrote: […] Builtin unittests and Ddoc, for example. There's a big psychological advantage to having them built in rather than requiring an external tool. The closeness to C syntax is no accident, for another. I've been in the compiler biz since the early 80s, working with customers, doing tech support. That results in experience in what works for people and what doesn't, even if it is not scientific or better from a CS point of view. This does not support the original claim that the design of D by you is based on psychology. It may be based on your perception of other programmers needs, which is fine per se, but that is not psychology- based design. That's like saying the way George Soros trades is not based on psychology because he doesn't refer to the literature in making and articulating his decision-making process. Instead people write papers about how he thinks, because it's not yet in the literature! If published knowledge were what was most important or valuable then anyone intelligent with an interest in a subject would be part of a war of all against all, because how is it possible to have an edge? But I don't think human expertise can be described in that manner. Karl Polanyi's work is quite interesting: https://en.wikipedia.org/wiki/Tacit_knowledge On Soros: http://marketfocusing.com/downloads/soros.pdf
Re: Maybe D is right about GC after all !
On Wednesday, 27 December 2017 at 16:29:02 UTC, Russel Winder wrote: On Wed, 2017-12-27 at 02:13 -0800, Walter Bright via Digitalmars-d wrote: […] Builtin unittests and Ddoc, for example. There's a big psychological advantage to having them built in rather than requiring an external tool. The closeness to C syntax is no accident, for another. I've been in the compiler biz since the early 80s, working with customers, doing tech support. That results in experience in what works for people and what doesn't, even if it is not scientific or better from a CS point of view. This does not support the original claim that the design of D by you is based on psychology. It may be based on your perception of other programmers needs, which is fine per se, but that is not psychology- based design. That's like saying the way George Soros trades is not based on psychology because he doesn't refer to the literature in making and articulating his decision-making process. Instead people write papers about how he thinks, because it's not yet in the literature! If published knowledge were what was most important or valuable then anyone intelligent with an interest in a subject would be part of a war of all against all, because how is it possible to have an edge? But I don't think human expertise can be described in that manner. Karl Polanyi's work is quite interesting: https://en.wikipedia.org/wiki/Tacit_knowledge
Re: Maybe D is right about GC after all !
On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright wrote: On 12/26/2017 4:18 AM, Russel Winder wrote: All of which brings us full circle: when it comes to programming languages and software development, it is all about advocacy, prejudice, and belief, there is very, very little science happening – and most of the science that is happening is in the psychology of programming, about which most developers of programming languages know nothing. If you're hinting that I know nothing about the topic, you're mistaken :-) A fair amount of D's design is based on psychology. I'd love to hear more about this sometime. I think that's what people who assess languages based on checklists miss - it's the gestalt of the features and how they are organised and the consequence of this for the pattern of the code as it emerges, rather than particular tickbox features that's appealing. (I agree with code phantom that an adaptation to how people chunk is one of those benefits).
Re: Maybe D is right about GC after all !
On Sunday, 24 December 2017 at 17:08:26 UTC, Russel Winder wrote: On Sun, 2017-12-24 at 16:51 +, Patrick Schluter via Digitalmars-d wrote: […] The big issues with Java and C# are the required infrastructure for deployment. They could be the best languages since sliced bread, they would still be annoying to deploy as the runtime is an emulator. I ported 1 app from Java to D. It was so unspectacular (or better said it was spectacularly easy) that you're probably right. Reaching to Java devs is a good idea. The advantage of Java though, is not the language but the huge, huge, huge existing libraries and packages and know how. This will be difficult to overcome for any language. But unless people submit proposals showing how D beats Java in direct competition, the JVM focused people will never know. Take DevoxxUK and JAXLondon the two primary JVM-related conferences in London. No mention of Go or Rust, let alone D. Single language conferences are tools for retaining people within the language, ditto programs such as Java Champions. New things grow at the fringes. See the work of Clayton Christensen and his book the Innovator's Dilemma. A head-on assault is ill-advised. People looking for salvation are easier to talk to than those who don't see anything wrong with what they're doing currently.
Re: Maybe D is right about GC after all !
Programming languages are tools for solving problems, and people face different problems and they also have different capabilities and tastes, which means even for people facing identical problems, the right tool for the job may not be the same because they aren't identical as groups and as individuals. Languages are also about much more than syntax; they are also about communities, ecosystems, and values. In the beginning people generally join a community because they admire the values and capabilities of those prominent in the community. Prestige often has a lot to do with that. How does prestige develop? From tangible consequences produced by able and virtuous people acting together to create something. There's a long lead time on that one, but it's not something that can be rushed. It's also hard to begin something - much energy poured in for no tangible result. You love your creation, but for a long time indeed it does not love you back. However once it ignites then things take on a momentum of their own. It's almost impossible to believe because you're expecting it to be difficult, like usual, and somehow things just almost magically start to unfold in that direction without your having to do that much. On Sunday, 24 December 2017 at 15:00:09 UTC, Dylan Graham wrote: How much further does D have to go to start snatching C++'s userbase? That's already happening, surely. Here there are lots of former C++ programmers, or professional C++ programmers who write D on the side. Andy Smith gave a talk about use of D in the automated trading systems at a financial company - I won't say who it is, but it's a very well-known firm that's well established and in the top handful of hedge funds. We're a newer fund (established in 2014, we were the largest Asian hedge fund startup), but we're starting to explore the use of D, and one project where we are moving to D was originally written in C++. It forms the basis of our analytics across the firm. And I didn't need to sell it because when someone is suffering they are looking for salvation, which is what D represents. Before, we had C++ analytics (and for each one the implementation and a header file). Then a C++ to C# shim. Then a C# to C++ low-level shim. Then a high level C# wrapper. Then an Excel function wrapper written in C#. Now you want me to add a new function??? And a new trader starts who would like to access the analytics from Python. Oh, and it would also be nice to have the analytics accessible from R, Java, Julia and Matlab. Conceptually, there are other ways to get to the same result. But practically for us we decided to rewrite the analytics in D and generate code at compile-time to wrap the functions to make them accessible from other languages (for native code ABI, with other language wrapping being generated at a combination of compile and run-time). It's by far a cleaner and easier-to-read solution. And it doesn't need selling to anyone, because it's an upfront cost that pays dividends for years not just on current code but all the new code that will be written in time. D has unit-testing and documentation generation built in, and as far as the community goes, there's an expectation that you use these! Wrapping for Excel is largely done (excel-d) and I've got something basic that can be used for Java if you are relaxed about efficiency (which we mostly are for that use case). We're working on C#. For Python we could easily use PyD (which we have now fixed to work also on 64 bit Windows), but we will try going via generating Cython as it's a bit cleaner. There's still more work to do, but it's a much better solution. And I think that's how D will be adopted. People who have problems, for which using D is in part the solution. And decision-makers who are acting as principals not agents, so that they can act without having to spend a huge investment on addressing social factors (there are always social factors, but it's a matter of proportion). Liran at Weka didn't have to ask someone to decide to use a new language he had never used before for a startup building complex code that had to just work. He had earned the right to decide, and there's plenty of risk in a startup anyway, and I suppose his investors trusted his judgment. Similarly, Remedy Games had a problem, and from his account of it, Manu was not entirely serious when he suggested why don't we use D for scripting, but the group was receptive, and they didn't need to make a presentation to the board to act. Andy Smith was in a position where he could 'build a prototype' in D, and then decide it wasn't necessary after all to rewrite in C++. Of course recognition that D can be helpful won't happen all by itself. It's worth doing the work to spread awareness, as we are. But if people agree, then I think talking about success stories, warts and all, is likely to be
Re: D downloads
On Sunday, 24 December 2017 at 12:25:49 UTC, Guillaume Piolat wrote: On Saturday, 23 December 2017 at 21:04:52 UTC, Laeeth Isharc wrote: http://erdani.com/d/downloads.daily.png Bad data, one off spike, or something else? Perdon my skepticism, but there is a higher chance that a new web crawler is downloading DMD multiple times - that isn't filtered out by the script - rather than users being suddenly three times as many. We don't know until we study the data (which should be simple to do if someone is curious and has access to it). Social phenomena are very strange, much stranger than economists and other students of social data recognise. I looked at that chart recently, and thought explosive. I didn't expect to see that kind of spike. (It's supposed to be a 28-day moving average - is that right?) In a market that spikes due to noise trades it's not that uncommon for it to head there for real a little while later in a less ephemeral way... Maybe non-traded social phenomena are completely different, but they might be more similar to market phenomena than people think. So, yes, the spike is probably in part noise but look at the broader context. People are not very good at understanding at a deep level the implications of compound growth, sustained over time. I didn't get involved with D because I thought it would become popular, but I've been saying since 2014 that language advocates are pushing at an open door because external conditions are changing in the direction where what D offers becomes more useful to a wider audience. William Gibson had a character observe that the future is already here, just unevenly distributed. And I think that's the case with adoption of D (the problems that early adopters face, and that recognise they face, for which D is a good and practical answer for them will become more prevalent over time). Digicash was launched in 1989. The cypherpunks list began in 1992. I remember reading a message by Tim May a few months after the list began setting out the reasons why cryptocurrency would succeed, and he was obviously right. But it took a very long time for it to gain traction. (The first person to receive Bitcoin was Hal Finney, a prominent member of both the extropians and cypherpunks lists). One could have reasonably said for many years 'cryptocurrency hasn't taken off, so it won't'. But that's not how social phenomena develop. They build slowly in the beginning, and there are certain thresholds of perception that need to be surpassed for a broader audience to start to get it. And things only break out into the world when external conditions are ripe - but those earlier years are very important for the thing to reach a level of maturity and refinement that simply could not have been possible had popularity been achieved earlier. It's not true that there are no jobs in D - we are hiring at least four people (depending on the people likely to be working at least partly in D), as are others - but maybe it was important for the development of the language that in the beginning there weren't jobs. Because the only people that were involved were those that were intrinsically motivated, and that's important to get to technical excellence... Laeeth.
Re: excel-d v0.2.16 - now with more @Async
On Friday, 22 December 2017 at 22:08:23 UTC, Mengu wrote: On Friday, 22 December 2017 at 00:41:31 UTC, Atila Neves wrote: excel-d lets you write plain D code that can be run from Excel unmodified via the magic of compile-time reflection. [...] can we use excel-d with office for mac? I don't think so but I am not familiar with the Excel API on Mac so it's possible not too many changes required. Pull requests welcomed :)
D downloads
http://erdani.com/d/downloads.daily.png Bad data, one off spike, or something else?
Re: (Possibly paid opportunity): PyD - Win 64
On Saturday, 2 December 2017 at 09:12:07 UTC, Thomas Mader wrote: On Friday, 1 December 2017 at 13:30:21 UTC, Laeeth Isharc wrote: Hi. I'd like to get PyD working on Windows 64. I think it's probably just a simple linking / library problem, but don't have time to work on it myself right now. If somebody would be interested in helping, we could pay for help on this. laeeth at kaleidic.io Thanks. Laeeth. Just found https://github.com/ariovistus/pyd/issues/67 Thanks. I didn't try yet but reckon Nic is right - just something small.
(Possibly paid opportunity): PyD - Win 64
Hi. I'd like to get PyD working on Windows 64. I think it's probably just a simple linking / library problem, but don't have time to work on it myself right now. If somebody would be interested in helping, we could pay for help on this. laeeth at kaleidic.io Thanks. Laeeth.
ESR on post-C landscape
He mentions D, a bit dismissively. http://esr.ibiblio.org/?p=7724=1#comment-1912717
Re: D for microservices
On Monday, 23 October 2017 at 12:08:52 UTC, Jacob Carlborg wrote: On 2017-10-22 04:48, Joakim wrote: I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux: "For now everything works(?) but I think the process could be improved.. Would be really cool to have LDC easily building alpine containers + static D binaries for microservice and tooling development. I'm pretty tired of reading Go code :)" https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550 It strikes me that microservices are a great way for new programming languages like D to get tried and gain some uptake, but that D might not be that easy to deploy to that scenario yet. So this is a question for those deploying microservices, as I'm not in that field, what can the D devs do to make it as easy as possible to get D microservices up and running, make some Docker and Alpine containers with ldc/dub/vibe.d preinstalled publicly available? What else, what kinds of libraries do you normally use? This is a niche that D and all newer languages should target. How do we do it? * Support full static linking using DMD, which requires the TLS implementation to be modified * Support musl as the standard C library, I've discussed that before [1] * Database drivers for the common databases (PostgreSQL, MySQL, SQLite) compatible with vibe.d * Database driver abstraction on top of the above drivers, perhaps some lightweight ORM library * RabbitMQ library compatible with vibe.d * Serialization to/from JSON and YAML * Official Docker images with DMD and LDC wouldn't hurt * Pre-compiled DMD that works on Alpine. Fully statically linked DMD would help here That's what I can think of for now. [1] http://forum.dlang.org/post/nhem1l$1ee3$1...@digitalmars.com Can you elaborate on how the TLS implementation needs to be changed? If someone wanted to work on rabbit bindings/wrapper, I might be open to sponsoring that. I'm not in love with Rabbit (one node uses more than 40% of memory so the node goes down, taking the cluster with it. really?), but we use it currently. I made a start on bindings for librabbitmq here: https://github.com/kaleidicassociates/rabbitmq-d Laeeth.
Re: My first experience as a D Newbie
On Saturday, 21 October 2017 at 09:51:41 UTC, Mark wrote: On Saturday, 21 October 2017 at 01:45:40 UTC, codephantom wrote: The real challenge (and ultimate goal) for any open-source project (especially a volunteer based one), is finding equilibria. Honestly, I do not believe that an open-source project, beyond a certain scale, can sustain itself without a consistent income stream. The Foundation has gone from zero to something. That's the hardest part. Over time I'm sure its revenue will grow.
Re: D for microservices
On Sunday, 22 October 2017 at 02:48:57 UTC, Joakim wrote: I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux: "For now everything works(?) but I think the process could be improved.. Would be really cool to have LDC easily building alpine containers + static D binaries for microservice and tooling development. I'm pretty tired of reading Go code :)" https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550 It strikes me that microservices are a great way for new programming languages like D to get tried and gain some uptake, but that D might not be that easy to deploy to that scenario yet. So this is a question for those deploying microservices, as I'm not in that field, what can the D devs do to make it as easy as possible to get D microservices up and running, make some Docker and Alpine containers with ldc/dub/vibe.d preinstalled publicly available? What else, what kinds of libraries do you normally use? This is a niche that D and all newer languages should target. How do we do it? We're going a bit in that direction, although it's a different thing in our kind of industry from a web company - we have fewer services and many fewer requests, but latency matters more for example. I was thinking we might use Go for some services that integrate and monitor things, but we could also use D. https://jobs.github.com/positions/8e98eac8-b504-11e7-9da8-0737a3dcef18 From the comment: "Would be really cool to have LDC easily building alpine containers + static D binaries" How can we generate a static binary ? I asked about this before, and the response was that it's a bad idea because of security vulns and so on. True if you are running on a conventional Linux host. But on the other hand, it's not that great if when the system phobos is upgraded all the D binaries break. You can write a script using rdmd or dub scripting feature, but that doesn't work for more complex programs. And on the other hand, for deployment, it's much easier to copy over one binary. (In a sense it's funny that the question was asked in the context of containers, because containers are kind of an alternative to having a single binary). When you're properly set-up of course it doesn't matter, but when you're moving towards that, a single binary is much easier. I guess I can figure out the answer to this question easily enough, but I think giving people the option might help with adoption of D for micro services. For example it's really just not that fun to make an AWS Lambda using D - being able to easily build a static binary would make the process much more pleasant. I wrote this up a while back: http://awslambda-d.readthedocs.io/en/latest/ "Since dmd links phobos dynamically on linux, and phobos/druntime aren't installed on the AWS lambda server, we will need to upload these to the servers and tell the application where to find them. (I should really have appended to LD_LIBRARY_PATH as I did with PATH). Now one can follow the regular instructions for AWS Lambda: create a .zip file with the D binary, the JS file, and the following libraries (update version numbers as appropriate): libcrypto.so.1.0.0 libphobos2.so.0.67 libevent-2.0.so.5 libssl.so.1.0.0 " Alpine is nice - would be good to have this as a standard target in time. Laeeth.
Re: My two cents
On Friday, 20 October 2017 at 15:38:53 UTC, Martin Nowak wrote: Commercial usage, shared libraries and stuff There isn't any handy tool to download, manage and publish closed source stuff. dub is great for simple solutions but useless in big projects with multiple targets, configurations, etc. Everything is primary focused on opensource development (but everyone here wants to see D as a next successor of C++ in commercial sphere). Well, dub is a package manager to share code, so obviously OSS it the main target. You can easily `dub add-local` packages or run your private registry. https://github.com/dlang/dub/pull/985 "A common use-case (that I currently have) is a large project with many dub packages in it, which much be registered with dub, but don't have any purpose outside that project. It also allows any dependencies to be easily packaged inside a project in order to allow building an application without an internet connection, by just running dub upgrade --root=$APP_PROJECT_DIR --defaultRepoPath=$PROJECT_ROOT/deps/ on the dev machine, then dub build --root=$APP_PROJECT_DIR --defaultRepoPath=$PROJECT_ROOT/deps/ --skip-registry=all on the target machine." We've submitted a PR for our internal dub fork that we use to build a decent-sized project (not as big as Weka, but not much smaller). Sadly it required quite a few changes and was hard to break into bite-sized ones. If you're working on a big internal project, I'd say that it's worth thinking about things from a medium-term perspective. With D you have higher costs to get the build system etc right, but you gain and keep gaining from having more concise, clearer, more maintainable, and more plastic code. The costs are front-loaded though. If one's able to take a medium-term perspective and the changes you want to see in dub are not all that much, it may well be worth finding someone in the D community you can pay to help make those changes. A little money goes a long way because here you have strong programmers - who like programming! - from all over the world, and not everyone is in a situation that makes their opportunity cost as high as what it might be within the company (not just payroll, but overheads, co-ordination costs etc). And you may find other commercial users are willing to split the costs - that's something a large media company asked me about, and that we would be open to also if it's something that will fit with what we need. And of course there are various other options like Make, CMake, Meson, or Raggae. (Reggae). We use Reggae for building proprietary codebase. If there's a feature missing, please do say - maybe we would benefit from it, and since Atila works with us, it's something easy to consider when time. As unfortunately with almost any OSS project, we're not that many people, and each of us is investing a huge amount of time into this. Also - for example with dub. Dub and vibe constitute an amazing achievement for one man. I don't mean to diminish the contribution of others, but I guess Sonke has been the creative spirit behind them and has done most of the work. There's one challenge that arises when you can benefit from the work of unusually productive people (of whom there seem to be many in the D community - I just take Sonke as one example), is that for that same reason they end up getting responsibility in the commercial parts of their lives, which might mean less time available to devote to open-source at certain points. There are 39 pull requests open on dub currently. It's not a super-complicated code base, but I guess the people responsible for dub have quite a lot on their plates. I don't know how others might be able to help, but maybe that is one area that would benefit the language ecosystem more generally. (I get the impression sometimes that people want to help, but they don't completely know how). There's no mention of dub here, for example: https://wiki.dlang.org/Get_involved Now there is.. (I just added it). https://wiki.dlang.org/Get_involved#Review_pull_requests But again your best bet on getting sth. done is working on it, be it writing a DIP, organizing the discussion, or actually implementing it. Bountysource went quiet, though I started contributing to it. I wonder if there is a better way for commercial users to say what they might be willing to pay for and how much. I don't think that keeping patches private for a while really fits. It doesn't hurt me if some other D user benefits from work I sponsored. In fact it helps me if it is incorporated into the main codebase, because that means I don't need to worry about maintaining it. And that's in any case way too selfish a perspective - not smart commercially: if D flourishes, it helps us too. Laeeth.
Re: London senior DevOps job and two London [D-ish] developer roles
On Friday, 20 October 2017 at 09:11:17 UTC, Arjan wrote: On Thursday, 19 October 2017 at 20:01:20 UTC, Laeeth Isharc wrote: Hi. Symmetry Investments is looking to hire ... Please feel free to drop me a line if you're interested or know of someone who might be - for this role or for the others. How would one contact you? devops.hiring at symmetryinvestments.io
London senior DevOps job and two London [D-ish] developer roles
Hi. Symmetry Investments is looking to hire one senior platform engineering / devops person in London (and also looking for two developers - one for building native/Jupyter GUI front-end of tools, and the other to work with our research team). So far, I've only had time to write and post the job description for the devops role (I'll do the others shortly). You can see that one here: https://jobs.github.com/positions/8e98eac8-b504-11e7-9da8-0737a3dcef18 We would consider someone with less formal experience/seniority. Some stuff about the firm here: http://symmetryinvestments.com/about-us/ https://stackoverflow.com/jobs/companies/symmetry-investments Please feel free to drop me a line if you're interested or know of someone who might be - for this role or for the others. How much of this work can be in D? It very much depends on the person, and what's sensible for the job. Potentially quite a lot, probably not all of it. Thanks. Laeeth.
Re: My first experience as a D Newbie
On Thursday, 19 October 2017 at 01:32:14 UTC, codephantom wrote: The open-source community is mostly driven by 'volunteers'...who work on what they want to work on, when they have some spare time to work on it. I think too many people do not understand this, and so come in with bloated expectations. ... They go out of their way to make the 'installation and learning curve as smooth as possible'..for beginners! And they are responsible for setting those kind of expectations up in peoples minds..at the 'beginning'! This is not the mindset you want when you enter the open source community... I guess this is ok, if you're only every going to encounter commercial solutions when you go out into the real world...but the world has changed a lot..and you're actually more likely to encounter non-commercial, open source software these days. ... open source, and D too, did not come about as a result of C#/Windows/VS users being disappointed with their language and/or tooling ;-) +1 Although these days, it's not like the contribution of enterprises to open-source is nil. In 2013 (I didn't bother to find latest stats), 80% of contributions to the kernel were from developers employed to work on it. https://www.extremetech.com/computing/175919-who-actually-develops-linux-the-answer-might-surprise-you And of course commercial open-source software is a thing. When I started my career after university at SBC Warburg, banks outsourcing technology services was just beginning. And I read a study from a couple years back about the consequences of outsourcing - and it said that very often there was a one-shot reduction in cost, followed by an enduring loss in productivity growth. Why? Because it's very hard to improve things when you don't control the whole process and when you don't receive information from the environment by getting your hands dirty. And outsourcing and using tools that do everything for you automagically are somewhat similar in that respect. Of course it's worth automating what no human should be doing. But if one completely loses touch with the layer beneath, that comes at a high price. And when you've automated everything, you may also find that the remaining problems are beyond the ken of any living human to solve, particularly when that human no longer has the experience of solving the simpler problems that are now automated. http://queue.acm.org/detail.cfm?id=2841313 Developments in society move in cycles and waves. From the 1990s until recently, yes, it made sense to think about making things easy that should be easy. Today, we've lost a bit touch with the underlying reality, and as far as I can see the pendulum is swinging back a bit. I just hired someone to work on devops who liked the old ThinkPad keyboards and didn't like the new ones. But the old machines are now a bit dated, and yet there is no way to buy the new machines with a classic keyboard. So he tried plugging an old keyboard in and it didn't work, so he did what anyone normal would do. He reverse engineered the firmware and patched it - only to patch it he also had to reverse engineering the patching tool because it was signed. Some might say that this demonstrates nothing more than a lack of pragmatism and commercial orientation. But I don't think that's the case at all. It's an unreasonable stance to take, but one that's very sane indeed. GK Chesterton said that 'all progress comes from the unreasonable man'. And if you have this kind of attitude then you recognise that you can change things in your environment - one no longer has this feeling of learned helplessness the moment that it is necessary to do something that can't be easily accomplished from within Visual Studio. It's just code, after all. And we're in an age where some of the most significant commercial problems come from the dynamic business environment - where you end up having to do something you didn't plan for - and from the complexity created by layers of abstractions. So if you're adaptable and not afraid of understanding the things you depend on, and if they are themselves designed for you to take apart and understand, there's just a chance it may be one source of enduring commercial advantage...
Re: My first experience as a D Newbie
On Monday, 16 October 2017 at 08:56:21 UTC, Rion wrote: When you invest this time into a language, you have expectations. A person expects for a language this old, that every puzzle fits together without issue. I can't say that your process for forming expectations is wrong, but it's evidently not turned out to be a good guide to reality. It could be that reality should conform itself to your view of what it should be, but it might also be that D is a thing in itself that develops according to its own intrinsic pattern that is different from the one with which some people are most familiar with today. And if that's right, one can't evaluate it according to heuristics that fit other languages - one needs to think about what is the problem one faces, and from an enterprise value perspective how and where might D be useful. And if one isn't in a position where one can't think about it from an enterprise value perspective, it's going to be hard to use D at work. Call me spoiled if you want but quick gratification it is not. Yes - that's the whole point - it's certainly not a language community that as things stand today fits someone expecting quick gratification, especially on Windows. I don't see how it becomes one very soon. Expecting it to become what it is not might lead to disappointment. For some people, perhaps that's enough for them to look elsewhere - it very much depends on your discount rate, on your patience, how quickly you pick up technical things, and on the sorts of problems you face. Debates about languages are often really debates about values. And although one may explore differences in values in a rational way, that's really not something one is easily going to persuade anyone else of. Hey Javascript guys why not slow down a bit, focus on code quality, security, rigour, error reporting and so on. It's not going to happen. https://www.slideshare.net/bcantrill/platform-as-reflection-of-values-joyent-nodejs-and-beyond https://vimeo.com/230142234 The time wasted on dealing with issue on D, is time you can have spend in a different language actually writing code/testing. Its a barrier to the language its own success when its not as user friendly as the other languages. It's not the time spent sorting out build systems or writing code that is the truly expensive bit... In fact there are days when I wonder about imposing a tax on lines of code to make people write less of it. It might not be a positive factor, but empirically it's certainly not an overwhelming impediment to the continued growth of the language, because adoption is growing. If a person needs to do a action in Windows and it takes him 5 mouse clicks. But hey, under Linux you can do it with one command line arg, ... the Linux approach sound more easy right? Yes, to me I find it so - even Microsoft at a WinOps talk recently said that in the end the command-line is better for some things because a GUI hides things from you (I paraphrase). Of course for some people it's easier to use a mouse. But the command-line is certainly more powerful and if you're managing or deploying to even as few as tens or more of machines, it may often be the only way. Until you add the time needed to learn the command and assuming there are no issues. You only need to learn once. And it's my impression classic command line tools change much less often than GUI app interfaces. What is more rewarding or punishing? It very much depends on what sort of thing is more your cup of tea. People are evidently quite different in their tastes, and it's a good thing too. It's just not going to be very gratifying to go to coffee drinkers and ask why they don't appreciate the virtues of Earl Grey. Unless you enjoy the sort of reaction you'll get. Windows does not get in the way. I must beg to differ. MS puts a massive amount of time and money in there testing. And it shows in there platform. So if you prefer to use their platform, there is no point expecting D to reach a similar standard in the sheer glossiness of the appearance of tools, because time and money in the D community is spent in different ways because people using D have different problems and therefore different values. Personally I can't stand Visual Studio, but then again I don't write much for Windows. Its the same reason why Linux as a desktop OS will never work out. Too much puzzle pieces that do not fit, too much assumed that people need ( and have the time ) to learn the complicated way. A lack of inter-testing beyond just the basic compile tests ( i mean really usage ). Fair enough. I gather UNIX family has been quite successful on the desktop - the only real competitor to Windows, no? And some say easier to use. And GNU and UNIX derivatives dominate the mobile markets. Its easy to see the same attitude in D as a community project. There are GREAT pieces being written but
Re: D on quora ...
On Saturday, 14 October 2017 at 22:43:33 UTC, Adam Wilson wrote: On 10/7/17 14:08, Laeeth Isharc wrote: In a polyglot environment, D's code generation and introspection abilities might be quite valuable if it allows you to write core building blocks once and call them from other languages without too much boilerplate and bloat. One could use SWIG, but... Oh dear, I seem to have accidentally set off a firestorm. Personally, I think there are better places to focus our energy than worrying about what the users of other languages think. We like D, that should be enough for us. The last line was somewhat tongue-in-cheek. There is no way we're going to convert C#/Java users either, and unlike C/C++ we cannot easily inter-operate with them. If we can convert Pascal users, why won't some C# and Java programmers be receptive to D? Plenty of people have approached D from Java: https://dlang.org/blog/2017/09/06/the-evolution-of-the-accessors-library/ https://dlang.org/blog/2017/08/11/on-tilix-and-d-an-interview-with-gerald-nunn/ https://github.com/intellij-dlanguage/intellij-dlanguage/ (Kingsley came from Java). Why can't we easily interop with Java and C#? I didn't find interop with Java so bad for what I was doing (embedding a Java library via the JVM with callbacks to D code), and Andy Smith found similar. http://dconf.org/2015/talks/smith.pdf (towards the end) C# interop for what I am doing sees easy enough. (I will generate C# wrappers for D structs and functions/methods). This work wasn't open-sourced, and nor did Microsoft send out a press release about their use of D in the COM team. But I spoke to the author in Berlin (maybe you did too), and it wasn't so much work to make it useful: http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf Instead of worrying about how to get more people to come from a specific language. People will come if they see an advantage in D so lets try to provide as many advantages as possible. :) Yes - agree with this.
Re: D on quora ...
On Sunday, 15 October 2017 at 07:21:55 UTC, Ecstatic Coder wrote: But as a C++ developer, I can tell you that : D's GC is what prevents me to use it for my current C++ programming tasks. Because I can perfectly live with a GC that progressively collects bits of memory in a predefined amount of time, like in the Nim language, but not one that can pause my application for an unpredictable amount of time. That's just my personal case and opinion, but I don't think I'm the only C++ programmer on the planet to dislike D's GC for typical C++ development cases, which are generally those where the lack of a GC is the reason that lead to the use of C++. Out of curiosity, what is it that stops you keeping the heap small and allocating memory manually for the rest?
Re: My first experience as a D Newbie
On Friday, 13 October 2017 at 15:29:54 UTC, Rion wrote: I have probably put in a few hundred hours try to learn D and get going. And half that time was pure wasted on bugs, editor issues, frustration, hours looking up something that is so easy in other languages, ... Recently i was helping a developer who was benchmarking D+Vibe.d, on his OsX he never got parallel support to work ( error fault 11 ) for Vibe.d, resulting in vibe.d running single core and losing to Crystal and Rust big time ( single core tests ). I do not expect him to pick up D based upon those results. That was two developers trying to find the correct way to force vibe.d to work parallel on his system. Lets not count the hours lost for use both. So currently i am more then a bit salty about D again. Its always something left or right that just does not work properly. His response was Go simply works even if it was slower then D. I can state the same that despite Go its fault, it simply works, same with the editor support etc. And that is frankly bad advertisement for D. Now excuse me as i prepare for a long trip. Maybe its better to simply pick up Go again, then keep hitting my head against the wall. As i started this long blog, love and hate relationship with D. D is much less gratifying than other languages for most people. Just like Windows was more gratifying than Linux for most people in 2000. And I suppose that's likely to change slowly, but continue to be the case for a while so long as people working on Windows don't notice when something isn't working and fix things at root cause. It's usually not that much more difficult to do so than work around it, and it usually pays off even considered selfishly. I can appreciate your frustration, but considering how many years knowing a programming language can pay off for, a few hundred hours spent to learn something new isn't that much. That's like a couple of months full-time and if it works out the payback period should easily be a year. Viewed rationally, that's a pretty good return on investment compared to most other opportunities available. In a world where there are lots of smart people and knowledge is widely available, the barriers to opportunity (there must be barriers, otherwise the opportunity would be competed away) are often emotional ones. So I like things where the difficulty is front-loaded, because they tend to be neglected by modern people who are used to quick gratification. And whilst it surely can be frustrating, the situation is already better both on Windows and as regards documentation and tooling than it was in 2014. It's not difficult to make little changes towards what one would like to see oneself.
Re: My first experience as a D Newbie
On Friday, 13 October 2017 at 13:14:39 UTC, Steven Schveighoffer wrote: On 10/13/17 2:58 AM, Peter R wrote: Replying to a couple of the comments here "I don't know if it's a different expectation or a different mindset or something else." I'd like to think I'm fairly knowledgeable, but Yes, I expect installing/configuring to be easy and quick, so I can get to the actual programming. I expect solid debugging capabilities, full IDE support, autocomplete, and 64-bit windows libraries. It is just some of the things that I am used to with Visual C++. "Better than C++" is my motivation to evaluate D, and to me that goes beyond just the language and standard library. If I, as a new user, don't have a solid first impression, I'd have no expectation that the rest of the D ecosystem is polished, and I would return to C++ Thanks for replying. I did not mean my post as a slight against your knowledge, but really about my ignorance -- I don't know what the expectations of a Windows user are. I think the Windows users we do have on the core team (Walter being the main one) probably aren't typical Windows developers. But my experience seems to be most of the "I've tried to use D for 10 days and it sucks!" rants come from the Windows side, and they are mostly about installation and IDE woes. On my mac, I just do "dvm install 2.076.0" and I'm up and running. I think at some point, an actual company will pick up the maintenance of a good D IDE for windows, and will solve this problem. Unfortunately, we have to rely on volunteers right now, and that company hasn't materialized. One note about your requirements, auto-completion I think is something that I love about IDEs for other languages (I would be lost in xcode without it) and is something I've never used with D (all my attempts have been disasters). It's definitely something we need to improve the experience on. -Steve The Windows experience is less good. Not just IDEs, but even a simple thing like DMD paths. That's been broken ever since longer Windows paths became common (the code dates back to 1987), and it interacts badly with dub, which likes to make a relative path going back up to the root directory and then back down again. We have fixed that (Atila did the work) and will submit a pull request once we're happy it meets the right level of quality and have been using it a bit ourselves. But it's a nice illustration of the situation: on the one hand people are more inclined to expect things to just work on Windows (less inclined to get their hands dirty fixing them and to share the solution when they do), and on the other they are more likely to break and stay broken for a long time: https://github.com/kaleidicassociates/dmd/pulls (The above path thing is a problem for command line too). Then on top of that, there's the problem that the situation for installing native libraries on Windows has been completely insane, although it's starting to improve now. Most of the time on linux it's a single command to install a library. It's more of a blessing on Windows when that's possible, because it often isn't. And if your benchmark is other ecosystems that take care of installing the native C library for you, then D looks needlessly complicated. (Even though it's a C on Windows thing, not a D problem).
Re: Infuriating DUB/DMD build bug.
On Saturday, 7 October 2017 at 19:34:53 UTC, WhatMeForget wrote: On Friday, 6 October 2017 at 23:02:56 UTC, Laeeth Isharc wrote: On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote: I've got a github project and using DUB with DMD and I keep running into this problem. I've tried deleting the entire ...\AppData\Roaming\dub\packages folder, but the problem repeats the very next build attempt. [...] See my post in learn on dmd path. The dmd path code was written in 1987 and could do with an update to process longer windows paths properly. We are working on this and I guess a chance a pull request on Monday but it depends on what else comes up. In any case it's a trivial fix. Presuming I am right about it being a path length problem. I did! But i didn't say anything because i wasn't sure if they were related. I'm pretty sure it is path related because the exact same dub.sdl files work fine on Linux and MacOS. (It's a cross platform project) Glad it is a trivial fix. Curious what it involves. Let me know if I can help out in any way. Mike Parker was kind enough to show me a manual dub local workaround for this issue. But I'll hold off now and see if your change does the fix. If it does, it will be the best timed bug fix ever :) Turned out to be more fiddly than I hoped because of unicode. Atila did the work, but it's awaiting a pre-review to be sure it's okay before submitting. In case it's helpful in the meantime, it seems to work (but use at your own risk): https://github.com/kaleidicassociates/dmd/pull/1
Re: Fast removal of character
On Wednesday, 11 October 2017 at 22:22:43 UTC, Johan Engelen
wrote:
std.string.removechars is now deprecated.
https://dlang.org/changelog/2.075.0.html#pattern-deprecate
What is now the most efficient way to remove characters from a
string, if only one type of character needs to be removed?
```
// old
auto old(string s) {
return s.removechars(",").to!int;
}
// new?
auto newnew(string s) {
return s.filter!(a => a != ',').to!int;
}
```
cheers,
Johan
There's always this:
https://github.com/dlang/undeaD/blob/master/src/undead/string.d
Re: D on quora ...
On Sunday, 8 October 2017 at 04:23:50 UTC, Jerry wrote: On Saturday, 7 October 2017 at 06:19:01 UTC, Brad Roberts wrote: As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers. Luckily, that's how things tend to proceed here, so yay for that. Doesn't feel like that when the views of the people in charge don't align with what people are saying. I can understand people's dissatisfaction with Windows, but some people take it too far. The compiler for Windows is built using 32-bit, not only is the 64-bit version not built it's not even supported or tested. I think someone made a post a little while ago about LDC that 95% or more of downloads for their compiler were for the 64-bit version. If only one version is to be supported then it should be the 64-bit version. I can't even imagine the outrage there would be if 64-bit wasn't supported on Linux. Hell, they haven't even bothered setting up AppVeyor for dmd, free testing on Windows. Niche within a niche, can't expect much I guess. You know it's not that hard to be the change you wish to see in the world. That's really the whole point of open source, or at least of at least reasonably or more free software - you're not at the mercy of a paid vendor to whom you pay a fortune for the favour of them closing or otherwise creatively ignoring your tickets. You can pretty easily fix many problems and irritations yourself, and if you're too busy then one can pay someone to do it, and if one is busy and has no money to spend right now one can try to persuade someone to work on it. But if one just grumbles, probably the result will be just what anyone would expect. 64 bit command line build didn't seem to work for a while. That's been fixed recently, as I recall. One can't really compare Linux and Windows 32 and 64 bit. Those worlds work very differently. Windows is as it is because they are fanatical about maintaining backwards compatibility. So unless you run out of memory then 32 bit compiler isn't much of a restriction. And if you are doing so much ctfe that you run out of memory, chances are you can figure out how to build the 64 bit compiler on Windows! Try using digger - might work now that the 64 bit command line build works again. And failing that maybe file a request on bugzilla. And I don't know but I guess if you contribute something to the D Foundation, probably - because it's still quite new - it will be easier to get people to listen to a gentle request to have a downloadable 64 bit compiler. These things do cost money, and right now I think somebody is paying for that out of the goodness of their heart...
Re: Catching C++ Exceptions in D - Windows and Linux
On Tuesday, 12 September 2017 at 04:33:30 UTC, Nicholas Wilson wrote: On Tuesday, 12 September 2017 at 03:51:45 UTC, Laeeth Isharc wrote: Hi. I'm here in HK with Ilya, Atila, John Colvin, and Jonathan Davis. I wondered what the current state of D catching C++ exceptions was on Linux and Windows. I know that some work was done on making this possible, and my understanding is that it is, more or less - just wondered what the rough corners might be. Thanks. Laeeth. IIRC I remember Walter saying that we should only bother to be able to catch C++ exceptions derived from std::exception, as opposed to say ints or strings. I believe the line was "those who throw ints should get what they deserve". Apart from that I believe they should "just work", although I haven't tested. OT I'm sorry I could make it to HK, I'm busy with uni all this week. I could possibly do telepresence though. Nic Thanks, Nic. Sorry about the dates - was arranged last minute. I'll drop you a line shortly in any case. Laeeth.
Re: gdc is in
On Sunday, 8 October 2017 at 19:30:48 UTC, Ali Çehreli wrote: On 10/08/2017 10:49 AM, Jack Applegame wrote: On Sunday, 8 October 2017 at 08:38:15 UTC, Iain Buclaw wrote: Donating for the upkeep of our infrastructure is also welcome. ;-) How to do this? You can donate to the foundation: https://dlang.org/foundation.html This is the donation page: https://dlang.org/donate.html Ali Thanks, Ali. I guess in this case people might want to send an email what it's for, although it becomes a nuisance if everyone attaches strings to everything. It's very easy to set up a recurring donation btw.
Re: D on quora ...
On Saturday, 7 October 2017 at 20:44:44 UTC, Adam D. Ruppe wrote: On Saturday, 7 October 2017 at 20:36:24 UTC, Laeeth Isharc wrote: Would it make sense to have a BetterC version define for Phobos? Quite a lot of Phobos already works that way. blog post to enlighten the masses?
Re: D on quora ...
On 10/6/2017 10:19 PM, Adam Wilson via Digitalmars-d wrote: > What if we stop focusing on the C/C++ people so much? The > like their tools and have no perceivable interest in moving > away from them (Stockholm Syndrome much?). The arguments the > use are primarily meant as defensive ploys, because they > compare everything to C/C++ and when it doesn't match in > some way or another the other language must be deficient. > They've already decided that C/C++ is the meter stick > against which all other languages are to be judged. > Unsurprisingly, nothing that is NOT C/C++ meets their > exacting demands. Yes - as Andrei said in a talk, people are looking for an excuse not to have to take the time to learn something new. There's an inordinate strength of feeling in discussions in relation to D. If it's not your cup of tea, why do you care so much? The raising of spurious objections is much better than indifference at this point, and you can see this year that there has been a shift. People got downvoted for repeating the same old talking points that are now demonstrably not correct, whereas before it was a matter of judgement and people could reasonably differ. On Friday, October 06, 2017 23:19:01 Brad Roberts via Or recognize that painting huge diverse groups as if there's a single brush with which to do so is a huge fallacy. Consider that the two leaders, as well as a large number of the contributing developers, come from the c++ community and that's not a bad thing, but rather a big part of _why_ they came to D. As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers. Luckily, that's how things tend to proceed here, so yay for that. Long tail. We really couldn't care less about what most people think. In fact it's good that most people won't try D because what they will be expecting isn't yet what we offer (glossiness and hand-holding). At any one time there is a proportion of people who are unhappy with their existing choices and looking for something better. It's easy to grow in the early days - you don't need to appeal to most programmers. You just need to have a slightly stronger appeal to those who are already predisposed to like you (and to those who are already using your language and would like to use it for more things). And people conceive of the market in too small a way. People talk as if languages are in a battle to the death with each other - D can't succeed because it's too late, or because Rust has momentum. But the world is a very big place, and the set of people who talk much to a broad audience about what they are doing is a small one and thinking it reflects reality leads to distorted perceptions. Who would have thought that probably one of the larger code bases (500k SLOC) to be rewritten/converted in D might come from Pascal, with D competing with ADA? I don't know what has been decided there, but whatever the outcome, that's highly interesting, because it's probably true of others. Similarly Weka came from nowhere. A random tweet by Fowler led to them building their entire company on a language the founders hadn't used before. Because D is a highly ambitious language that isn't confined to a single domain, and that's a potential replacement in some domains for many other languages, most people won't know anyone who uses D because use is much more spread out. Enterprise users outside of web + big tech/startups don't talk about their choices that much. Microsoft didn't send out a press release when they used D in their COM team, for example - someone there just figured it was a good tool for the job and got on with it. Similarly the company that Andy Smith worked for (a money management company) didn't say anything, and it only happened that he talked about it because I suggested it and he happened to have time. Inordinately at this point in its development D is going to appeal to principals over agents, to people who have at least local authority to make decisions and don't have to persuade others, because the dynamics of how you persuade a committee are based on quite different things than making a decision and living or dying by how it turns out. That's okay. If people don't feel they can use D at work, they shouldn't. Some people will be able to, and as they have some success with it, others will start to imitate them. And in the meantime maybe it will be an advantage of sorts for the earlier adopters. It matters who your customers are, because that shapes what you become. And it's better early on to have people who make decisions on technical merits and who have the authority to do so, then to have a representative enterprise buyer! On Saturday, 7 October 2017 at 08:36:01 UTC, Jonathan M Davis wrote: Honestly, I've gotten to the point that I don't care much about trying to appeal to folks who complain about
Re: D on quora ...
On Saturday, 7 October 2017 at 09:37:12 UTC, Radu wrote: I think there is some merit criticizing D's GC. The major problem with it ATM is that there is no convenient way to use all (most) of D's std lib without it. This also extends to third party libs - most of them are coded with the GC in mind because of the above point. I guess a non-GC solution for throw new Exception will help with quite a lot. What to do about the rest (at least for Phobos)? - Allocators - right now they are in Phobos... This is not great, they should be split in 2 parts: core an druntime. One should be able to use a minimal set in betterC mode, and the full version with druntime (all GC related parts). Would it make sense to have a BetterC version define for Phobos? Or is this a terrible idea? So you could still use some subset of Phobos from BetterC mode, and maybe this subset could be expanded over time? And maybe people would write a complimentary set of functions to cover the missing most useful things in a way that doesn't depend on the runtime? It makes sense what you say about allocators - it would be nice to be able to write BetterC code using those. I used dscanner quickly to see what the imports are, and I wonder how much work it would be to do what you propose. core.atomic core.bitop core.exception core.internal.spinlock core.memory core.stdc.errno core.stdc.stdlib core.stdc.string core.sys.posix.pthread core.sys.posix.sys.mman core.sys.windows.unknwn core.sys.windows.windows core.thread std.algorithm.comparison std.algorithm.iteration std.algorithm.mutation std.algorithm.searching std.algorithm.sorting std.array std.c.stdlib std.c.string std.concurrency std.conv std.exceptionstd.file std.format std.internal.test.dummyrange std.math std.meta std.random std.range std.range.primitives std.stdio std.traits std.typecons
Re: D on quora ...
On Saturday, 7 October 2017 at 01:00:41 UTC, Jon Degenhardt wrote: On Friday, 6 October 2017 at 18:42:02 UTC, H. S. Teoh wrote: On Fri, Oct 06, 2017 at 06:09:58PM +, Ali via Digitalmars-d wrote: The reputation is D's GC is slow, and Manual Memory Management is fast The first point is valid (when are we going to get a better GC? :-/), but the second is questionable. Have there been studies quantifying the performance of D's GC relative to other GC implementations? My anecdotal experience is that D's GC can have undesirable latency behavior (long pauses), but throughput appears good. Of course, quantified metrics would be far preferable to anecdotal observations. --Jon Have you tried running the GC instrumentation on your tsv utilities? That might make for a very interesting blog post.
Re: Infuriating DUB/DMD build bug.
On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote: I've got a github project and using DUB with DMD and I keep running into this problem. I've tried deleting the entire ...\AppData\Roaming\dub\packages folder, but the problem repeats the very next build attempt. [...] See my post in learn on dmd path. The dmd path code was written in 1987 and could do with an update to process longer windows paths properly. We are working on this and I guess a chance a pull request on Monday but it depends on what else comes up. In any case it's a trivial fix. Presuming I am right about it being a path length problem.
Re: D on quora ...
On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote: Why is GC a problem? T -- Everybody talks about it, but nobody does anything about it! -- Mark Twain** Are you sure your quotes are randomly generated ?? Jonathan Davis wrote: "We don't want D's standard library to rely on the GC when it doesn't need to, but there are language features that require it and really couldn't work with it, and there are cases where it's going to be involved by default for @safety reasons." Perception is so important when people are making decisions about something they don't know. (As Walter says, you have to write tens of sloc in a language to really see it's benefits. They won't be so evident if you write D like the languages you know). So I think the GC series has been very helpful. But it might also be helpful to be very explicit on the functions that can and can't be called with nogc (I mean a top level overview in the docs) because it's one of the remaining sources of FUD that people say "yeah but you can't use large parts of the standard library without the GC". And for things that are useful and easiest done with GC it would be nice to have an alternative that doesn't depend on the GC - if for no other reason than to address objections. So the answer is then "yes - you're right, these X functions depend on the GC, but there are similar ones that don't". (Walter already started that for functions that use the GC for purely legacy reasons but I mean for more difficult cases too. I know Weka wrote their own versions of some std.algorithm functions for example). Many things aren't much work, but when you have a lot to do, even small frictions can have big consequences. So it's also a documentation question - it's not that easy from the outside last time I looked to see just how easy std.experimental.allocator is to use.
Re: dmd path handling is a bit dated
On Friday, 6 October 2017 at 20:11:25 UTC, Laeeth Isharc wrote: DMD path handling is a bit dated, and it's causing build I mean I imagine getcwd and tk/filespec.c might not be the only places that need updating, but I was going to start with those and see what happened.
dmd path handling is a bit dated
DMD path handling is a bit dated, and it's causing build problems for us because on Windows it's easy to end up breaking DMD's limit - particularly given how dub likes to turn everything into a relative path. Windows has so many beautiful example of the costs of legacy compat. I just wrote down 5 ways it handles paths, and then realised there's another. There's a 260 char limit (less a bit, depending) in the old Windows API, but looking at the ddmd code there's a more restrictive limit of 131 chars + null for windows when it builds paths for the base directory. I think if you use Windows 32 file namespaces (eg \?\C:\D\foo\bar, and note the difference from \?C\D\foo\bar ) and the unicode library calls then you get up to 32,767 chars. We already have much better code in Phobos (for Windows it's hard-coded at 4K) getcwd, and I think either we should call Phobos or copy/paste the Phobos function into ddmd. And I'm posting here because we can submit a pull request, but I didn't know whether to call Phobos or copy/paste as I haven't submitted more than trivial doc changes to compiler. I've written all of this up but on an internal gitlab. https://github.com/dlang/dmd/blob/2bf9a9d731e88ebd8a175bd0a990a3b651e8df82/src/ddmd/tk/filespec.c (c) 1986-1987 by NorthWest Software. It could do with an update! " So there's an obvious set of related problems. Line 119 - current working dir is 131 chars + null. and on linux it's restricted to 255+null (not sure if that limit applies anymore to linux, but who cares for now). getcwd prototype is defined here: https://github.com/dlang/dmd/blob/ebd6606840afea0034ce599815ed950fd558981c/src/ddmd/dmodule.d and this is the prototype: extern (C) char* getcwd(char* buffer, size_t maxlen); it's deprecated and replaced by the ISO function: https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/getcwd-wgetcwd okay - so: it's wrong to use that limit on linux and OSX. Linux PATH_MAX is 4096. OpenBSD is 1024. Linux paths are unlimited, apparently (OSX can have several k chars at least). And the Windows one should at least be PATH_MAX less a bit even without using long paths. (But then if you are going to use old winapi need to check its less than PATH_MAX if you extend). https://insanecoding.blogspot.co.uk/2007/11/pathmax-simply-isnt.html on Windows and indeed other operating systems we already have the correct code to get current working directory. so we just need to update dmd to use this. https://github.com/dlang/phobos/blob/v2.076.0/std/file.d#L2681 "
Catching C++ Exceptions in D - Windows and Linux
Hi. I'm here in HK with Ilya, Atila, John Colvin, and Jonathan Davis. I wondered what the current state of D catching C++ exceptions was on Linux and Windows. I know that some work was done on making this possible, and my understanding is that it is, more or less - just wondered what the rough corners might be. Thanks. Laeeth.
Re: dub projects generate docs and host on code.dlang.org?
On Tuesday, 5 September 2017 at 03:15:58 UTC, Adam D. Ruppe wrote: On Monday, 4 September 2017 at 11:15:08 UTC, Joakim wrote: While it's an interesting suggestion, dub has 355 open issues, would be better if more people pitched in on those: I have zero interest in fixing dub issues since I have zero interest in using dub. If one of the libraries were compelling... and I actually knew about it though, that equation may change. Making the code repository show documentation will do a lot to make the library more discoverable and valuable, which in turn, can drive dub use and bring with it more contributors. I think this is a good idea (and I bought a VM to set up to do it myself, but I went too cheap and the 512 MB of memory isn't enough to actually build the docs! ugh.) If you want a larger VM email me specs and I will set one up for you. I guess the doc generation doesn't need much changing on dub. Maybe an extra command line option to build and publish docs that calls a field specified in dub.sdl like postgenerate command because you don't want to build docs every time and creating separate build configurations means you now have double the number, with and without docs. And custom command allows you to use a different doc generator. But we could have a default command to generate those for dub the repository. And then the template for the web site would just need to have a link to appropriate directory added? We have contributed to dub in past - John Colvin worked on this. One problem was lack of bandwidth to review pull requests. If we get better review and still don't have contributions then one can address that directly, but for now review seems the bottleneck.
Re: How do you use D?
On Sunday, 6 August 2017 at 06:04:57 UTC, Ecstatic Coder wrote: Very interesting post. My bachelor's thesis was a expert system for stock trading implemented with Borland C++ 1.0, and D would have been a good fit as well if had been an option in 1989, so I understand why you think that financial development will make D popular. I don't know that I would say finance will make D popular but it's one domain that I know well where I think it can be useful. Popularity isn't only a good thing either. I think the focus on Go, Rust etc as a competitive threat is misplaced. If they do something well and it fits us we should without shame copy it, but better. But just because they are the focus of attention amongst some communities doesn't mean we should otherwise worry about what they are doing. But that's the exact opposite of what trending languages do at the moment (Go, Kotlin, etc). They care to solve the basic problems of the casual developer : implementing desktop, mobile or web applications. Why try to beat them at their own game, or even spend energy wondering about it. The DNA of the community mostly isn't interested in solving the problems of the casual developer in the same way. So unless it changes then it's a tough game to expect to beat them on criteria they set. Looks at the compounded rate of growth of dmd daily downloads. If it were a stock, I wouldn't be short it, because it's in an uptrend and far from overbought. Many other contexts you would even call that explosive growth. Not the most interesting jobs maybe, but that's what pays the bill of many of us, the "less skilled" developers who are not engineers. I guess you only need one job. And there is share of market and share of mind. It's much easier for talented people to be recognised as such in a smaller community than a vast one.
Re: How do you use D?
On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote: While the Orgs using D page is very nice ... I hoping to hear more personal stories ... So How do you use D? In work, (key projects or smaller side projects) in your side project, (github, links please) just to learn something new? (I would easily argue that learning D will make you a better C++ programmer, maybe not the most efficient way, but I a sure it i very effective) Did you introduce D to your work place? How? What challenges did you face? What is you D setup at work, which compiler, which IDE? And any other fun facts you may want to share :) I started programming in 1983: BBC BASIC, 6502 assembler, Z80 assembler. I learnt to program C on an Amstrad PCW running CP/M, and compiler I used had K style declarations. Then I discovered economics, and my life took a different course. I moved into trading and managing money, but I always programmed on the side to help me solve investment and business problems. Kept it quiet because programming was for a long time low status and clashed with what people expected to see in a money manager. Late 2013 I recognised that the way our business used technology was completely broken. The only way to make the most of technology is to combine an understanding of investing, financial instruments, the investment business, and technology in one mind. But where am I going to find a guy like that? So I looked in the mirror and realised I had to brush up my skills. So I started building tools to help me invest. My friends mostly thought it was a crazy course of action, because it's rare if you leave investing even temporarily to return to it, and I love markets, but sometimes the direct approach isn't the right one. We're drowning in data but don't have good tools to make sense of it. I learnt python and cython, but kept looking, because I wanted to have my cake and eat it. Why can I not have all of productivity, performance, static typing/correctness, abstraction, and code readability - I don't think I should have to choose just a couple, and I am not going to. That led me to D in 2014. At school they used to ask us if everyone else jumped out of the window would you do it too? And it's a profitable approach in financial markets to develop and learn to trust your own judgement of things. If a highly respected and very knowledgeable economist tells you "you do realise that there is no basis in economic theory for what you are suggesting", you need to be able to revisit your thinking, see what you might be missing, but in the end trust your own judgement over that of the putative expert. And he subsequently wrote a very impressive explanation after the fact of how what "couldn't be justified in theory" did in fact happen. And it's a bit similar with programming language choices and such. Its way better to appeal to people who make up their own mind and bear the consequences then to those who have to cover their behinds by getting the right ticks in the boxes because the are never going to be earlier adopters except through some unfortunate accident - because you also don't want such people as early adopters! Since then, one thing led to another, and I ended up hiring a few people from the community to help me as consultant developers. Maybe a bit more than 10% of Team Phobos, based on a simple calculation. I have also ended up running technology, amongst other things, for a decent size hedge fund. I am using D for the project I started beforehand, and we are starting to explore its usefulness in the rest of the firm for some core analytics. It pays to start small and build on early successes. Has D been good for me? What have been the consequences of the French Revolution? In both cases it's too early to say with utter confidence since life is complicated and things are not always what they seem to be in the moment, but I have a view on the latter, and I think the answer to the former is definitely yes. Finance used to be relatively at the leading edge. The industry got a bit too fat, it hired the wrong people as it expanded too quickly, and then after the crisis people had other things to worry about - first survival, and then an exploding burden of compliance. At one big bank even the compliance people complain about the number of compliance people they have. On top of that, there's so much legacy systems that it can be very difficult to do anything creative or new. So as an industry we fell behind a bit, and when you go through a cycle like that if becomes somewhat self-reinforcing. To turn things around you need to hire very good people, but it's not so easy to find very good people who are willing to work with the people who created and tolerated the mess in the first place. But it can be done, and I think based on a view from afar that the banks will do better on this front than they have been. For a
Re: How do you use D?
On Saturday, 5 August 2017 at 21:31:49 UTC, Ecstatic Coder wrote: It is more about marketing. Maybe Go is not a perfect language, maybe not even a good one, but it's sold so good because of a good marketing So, calling D a "better C++" is a bad advertisement. But if you rename it to 'Script', for example "DatScript" and sell it as "better, statically typed JavaScript dialect which compiles into fast native executables" it will became #1 language on GitHub in no time. +1 I've suggested exactly the same "easy-to-learn super-powered stronly-typed javascript" and "efficient web server development" advertising approachs to the D leadership, using a more "Python.org"-like website. Maybe it's because this change would be much too radical, but I've been told that the "Better C++" slogan won't change, despite D could easily be "tweaked" to eat a significant part of Go/Dart's market shares. And I'm not especially convinced that many C++ developers are currently rushing towards D because of the current website. For instance, I've personally chosen D *only* it was much better than JavaScript/Node.js, not because it was better than C++, that I still have to use for game and mobile development. Still waiting that somebody explains me how to _easily_ use D with Unreal Engine, Cocos2D-X, etc... ;) I know I'm not the general case, but this still proves that "some" C++ developers won't switch to D for long because they are too tied to their ecosystem. In open source, and indeed in entrepreneurial corporations, the way to persuade people is to create the shift you advocate, at least in a small way, so people can see what your early start could become. Code wins arguments, as they say at Facebook, and not just code but documentation, business plans etc too. Its work to write it, but on the other hand my experience has been that work is rarely truly wasted. It might seem so at the time, but for example work I did to persuade somebody that didn't want to listen, and where it seemed like I was pointlessly banging my head against the wall, has ended up being very valuable, even in dollar terms a few years later. It's not always rational to be excessively calculating about risk reward in the face of genuine, radical uncertainty when the risk is not that bad. I agree with you that the benefits of D are not perfectly well communicated to people who aren't C++ programmers looking for salvation. I had a discussion just last week about that, explaining that D isn't just something they mostly fits only large data sets where performance is key. And in particular it's a cultural challenge because people have become resigned to the idea of different languages for different purposes, and to a large extent D doesn't fit the mental schema people have. Nothing much changes in life day to day, and changes that seem to be big often unfold slowly for a long time before being noticed. The financial crisis unfolding began in Feb 2007 at the latest, but it didn't feel like that to most people at the time. Similarly, compare D documentation today to that of early 2014 (when I first look at D). Plenty of it was all perfectly clear if you had a more academic training in computing, but if not then it wasn't the friendliest. I tried to persuade one chap who was helping me between jobs to learn D, and he was absolutely terrified of it, to a good extent because of the docs! And it's also because people are used to complexity being hidden from them and things being made very easy. Since D often involves paying a price upfront to make future things easier, perhaps it's worth bearing in mind that there's a coupling between the degree of development of the tooling and how polished the docs should be. If you make it so easy to learn D that you draw people who are utterly stuck when they hit dependency problems with dub, that may not be ideal either. Ie an implicit question of truth in advertising. And the situation with docs changed over time. One recent change is thanks to Seb Wilzbach who introduced runnable examples generated automatically from unit tests. If you look at his pull request it wasn't welcomed entirely with open arms in the beginning because the benefits weren't clear (and some other reasons I forgot). So if you think we should have friendlier docs appealing to non systems programmers, why not write a mock up so others can see. It needn't be either or, because you can have an easy or advanced channel from front page. And it's worth not alienating those who want to go straight to the meat of things - there's nothing more frustrating than a system that talks down to you or breaks things down into little pieces when you're quite used to slaughtering and butchering dinner for yourself, thank you very much... I really think there's a limit in how much sense it makes to think about D marketshare against other programming languages.
Re: Netflix opensources its first D library: Vectorflow
On Thursday, 3 August 2017 at 03:46:11 UTC, Matt wrote: On Wednesday, 2 August 2017 at 21:31:19 UTC, Walter Bright wrote: https://www.reddit.com/r/programming/comments/6r6dwp/netflix_opensources_its_first_d_library_vectorflow/ Speakng of D in data science (where I think it can get traction), is there a standardized linear algebra library in D? Perhaps some hooks to Eigen? I saw a few upstarts LA libraries, but none that I would consider "the one to use in D", like numpy in python or Eigen in C++ We're using D in finance. D libraries are far from the maturity of Python, but they are developing quickly. https://github.com/kaleidicassociates/lubeck Library we have open-sourced https://github.com/libmir/mir-algorithm Mir library we sponsor Other mir libraries: https://github.com/libmir/mir-lapack https://github.com/libmir/mir-blas https://github.com/libmir/lapack https://github.com/DlangScience/cblas Performance matters: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html
Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept
On Thursday, 20 July 2017 at 12:23:31 UTC, Mike wrote: A few years ago I created a bare metal demo on an ARM Cortex-M4 microcontroller entirely in D. It was just a demonstration that one could do bare metal programming for microcontrollers in D without any dependencies on C or assembly. It was also a proof of some ideas I had about leveraging compile-time features of D to generate highly-optimized code (both small and fast) for these resource constrained systems. I hit a wall, however, with Issue 14758[0], and ultimately abandoned D for other alternatives. Well, that issue was recently fixed in GDC [1]. In addition, he GDC developers did some work to reduce the number of phony stubs one had to add to the runtime to get a build [2], removed the "shared is volatile" hack, and implemented the `volatileLoad/Store` intrinsics so I no longer need to do volatile access in assembly. So, I decided to give it another try, and updated that demo. You can see the results at https://github.com/JinShil/stm32f42_discovery_demo Congratulations, Mike. https://www.reddit.com/r/programming/comments/6pn31c/d_on_bare_metal_stm32f4_redux/ Could someone post to Hacker News? I don't have enough rep for it to propagate.
Re: static foreach is now in github master
On Monday, 17 July 2017 at 18:14:35 UTC, Andrei Alexandrescu wrote: For those who want to play with our new static foreach feature and are willing to take the steps to building their own dmd, the feature is now merged in master: https://github.com/dlang/dmd/pull/6760 Happy hacking! Andrei Maybe good subject for an AMA (though not many upvoted so far). It's pretty cool that it was added on an afternoon during the hackathon. https://www.reddit.com/r/programming/comments/6pn257/static_foreach_added_to_d_compiler_nightly/ Could someone post to Hacker News - I don't have enough rep there for stories to propagate. Can always post another story later on explaining the practical benefits of static foreach (good topic for a D blog post) - marketing is about repetition.
Re: dlang website design
On Saturday, 24 June 2017 at 18:10:54 UTC, Adam D. Ruppe wrote: On Friday, 23 June 2017 at 18:26:43 UTC, Ecstatic Coder wrote: I'm also in favor that some of your personal developments be converted into std libs. Eh, std libs is where you lose me. I don't mind offering a "just works" dmd download on my website, with my packaging dmd for some particular purposes, or on the official site, that includes all the stuff. But I have no interest in being part of Phobos and losing control of my projects. Now, I think Phobos should be open to those things, where the modules are owned by third parties and just packaged as a standard library. The phobos devs might fork it or whatever, of course, but this would be more like a Linux distribution than a corporate merger - the individual packages in a Linux distro are still owned by outside parties, and the distro maintainers just bring them in and might slightly modify them to fit their thing better. From the user side, it looks like a traditional std lib, but from the developer side, it is more of a bazaar than a cathedral. what is the barest minimum we need to enable that? someone to organise conventions about module organisation and some kind of package grouping in dub? so you can specify "adamandfriends" as a dependency to bring in the repackaged library under that group name? like yum groupinstall 'blahblah' but more personal.
Re: Go 1.9
On Saturday, 24 June 2017 at 11:18:10 UTC, Ecstatic Coder wrote: On Saturday, 24 June 2017 at 10:34:07 UTC, Ola Fosheim Grøstad wrote: On Saturday, 24 June 2017 at 09:35:56 UTC, Ecstatic Coder wrote: I'm assuming that D is for general purpose programming as well. That seems to be where it is heading. I don't think D stands a chance in that domain, but we'll see. With all due respect, on the contrary I think that promoting D as a general purpose programming language could be its only chance to really improve its popularity, and thus significantly grow its current user base. I know that in certain other sectors, people have high expectations of growth, but I really am at a loss to know what it is that people might expect significant growth to be when we already have some pretty impressive developments in the numbers that we do have. http://erdani.com/d/downloads.daily.png Daily unique dmd downloads in Jan 2013 were 150-200 much of the time. This year they have been between 1200 and 1700. What kind of growth would it take for you to be satisfied - I am curious? Bearing in mind that the availability of all three compilers via distributions has been improving over time. And it seems to be unlikely to be a mere artefact of some sort because it lines up with what one observes in the forums, in what one hears about dconf lately versus prior years (I only went to the past couple) and more importantly in development activity - commercial and organic. Weka.io hadn't even heard of D about three years ago and now they have one of the largest D projects there is. 3.5 years ago me neither - and soon I will be paying for about 4.5 full time equivalent people to work on D (maybe a bit more than that in time). This little web company called eBay seems to be using it - never heard of them before, but they seem pretty smart. Remedy Games released Quantum Leap, which I guess sold millions of copies - it used D for scripting and they will be using D much more throughout the firm shortly. It's used by a $20+bn hedge fund for their trading systems, and will gain greater adoption within a $3.5bn hedge fund quite soon. https://dlang.org/orgs-using-d.html And somebody else remarked to me: "just look at code.dlang.org these days - some interesting libraries and I don't know even half the names that wrote them". D doesn't need to persuade most C++ users to switch over to succeed. It doesn't need to persuade anyone you know to succeed. It's at a stage where it's easy to keep growing without anything particularly dramatic happening. All it needs to do is appeal just that little bit more to people who are already minded to use D, or for whom people who are in pain and looking for an answer (which D might be in part) to find out about the language - as happened recently with Weka. And if I compare the documentation, libraries, and general quality of things today compared to 2014 when I started looking at the language, it's improving much faster than just a little bit every year. One doesn't notice such change necessarily quickly. I agree, but it will be hard for D to beat C++, because people who *need* to use C++ as a "systems programming language" won't use D for the same reasons they don't use C#, Java or Go. Finance is still one of the larger spenders as an industry. C++ is used quite broadly within it for analytics. Not because people want a system language and need to use malloc and free and freely drop down to assembly, but because there isn't an adequate alternative that's widely known about for now. In 3-5 years time, I think number of users in finance of D will be higher, because it's the solution to pain. Also, people tend to have end-users working in many different languages. Writing separate clients for each one isn't ideal, and wrapping automatically makes much more sense. SWIG works, after a fashion, but D offers some more pleasant and more maintainable alternatives. R is done (thanks bachmeier); Python is done (PyD); Excel is done (me, Stefan + Atila); C/C++ is easy enough; C# will be done shortly, and I have already done some work on Java. If you say that finance guys will never consider adopting D, I beg to differ because I think I know that world quite well. And that's just a world I am familiar with, and there are plenty of others. The web guys get the attention because they are doing interesting things, have particular challenges, and can afford to talk - because their edge doesn't mostly come from code, which is why they open-source so much of it. It's a mistake to think that the people who talk are a good representation of the total number of lines of code that are written each year, let alone the total code that exists. Visual Basic for Applications (Excel) programmers for example do not tend to get much attention - yet there's still a lot of code in VBA, a lot of new code being written each year.
Re: Suggest; LDC windows package offer to install VisualD like DMD does
On Saturday, 24 June 2017 at 04:04:14 UTC, Manu wrote: On 23 June 2017 at 22:34, Kagamin via Digitalmars-d < digitalmars-d@puremagic.com> wrote: There's ldc installer? Sounds like a good starting point :) Refit the DMD installer and offer it alongside the archives? Why not add ldc as an option in the existing installer?
Re: Dub command line knowledge sought
On Friday, 23 June 2017 at 08:26:21 UTC, Russel Winder wrote: On Fri, 2017-06-23 at 08:11 +, Nicholas Wilson via Digitalmars-d- learn wrote: On Friday, 23 June 2017 at 07:51:51 UTC, Russel Winder wrote: > I am likely just staring at and missing the data needed: > > How does one invoke dub to fetch and build, and put into a > place other that ~/.dub/… a package from Dub? dub fetch foo --version=1.0.0 mv ~/.dub/packages/foo-1.0.0 /desired/path dub add-path /desired/path dunno about how to do that in one step. This is what I feared. The real awkwardness here is that Dub stores all the compilation products nicely separated by platform, compiler, and configuration, and puts the last build in a nice named place on the assumption there will only ever be one. So generally the ~/.dub/packages/foo-1.0.0 has to be moved as above. Using unit-threaded as an example: ~/.dub/packages/unit-threaded-0.7.24/unit-threaded/.dub/build/library-debug-linux.posix-x86_64-ldc_2073-1AF38A4B25224ABFB5BB5ED68A0E4633 Is the location of the last debug build on linux using ldc2, but what is that hash code, how to make that deducible so that it isn't necessary to move, just build. Check out the Kaleidic fork maintained by John Colvin - currently in his personal repository on github. We submitted back our changes but ended up being quite a lot so not all have been accepted yet. Allows you to change location of dub repos - useful to avoid work and personal interacting without having to use containers or VMs, but it may be easy enough to change path on an adhoc basis as you wish to do. Don't recall right now, but take a look.
Re: Go 1.9
On Thursday, 22 June 2017 at 07:32:51 UTC, Wulfklaue wrote: On Thursday, 22 June 2017 at 07:15:26 UTC, Bienlein wrote: In Java development there is almost no C or C++ and no Rust or D at all. Memory is no problem. Some server needs 256 GB RAM or maybe 512 GB? That is just sloppy... There is this bad trend in the industry, it has been going on for years. Performance issue, trow more hardware at the problem. Optimizations? Trow more hardware at the issue. The problem being that it has becomes a constantly lowering expectations bar. Hire some basic programmers, use php/ruby/python and performance issues are simply overlooked as part of the job. In my daily job seeing php import scripts that suck up a GB just for some basic work, is considered almost normal. Let the client pay for more performing servers. Our developers need to write more code, faster, be ready before the deadline so we can bill the client for the fast work. That's not an issue anywhere. As long as you get the performance through parallelisation there is no need for C or C++. And while this works on a local server, the moment you start with clusters, master-slave configurations etc, things get complicated fast. Especially with latency issues. You won't meet any Java EE archtitecture that will do anything else than fight against calling C, C++ routines from Java. That is only done in some very exceptional cases. That same applies to just about every other language. Native will always be prioritized before external calls. The days of languages for systems programming are over. There are only very few people that need such a language. That is why D really needs a decent GC, otherwise it won't find any users that would do production systems with it. Technically, with Go, Rust, Crystal etc more about those high performing languages, then before. Before it was all about scripting languages, slowly you see a trend backing away from them. Massive relative price shocks can be important in shaping trends in the use of technology. Storage prices drop 40% annually, Moore'a Law isn't what it was, and dram latency isn't improving nearly as fast as data sets are increasing in size. Intel non volatile storage technology upsets all our assumptions about where the bottlenecks are, and there seems a decent chance that as you say the tilt away from slow languages is only just beginning. https://www.quora.com/Why-is-Python-so-popular-despite-being-so-slow/answer/Laeeth-Isharc?share=5ebdf91a=35gE Acam paper linked at the end of this.
Re: dmd -betterC
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote: Is getting a whole lot better: https://github.com/dlang/dmd/pull/6918 You can now build D executables that do not link in anything from Phobos - only from the standard C library. Very cool - this plus Adam's changes. The next logical step for some might be to want to be able to use the bits of Phobos that don't necessarily need the runtime. Which might be a bad step. But it's oh so tempting to want to have bits that are version(NoRuntime)...
Re: dmd -betterC
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote: Is getting a whole lot better: https://github.com/dlang/dmd/pull/6918 You can now build D executables that do not link in anything from Phobos - only from the standard C library. https://www.reddit.com/r/programming/comments/6ijwek/dlangs_dmd_now_compiles_programs_in_betterc_mode/
Re: Advertise D's great compatibilty with JavaScript
On Sunday, 18 June 2017 at 23:11:25 UTC, rikki cattermole wrote: On 18/06/2017 5:29 PM, Meta wrote: We should be careful not to make *too* close a comparison. While Javascript is a necessary evil for web applications and some people do like it, I get the feeling that it's becoming less and less liked. It's not quite a fractal of bad design like PHP, but it has more than a few drastic shortcomings and design flaws. The moment webasm becomes a realistic target, I will do EVERYTHING in my power to get Lua in the browser (yes there already is solutions). Stuff Javascript, kill it, replace it with something actually properly designed! Why not D? And why wait till it's a realistic target? Wasm is clearly going to be the answer and it's an answer to a problem that exists, so what does one gain by waiting?
Re: Windows integration [was: Re: There really needs to be some moderation]
On Sunday, 18 June 2017 at 22:15:41 UTC, Adam D. Ruppe wrote: On Sunday, 18 June 2017 at 21:47:48 UTC, Laeeth Isharc wrote: Windows has been a bit of a pain, but mostly from the native code library side. I've found D on Windows to be very easy for myself and for my end users... but not for intermediate developers. For myself, I just set up the necessary .lib files in my dmd lib folder and problem solved. I can do conversions or generation as needed. For the end users, I'll just do a binary distribution and things just work for them. But intermediate devs having to set up the environment can be a pain... that's why my libs are set up in a particular way to work with dmd out of the box and other stuff opt in.. Yes, but suppose you want to build a C library like Google snappy, nanomsg or leveldb. It's a bit of a pain on Windows. No worse with D than C++. But it looks awfully complicated coming from C#.
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 11:50:20 UTC, Wulfklaue wrote: Maybe that is the same reason why D has a issue drawing in new non-C/C++ developers? What's your evidence for this? I'm curious. Not that the composition of new adopters matters particularly - it's just interesting to know. Well, i do not have the time. Want me to donate? Does that solve the issue. No ... because there is no clear infrastructure in place to actually hire people to work on the language and the environment. If you're serious, put up some money and maybe I can match it (and there is a decent chance one or two other larger commercial users might contribute also). One doesn't need much infrastructure to organise things, BTW. I have a private gitlab instance and a way to pay people and we're already trying to make the ecosystem a better in modest ways - for example we have already contributed back our internal changes on our own fork to dub.
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 15:54:36 UTC, Joakim wrote: On Friday, 16 June 2017 at 15:47:15 UTC, Russel Winder wrote: If it is true that there is increased traction for D, then getting some resource into the front of house stuff will be critical to that traction fading and disappearing. Yes, daily downloads of dmd are up 25-30% this year: http://erdani.com/d/downloads.daily.png " But when will D take off. There are no jobs in D. D hasn't taken off yet so it won't etc etc. "
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 14:40:42 UTC, jmh530 wrote: On Friday, 16 June 2017 at 13:30:21 UTC, Joakim wrote: On the other hand, maybe D is not meant for the kind of user who needs such an easy path. What does it matter if you set D up really easily and then can't grasp such a sprawling, lower-level language? Perhaps _this_ is the right packaging for D right now, to keep away the kinds of casual users who would not be suited for D. Today I agree with that, but in 1-2 years when mir/lubeck are in better shape I'm probably going to disagree. Hoping someone packages something together like an Anaconda for D that just easily works. What's missing from Lubeck that you would like to see? Wrt Anaconda for D - it's the native code (C) libraries that are the biggest pain point. Same thing as with Python really. So I wonder if we could figure out a way to host build configuration and build itself for the C libraries underlying dub bindings and wrappers. It's really a Windows-specific problem, because even today there doesn't seem to be a great answer. I played with chocolatey a bit, but it doesn't always seem to be that helpful in practice.
Re: Windows integration [was: Re: There really needs to be some moderation]
On Sunday, 18 June 2017 at 21:37:13 UTC, Martin Nowak wrote: On Sunday, 18 June 2017 at 21:06:07 UTC, Laeeth Isharc wrote: Is it possible to use lld on Windows? I never tried it myself. https://lld.llvm.org/ Says they don't support debug info (debugger being another dependency on VisualStudio). But yes, different toolchains (mingw, lld) and cross compilation (gdc, ldc) might improve the situation. The last gdc cross-compiler supported Windows is from 1/24/16. ftp://ftp.gdcproject.org/binaries/4.9.2/x86_64-linux-gnu/ AFAIK clang had quite some Windows support issues as well, so maybe we can draw some bits from their solutions. Part of the problem is that we have very few contributors that are using Windows, so there isn't much personal motivation to work on that. I wasn't using Windows but we are now, and there's an author of one Phobos module that will be starting to help me full-time from maybe August, so we could look at what could be done if we could start small. Windows has been a bit of a pain, but mostly from the native code library side. It should be easy to install google snappy right? On Linux it is. On Windows, not so much... And that's just one library. I almost never use debuggers myself so might be interesting to get lld working with ldc (dmd too?) if it's possible as could simplify our builds a bit.
Re: D needs to get its shit together!
On Sunday, 18 June 2017 at 14:53:57 UTC, Wulfklaue wrote: I already concluded from this "discussion" that there is no point trying to point out issues with D. Maybe too many people in the past pointed out the same stuff and they are tired of it. In an open-source community, the best way to change something is to make a start on it yourself and try to get others interested. Or if you can afford it you can see if Walter or Andrei might be interested in helping you under a consulting arrangement, or try to find someone else in the community that you could pay to change it for you. If you don't want to do the work, and can't pay, then you can still try to persuade people - and often enough, if you are gently persistent and your point is good, you'll be able to influence things over time. What doesn't work is complaining and expecting others to fix your stuff for you. In theory, when you purchase products and services your supplier ought to be much more responsive than where you don't pay. My experience has been that even when you pay quite a lot - millions of dollars - one can often be disappointed in just how responsive a commercial supplier will be. So increasingly over time for me I have come to see the merits of open-source, because at least I can figure out how to change something and find someone who will help me do the work. There are good people in the D community but in some responses you get the attitude like "how do you not know something so simple". And i am not talking about this topic. There are responses that borderline "how stupid are you". Maybe not in those words but you can read it clearly. I do not recognise this attitude at all - in fact it's remarkable how helpful people are, and how some of the best people in the community spend a great deal of time helping others for free. Perhaps _this_ is the right packaging for D right now, to keep away the kinds of casual users who would not be suited for D. Yes - it's an advantage for D in its present state of development that the frictions act as a shield and tend to mean the people who persist have a high level of technical ability and resourcefulness, and the people shape the culture. If you go buy something precious, they don't give you the hard sell. They say this X is not for everyone, but if you would like to understand it, here is what the thing is like. And I think it's like that with D - it's not for everyone, but if it were I wouldn't be here. I am not targeting any person here but there are people here with good intentions and people who to not realize how there responses look down on people. Some do not understand that not everybody has 10+ years in developing C/C++ programs and knows every terminology and understands every aspect of the memory management and the ins and out. Personally I programmed intensely in C and assembler from 1983 - 1988 at high school, a little from 1996-1998 and I picked up programming again in 2014. So in the beginning I had no idea why people were so focused on memory because when I learnt to program memory was pretty fast vs CPU and that changed whilst I was doing other things. But I learnt a lot just in a couple of years from being around here - and it wouldn't have been the case in a different community. I don't think it's true that people here look down on you or that they expect you to understand every nuance of memory management. One might feel initially inadequate, yes, but that's what it's like to learn something new. And people may also be a bit short on time - but it's not their responsibility to spend their free time to teach you. It's nice when they do, but it's up to us to teach ourselves using whatever resources we can find. Frankly, sometimes i wish i NEVER discovered the forums because seeing some of the discussions and reading the past discussions, it feels like a darn pool of evil. Good, bad and just ugly. It frankly demotivates... You must be reading different forums from me. And it has now **highly** opinionated my attitude about D, to the point that makes me wonder. As a potential employer: If i hire people with no D knowledge and they need to learn D. They go to these forums and get sucked into this. I'm paying people to work in D, and have done since 2015. I personally would never hire someone who would be put off by robust exchanges or who would lack the resourcefulness and ability to tolerate discomfort that everything not being completely shiny (documentation, installation on Windows) would deter them. In fact, I would go further and say that D is a good hiring filter for the very reasons that you find offputting (though you interpret the meaning of things differently from me). And I'm in a different business, most likely, and it may be that at this point the language is a good fit for me and not for some others - that's okay. D isn't for everyone, and it doesn't need to
Re: There really needs to be some moderation
On Sunday, 18 June 2017 at 21:01:10 UTC, Martin Nowak wrote: On Sunday, 18 June 2017 at 20:04:48 UTC, Joakim wrote: I strongly disagree about deletion and banning. The moment you start removing dissenting opinions, you move towards a bubble where you get isolated from the world. These people are detailing real frustrations that they had, albeit in a shrill manner, feedback that doesn't hurt. As for their posts affecting corporate perception, better they see the truth now and know what they're getting into, rather than the companies coming in here and ranting later, only to get their posts deleted too! :D Couldn't have said it better. Though I just filed [Add some Hackernews-like ranking and upvoting](https://github.com/CyberShadow/DFeed/issues/84) because relevance and not wasting people's time matters. Finally, my point was that since D is not at the stage where it has corporate support to polish it up to the sheen you want, perhaps it's better to keep away the kind of users who want that level of integration. That's not to say they're "less," but that D is not ready for them yet. We all hope D gets there someday, but maybe it's not yet ready to make that leap. You have quite a good point there, that said the Windows experience is fairly bad, no point about it. That's mostly because VisualStudio integration is required, be it for their linker and libc only, and that isn't too well done. Is it possible to use lld on Windows? I never tried it myself. https://lld.llvm.org/
Re: D needs to get its shit together!
On Sunday, 18 June 2017 at 15:47:34 UTC, Vladimir Panteleev wrote: On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: Just try getting D installed on all 3 major systems for DMD, LDC, GDC, with an IDE, some utilities, possibly arm support(even though it's new and expected to have some issues), etc. The issues really start popping up when you are trying to use x86 + x64. Library issues that result in strange error messages instead of "This compiler is not compatible with the phobos v2.4324". Might be worth considering something like the Android SDK installer. It looked like this: http://cache.filehippo.com/img/ex/4515__android_sdk_1_8_5_15.png Essentially it was a cross-platform package manager GUI, which allowed installing platform support for various platform versions side-by-side, as well as additional utilities and dependencies. It also exposed its functionality via command-line tools and IDE integrations. This translates fairly well to the D ecosystem, and could serve as a decent work-around for Windows' lack of native package management. We have some of the pieces as separate tools (Digger, DVM, the dlang.org/install.sh script, the Windows' installer's Visual Studio detection/integration), could be nice tying them together into a palatable GUI. Digger has a rudimentary one, which probably could be wrapped into a native-like app using Electron, but still lacking features such as managing GDC/LDC. Digger is great, as is the Windows installer, and I appreciate the work that has gone into them. Sadly though in the current year we have been ruined by everything being made easy for us - personally I have no problem taking things apart to get to the bottom of a problem when it doesn't work, but in the business world that is not universally true, alas. So I think what lets us down sometimes is tiny little things that maybe aren't complicated to fix, but are maybe a bit specific. For example it's not so easy to build 64 bit dmd on Windows from the command line (and I don't understand why we don't distribute a binary). Or the installer somehow doesn't seem to work with VS 2015 and I haven't even had the time to figure out what the problem is because it's not on my machine and I don't develop much on Windows at all myself. Having a tsar of ergonomics or user experience might be something valuable. Not really a tsar, but just someone to co-ordinate improvement of those little frictions that one doesn't even notice after using D for a while, but that are a big impediment to a newcomer. I mean you could sit with someone new to the language and see what they struggle with, or do it remotely and chat every week. You would learn a lot that way. It doesn't need to be an expensive resource - an intern could do that. The culture is shaped a bit by C/C++ world, but actually I disagree with Joakim that D is a low-level language. I don't really use it that way myself, and others before me - including Liran at Weka (who is pretty low-level when he needs to be) - have observed that D has qualities of a compiled Python. And people who use it like the latter are a bit accustomed to comfort, and so it's a bit of a shock when for exaple someone comes from C# or Python on Windows and wants to install zeromq and realises (or worse, doesn't) they have to build the C library themselves on Windows when they never even heard of cmake before. This was a real example, and the person grumbled that D was a lousy language for that reason... It's also true that an excessive love of comfort is a civilisation-killer, and I think that's one of the strengths of the community - that people who persist are those who aren't put off by things being a bit difficult in the beginning - but perhaps its a matter of balance, and one could think about how to make the experience a bit easier. (Yes, I realise that even today, Windows native code library management is a problem - I just use that as an example).
Re: There really needs to be some moderation
On Sunday, 18 June 2017 at 20:04:48 UTC, Joakim wrote: On Sunday, 18 June 2017 at 11:59:34 UTC, bachmeier wrote: As D continues to grow, there will be messages like this posted more frequently. Imagine that you work at a large company and are considering adopting D so you decide to check out the forum. Posts like this have to be deleted from the website and users that post such things need to be banned. Like it or not, this is marketing. I strongly disagree about deletion and banning. The moment you start removing dissenting opinions, you move towards a bubble where you get isolated from the world. These people are detailing real frustrations that they had, albeit in a shrill manner, feedback that doesn't hurt. As for their posts affecting corporate perception, better they see the truth now and know what they're getting into, rather than the companies coming in here and ranting later, only to get their posts deleted too! :D Yes - from my perspective, the way you know something is true is if you can recognise it as potentially such and expose it to critique and there hasn't been a _good_ argument against it. It's certainly true that the more corporate types will be put off by the directness and passion of discussions here, but I really don't think they are likely to be earlier adopters of D. The people who will be early adopters are discerning principals who have the ability to make decisions personally and bear the consequences rather than managerial agent types operating in a world where social perception dominates. The managerial types will come later - that's the price of success that it draws a different kind of person. From a hiring perspective, it's a positive thing that very few people are involved with D primarily for careerist reasons - even though I can think of quite a few people for whom it's turning out to be pretty good indeed, and where taking a more conventional route would not have had this payoff over time. This being said, there is only one problem which is that anyone can say anything and until you know who is insightful then it's not in the beginning obvious. Some people here (not many) for example that are highly intelligent are constantly criticising the direction of the language - but I'm really not sure they do much in D at all - they just like hanging out here and arguing: for them it is like sports. So I think people should earn the right to be listened to and who they are and what they have contributed sets the context for how one should understand a passionate critique, even rant. If Manu, for example, (I am thinking of a while back) expresses frustration and in very specific terms about infelicities then that's something we should take seriously because it's evident that he cares about the language and community and would just like to remove such infelicities because they get in the way of it being adopted by colleagues and associates. We might not be able to change much in the short term, but such a thing one should take seriously. As Walter said you should listen to your current best customers not the people who give you friendly 'free advice' when they do not actually have skin in the game. A community isn't a democracy - you listen to people who have shown they know what they are talking about, and the amount of noise people make is not very related to how much insightful they have to say.
Re: Is D slow?
On Friday, 9 June 2017 at 19:29:35 UTC, Honey wrote: On Friday, 9 June 2017 at 18:32:06 UTC, Steven Schveighoffer wrote: Wow, so that's how D code would look like if it were C++ :) Well, I cannot (and did not try to) hide where I am coming from. ;-) The results are quite disappointing. What seems particularly strange to me is that -boundscheck=off leads to a performance decrease. That doesn't make much sense, but I'm not an ldc2 user. However, it does note in the help that -release disables bounds checks already. Sounds like a bug, then. I did replicate that issue on my box, and mucking around with the implementation didn't help. In answer to the subject, no D is not slow. However, it's quite possible that std.algorithm.bringToFront is slower than std::rotate, or SortedRange.upperBound is slower than std::upper_bound, or both. I don't think it's a design issue per se, probably more of an implementation issue. Thank you for confirming the results and your factual explanation notwithstanding my pointed question. ;-) Maybe I was expecting too much given Andrei's performance oriented talks. I realize that the conceptual groundwork is more important than a concrete implementation that can be easily improved. However, I think that real world out-of-the-box performance - particularly with respect to toy examples (since those are small enough to be literally translated) - is important for prospects to gain confidence in buying into D. At the current state, at least for such benchmarks, I think, I should not rely on standard library facilities. Unfortunately, that does not increase my confidence. Real world and toy are mutually exclusive categories, and I am not sure the empirical evidence is consistent with your perspective that it is what prospects need to see before exploring D, though that is an interesting perspective. I highly recommend Weka.io talks if you would like to see how one larger D user has found performance in practice. If you are expecting a perfectly finished glossy product then I don't think that - at least in the current year - D will be necessarily for you. Polish improves every year, but it's not the principal focus of the community currently. It's more the opposite - pay the price up front in different ways and reap the returns again and again over time.
Re: Avast virus warning?
On Monday, 5 June 2017 at 16:31:04 UTC, Anonymouse wrote: I just sent a pre-compiled .exe of my project to a friend, and his Avast anti-virus promptly quarantined it and sent it off for analysis. I tried sending him a Hello World[1] with the same results. Is this something common for d programs? Anything I can do to work around it from my end? [1]: http://www.mediafire.com/file/fc51qz141r3ns6r/helloworld.exe https://forum.avast.com/index.php?topic=203573.0 It's not that people do bad things with D. It's that dmd generates code that doesn't look like anything it has seen before.
Re: good RPC framework for D?
On Tuesday, 6 June 2017 at 01:01:34 UTC, Timothee Cour wrote: Is there a good RPC framework for D? requirements: * efficient (no json/xml) * supports at least sending/receiving raw bytes I tried msgpack-rpc but it seems abandonned (last commit 2 y ago) and this issue makes it unusable: https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16 for messages of length >= 4090 bytes. I would love to have a GRPC work with D but couldn't find a package for it. Is there at least a reliable solution that sends raw bytes ? than I can for eg wrap protobufs or other serialized formats via serialization/deserialization. Additional requirements: supports streaming data (either input or output or both), and timeouts. I am working right now on wrapping grpc, but it's a bit of work and I have lots of other things to do and can't be sure when or if I will finish. The C API is not that bad once you understand what if is doing. And see dprotobuf.
Re: Make enum auto castable
On Sunday, 4 June 2017 at 22:52:55 UTC, Mike B Johnson wrote: I am dealing with some COM stuff and some functions use VARIANT, which can hold an enum. Instead of having to manually convert the enum(and for that matter, other things) to VARIANT, is it possible to have them automatically converted? This is because an enum is always convertible to a VARIANT but not the other way around. So, when a enum is passed to a function accepting a VARIANT, it should just work. Overloading is not an option. Not sure if this breaks your requirement but you could generate overloads or rather templated version of your variant accepting function with a mixin that introspects on functions with a certain uda in the module. See excel-d for an example.
Re: Dynamic binding to the Mono runtime API
On Saturday, 3 June 2017 at 17:30:05 UTC, Jakub Szewczyk wrote: Mono runtime is a cross-platform, open-source alternative to Microsoft's .NET framework [1], and it can be embedded in other applications as a "scripting" VM, but with JIT-compilation enhanced performance and support of many languages such as C#, F# or IronPython [2]. It provides a C API, so I've bound it to D as a Derelict-based project, available at https://github.com/kubasz/derelict-mono, and as a DUB package (http://code.dlang.org/packages/derelict-mono). It currently wraps the Mono 5.0 API. There's also a simple example of calling a C# main from D code, and C# code calling a native function implemented in D. PS: Because I don't own a Mac I have no idea what the correct paths to the Mono shared library are, so it'd be great if someone could post/create a PR of them. [1] http://www.mono-project.com/ [2] http://www.mono-project.com/docs/advanced/embedding/scripting/ This is very cool - thank you for doing this. It could prove very helpful. Have you thought of/any interest in looking at automatically generating C# wrapper and bindings for D code? (I'm interested myself mostly in nested templated structs/arrays rather than classes). It may not be relevant for you, but if it is please drop me an email on laeeth ... at kaleidic.io Thanks. Laeeth.
Re: D scripting in D
On Friday, 2 June 2017 at 17:22:20 UTC, Stefan Koch wrote: On Friday, 2 June 2017 at 16:13:03 UTC, Laeeth Isharc wrote: On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote: [...] Stefan Koch has written a good part of an interpreter for D AST, no? And I guess the lexing and parsing stage doesn't take so long, whereas not having to link saves much time. So is there any way to repurpose his work on ctfe to have an interpreter that you can call at run time, set context for and get return values back? No there is not. First it's woefully incomplete and secondly it's tightly bound to dmd, and it's semantic phases Maybe it's incomplete today, but some day it will be or could be finished. And whilst I understand the difficulty of working with the dmd codebase as it's structured today, why is it intrinsically a problem that your work is bound to dmd? T - interesting idea about ldc though that's a bit slower than dmd.
Re: D scripting in D
On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote: I wonder if it is possible to somehow turn D in to a scripting language that can be run inside D? The point? To have the same uniform syntax for quickly developing scripts that can then be easily transferred, if desired, in to a complete binary. e.g., suppose I am working in some type of analysis software. Use a Dscript like feature to develop and test different analysis algorithms quickly(rather than using the compile and execute model)... then once everything is working, move the code to a D file and compile it directly. Since the syntax would be identical(or nearly so) it would be quite easy to copy and paste... unlike, say, using lua or some other non-D like scripting language. Stefan Koch has written a good part of an interpreter for D AST, no? And I guess the lexing and parsing stage doesn't take so long, whereas not having to link saves much time. So is there any way to repurpose his work on ctfe to have an interpreter that you can call at run time, set context for and get return values back?
Re: Bad array indexing is considered deadly
On Friday, 2 June 2017 at 10:37:09 UTC, aberba wrote: On Friday, 2 June 2017 at 02:11:34 UTC, Laeeth Isharc wrote: On Wednesday, 31 May 2017 at 13:34:25 UTC, Steven Schveighoffer wrote: [...] Hi Steve. Had similar problems early on. We used supervisord to automatically keep a pool of vibed applications running and put nginx in front as a load balancer. User session info stored in redis. And a separate process for data communicating with web server over nanomsg. Zeromq is more mature but I found sometimes socket could get into an inconsistent state if servers crashed midway, and nanomsg doesn't have this problem. So data update either succeeds or fails but no corruption if Web server crashes. Maybe better ways but it seems to be okay for us. Laeeth How does that setup affect response time? Do you cache large query results in redis? Our world is very different from web world. Very few users but incredibly high value. If we have twenty users then for most things that's a lot. We don't cache query results as it's fast enough and the data retrieval bit is not where the bottleneck is. Laeeth
Re: Bad array indexing is considered deadly
On Wednesday, 31 May 2017 at 13:34:25 UTC, Steven Schveighoffer wrote: On 5/31/17 9:21 AM, H. S. Teoh via Digitalmars-d wrote: On Wed, May 31, 2017 at 09:04:52AM -0400, Steven Schveighoffer via Digitalmars-d wrote: I have discovered an annoyance in using vibe.d instead of another web framework. Simple errors in indexing crash the entire application. For example: int[3] arr; arr[3] = 5; Compare this to, let's say, a malformed unicode string (exception), malformed JSON data (exception), file not found (exception), etc. Technically this is a programming error, and a bug. But memory hasn't actually been corrupted. The system properly stopped me from corrupting memory. But my reward is that even though this fiber threw an Error, and I get an error message in the log showing me the bug, the web server itself is now out of commission. No other pages can be served. This is like the equivalent of having a guard rail on a road not only stop you from going off the cliff but proactively disable your car afterwards to prevent you from more harm. [...] Isn't it customary to have the webserver launched by a script that restarts it whenever it crashes (after logging a message in an emergency logfile)? Not an ideal solution, I know, but at least it minimizes downtime. Yes, I can likely do this. This kills any existing connections being handled though, and is far far from ideal. It's also a hard crash, any operations such as writing DB data are killed mid-stream. .. -Steve Hi Steve. Had similar problems early on. We used supervisord to automatically keep a pool of vibed applications running and put nginx in front as a load balancer. User session info stored in redis. And a separate process for data communicating with web server over nanomsg. Zeromq is more mature but I found sometimes socket could get into an inconsistent state if servers crashed midway, and nanomsg doesn't have this problem. So data update either succeeds or fails but no corruption if Web server crashes. Maybe better ways but it seems to be okay for us. Laeeth
Re: D for Android beta
On Thursday, 1 June 2017 at 19:31:28 UTC, Joakim wrote: The beta release of ldc 1.3, the llvm-based D compiler, is now out: https://github.com/joakim-noah/android/releases It is accompanied by a non-trivial sample app from the Android NDK, ported from C++ to about 1.2 klocs of D: the classic Utah Teapot (https://en.wikipedia.org/wiki/Utah_teapot), updated with mobile touch controls. This app also demonstrates calling Java functions from your D code through JNI, though most of it is written in D. There are two builds of ldc, a cross-compiler that you can use from a linux/x64 shell to compile to Android/ARM, and a native compiler that you can run on your Android device itself. As I pointed out last year, not only is ldc a large mixed D/C++ codebase that just worked on ARM, but it is possible to build arbitrarily large Android apps on your Android device itself, a first for any mobile platform: http://forum.dlang.org/thread/ovkhtsdzlfzqrqneo...@forum.dlang.org This is the way the next generation of coders will get into coding, by tinkering with their Android devices like we did with Macs and PCs decades ago, and D is one the few languages that is already there. I will write up instructions on how to write an Android app in D _on_ your Android device by using ldc and the Termux app, and get ldc into the Termux packages, a package repository for Android: https://play.google.com/store/apps/details?id=com.termux=en Congratulations, Joakim! https://www.reddit.com/r/programming/comments/6eqv46/write_mixed_dc_android_apps_even_build_them/ and news.ycombinator.com Looking forward to termux.
update list of organisations using D to refer to blog posts and talks
Could we try to keep the list of organisations using D updated to include links to talks given since the list was made? Eg Weka, Remedy Games. Similarly could we add blog posts (eg recent one on eBay) to the list as we do for talks. Maybe we could add some more concise quotes as well to this page. Eg Tamedia say "D is not only a highly productive language, but also a great hiring filter." But nothing for Weka. If we could contact Netflix to get their confirmation and approval to mention their use of D for machine learning, I think their name would carry some weight. Bear in mind that this page may be visited by people that have influence on decisions by their organisations, and who are just taking a quick look and won't dig deeper unless their interest is piqued. Then also, on the front page under Community there should be a "Notable Projects" page for non-commercial open-source projects like Tilix (nee Terminix). Finally - I think having a "channels" or domains page that gives a primer on domain-specific resources available would make it a bit easier for people looking into the language. Eg bioinformatics, numerical computing, automated translation from other languages, web services, etc. The knowledge is there, but it's a bit fragmented. I would do myself, but don't have so much time unfortunately. Thanks. Laeeth.
Re: Please provide DMD as 64 executable
On Friday, 19 May 2017 at 10:38:56 UTC, Andre Pany wrote: Should I file an issue for providing the 64 build of dmd on windows? As 64 bit is the default on the other platforms it should be available for windows too by default. Kind regards André We would find this useful too because we run out of memory on Windows. There may be a way to build dmd for win 64 as a script, but it wasn't obvious to me when I looked at it. There is a Visual D script, but I do not know how to use that using msbuild. Digger fails. I mentioned to Vladimir and Martin at dconf, but haven't had time to file an issue. Laeeth.
