New beginnings - looking for part-time D programming help
Hi. For those that didn't hear, I resigned from Symmetry in September and my last day was a couple of weeks back. I don't have any concrete plans yet, but I've agreed not to do anything in the hedge fund world for quite some time and I've also agreed not to hire anyone that's an employee or consultant for Symmetry. Out of little acorns do great oaks grow and the best beginnings are often not much, just a little hobby project. I sat down in early 2014 and wrote down what I called hedge fund in a box - what are the things I am going to need to build so I never have to worry about them again. Not always quite in that form, but it's remarkable how many of those little beginnings ended up coming to fruition in what was an 11bn hedge fund by the time I left. With that said for now I don't have much, just a few ideas about how to solve some of my own problems, knowing there's just a chance they might be useful down the line to others. I'm paying out of my own pocket and my budget is modest for now so this isn't going to be an opportunity interesting for someone currently embedded in big tech ! You can speak to some of the people I hired at Symmetry - if this ever becomes anything then I will pay well to very well over time. But you shouldn't bet on it becoming anything at all. If you do good work but nothing comes of it and you're interested in getting a job in finance I can help you navigate that world and the experience may help you achieve your goals. But I am not sure I would recommend most jobs in finance. What kind of work? Initially some scripting in D to integrate things and a little bit of work with LLM embeddings and fine tuning, STT transcription, classifiers, parsing. Some presentation work - gui or web I don't mind. What kind of person? You need to be a talented hacker that's interested in learning and accomplishing things. You don't need an impressive CV - my best documentation Dev hire was a Spanish baker with no enterprise experience. (Just the kernel, lol). What's the vision? Well I will say more when I can but how people do work today in organisations is broken and it's miserable and I would like to play a part in transforming that. Full remote is ideal as I live on an island. If you happen to live near Rennes, Saint Malo or Amsterdam then it's easier for me to visit you. Let me know any questions. laeeth+reboot at laeeth.com
Semi - OT: LLVM blog on calling most of C++ from a DSL written in D
https://blog.llvm.org/posts/2021-03-25-cling-beyond-just-interpreting-cpp/
Talk before Compiler Research Group at IRIS-HEP Princeton on SIL-cling
https://youtu.be/7teqrCNzrD8 https://t.co/2iAWdO9cXA Alexandru Militaru speaks to Compiler Research Group, IRIS-HEP at Princeton about his work at @SymmetryInvest using CERN's cling to compile and call C++ from our internal domain specific language, SIL. #dlang #cling
Re: FeedSpot Recognizes the GtkDcoding Blog
On Friday, 7 February 2020 at 16:00:07 UTC, bachmeier wrote: On Friday, 7 February 2020 at 15:05:13 UTC, Russel Winder wrote: True companies have convinced themselves that only licences that allow stealing of others' intellectual work are acceptable to business, but then that is the point, they can steal the intellectual work with impugnity. A rant of my own: The push against the GPL is mostly by those who want free software to mean "free labor". GPL software can be dual licensed. Companies can pay for an alternative licensing arrangement if it's that valuable to them. Instead they want "free" software that allows them to avoid payment while imposing restrictions on how others use the software. How do you pay for an alternative licensing arrangement when there are a gazillion contributors some of whom are untraceable and when in practical terms any one of those saying no might make it in practical terms impossible? Software can be dual licensed, but it often isn't, particularly with community developed software. Most software is internal software I think. But a company needs to make decisions strategically in the face of uncertainty. Suppose you are considering a library for internal use and not planning to redistribute. But business is uncertain. Maybe it could be you want to redistribute your software to a future partner. Now if you use a viral license library that doesn't give you an option to pay for it then you are shutting off that option.
Re: My Android project nearing beta
On Monday, 6 January 2020 at 14:37:54 UTC, Adam D. Ruppe wrote: On Sunday, 5 January 2020 at 03:56:37 UTC, visitor wrote: Not a single line of java! so i got kinda excited for creating a class 100% in D as well, but. https://developer.android.com/training/articles/perf-jni.html "DefineClass is not implemented. Android does not use Java bytecodes or class files, so passing in binary class data doesn't work." I haven't tried, but: https://github.com/linkedin/dexmaker
Re: Article about D in the iX magazine
On Sunday, 22 December 2019 at 13:05:02 UTC, Robert M. Münch wrote: On 2019-12-20 21:26:00 +, Andre Pany said: In the new iX (1 Januar 2020) there is also a Leserbrief for the article;) Even there are only few comments, every comment helps. It's very hard to convince programmers to give something else a try and stay to it long enough to see the light. Most of the time, evangelizing is very frustrating. The better strategy from my experience is: Deliver a cool product and than tell everyone "we are 10 times more productive than our competitors while delivering a better product." You can be sure, everyone wants to know how you do it. I think it's much better to spend most time on those receptive to it anyway, which is a very small proportion of the programmers many people might know in real life. The beauty of being the challenger is you can keep growing by persuading only a small proportion of people who were already poised on the edge or would be if they knew of D. Yes - I agree that delivering value speaks the loudest. But of course in a competitive market it's not necessarily going to be something people discuss. It's outside the reality of many others, what can be achieved with D, and at the same time you don't necessarily want to actually make it vivid to your competitors how they could do what you did. I think also that enthusiasm and working code might be more effective than logic and feature comparison. The biggest asset the D community has might be the calibre of people that are drawn to it and that stick with it...
Re: Mix struct types in the same array
On Wednesday, 18 December 2019 at 22:17:21 UTC, tirithen wrote:
On Wednesday, 18 December 2019 at 22:11:10 UTC, Sebastiaan
Koppe wrote:
If you know all types up front you can use the Sumtype library
on code.dlang.org
Thanks, it's a good starting point, the best would be if I only
needed to define that the struct would implement void
applyTo(ref User user) so that could be run in the loop to
update the User entity.
But I'll try the Sumtype library, that takes me forward, thanks
for the answer!
https://github.com/atilaneves/concepts
interface IFoo {
int foo(int i, string s) @safe;
double lefoo(string s) @safe;
}
@implements!(Foo, IFoo)
struct Foo {
int foo(int i, string s) @safe { return 0; }
double lefoo(string s) @safe { return 0; }
}
// doesn't compile
/*
@implements!(Oops, IFoo)
struct Oops {}
*/
Re: d programs conversion to c
On Wednesday, 11 December 2019 at 18:54:49 UTC, jicman wrote: Greetings! I am trying to see if there are any converters out there from d code to c. Anyone knows? Thanks. josé How many lines of code is it ? It's not that bad to do it manually with help from regex. If you're good with vim macros like Robert Schadek then that may help too. There's a project to convert C code to Rust and some day I plan to support something similar for C to D. LLVM used to have a C backend that was revived by the Julia guys. Might get somewhere with that, but if it's not too big a codebase assisted manual isn't that bad. First version of excel-d I had to do entirely manually as dpp didn't exist.
Re: LDC 1.18.0
On Wednesday, 23 October 2019 at 02:22:56 UTC, zoujiaqing wrote: On Thursday, 17 October 2019 at 04:04:41 UTC, Newbie2019 wrote: On Wednesday, 16 October 2019 at 22:31:41 UTC, kinke wrote: Thanks for keep up the good work. Android CI is really a great for mobile users, I wish some day there also include IOS cross build binary package. Yes, I wish it too. LDC for iOS needed. We use iOS. If somebody were willing to do the work of bringing LDC up to date and maintaining it maybe we could support the work, or at least contribute to it.
Re: Good way let low-skill people edit CSV files with predefined row names?
On Thursday, 24 October 2019 at 17:41:21 UTC, Dukc wrote: On Thursday, 24 October 2019 at 16:50:17 UTC, Dukc wrote: Hmm, I need to check whether I can do that on LibreOffice Calc. Unfortunately, no. If there's a way to do that, it's not obvious. I should be able to make an easy-to-use excel-to-csv translator using Atilas Excel utilites without too much effort. This was wrong: Atila's Excel-d enables writing plugin functions, but not reading the spreadsheets. There are other DUB utilities for that, though. I quess I will give my employer two options: Either the price variables are in an one-column CSV and I distribute the key column separately so they don't mess it up, or I take my time to do a GUI solution. Unless somebody has better ideas? Another Symmetry project allows reading Excel files and a third is wrapper and bindings around a C library to write Excel files. We use them in production daily though there may be rough edges for features we don't use. I should think you can use a Javascript library and call it from D. See trading views repo by Sebastian Koppe for an example of this. Bindings are manual currently but he will work on generating them from the Typescript bindings in time.
Re: D for sciencetific scripting / rapid protoryping
On Tuesday, 22 October 2019 at 05:58:50 UTC, Prokop Hapala wrote: I'm examining the possibility to move from Python+C/C++ to D or Python+D. I read (https://wiki.dlang.org/Programming_in_D_for_Python_Programmers) and (https://jackstouffer.com/blog/nd_slice.html), where is mentioned PyD, Mir-algorithm, all seems very promising. But I did not test it yet. [...] See autowrap. PyNih might eventually be a bit nicer than pyd but it's not yet there. We did some very early work on Julia integration and probably will finish when time. You can call R libraries from D too. If you do use pyd then ppyd might make it a bit more pleasant. Some rough edges around pyd but it's okay if you don't mind figuring things out.
Re: Five Projects Selected for SAOC 2019
On Tuesday, 27 August 2019 at 17:32:30 UTC, Max Haughton wrote: On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev wrote: On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote: The Symmetry Autumn of Code 2019 application selection process has come to an end. This year, we've got five projects instead of three. Congratulations to everyone who was selected! You can read about them and their projects over at the D Blog: https://dlang.org/blog/2019/08/25/saoc-2019-projects-and-participants/ Sorry, I haven't been following. Don't we already have an implementation of the "Create a CI or other infrastructure for measuring D’s progress and performance" project? I just haven't been maintaining it because there hasn't been a lot of interest in it while it was being maintained. Here's the original blog post: https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/ I'll give it a kick and get it back online if there is interest. Seems wasteful to reimplement it from scratch, though. I was aware of the site when i wrote the proposal, but the idea is to create the infrastructure to add more measurements too, e.g. profiling the compiler or testing it under limited memory (I found out how much memory my CTFE thing was using the other day!). Assuming I can get it to work I'd also like to throw the Linux perf system in there too, Take a look at BPF. Might be some work to wrap and if I recall right some of the C headers are a bit gnarly. But it's pretty powerful. https://github.com/brendangregg/bpf-docs
Re: problems with swig generated code
On Tuesday, 3 September 2019 at 20:03:37 UTC, Martin DeMello wrote: On Sunday, 1 September 2019 at 11:19:11 UTC, DanielG wrote: Do you know whether SWIG's D generator is even being maintained? I've searched for it on the forums in the past and got the impression that it's outdated. I didn't realise that :( It was included in the current release of swig, so I figured it was maintained. It's pretty sad if it's not, because trying to access C++ libraries directly from D has some limitations (most notably not being able to create new C++ objects from D) and swig would have let things just work. I think DPP can call constructors. YMMV. We are working on a little project I started as another step in the eternal personal hackathon. Libclang isn't my cup of tea. It's almost very cool but they put in whatever the guy needed and so it's inconsistent but your alternative is code that breaks things between breakfast and teatime. Cling is used at CERN and I found libcling more pleasant. I only wrapped the cppyy fork but that actually allows you to reflect at runtime on a lot. From our DSL at work I can include a header, instantiate a templated type, create an instance of the class and call a method on it. Can, but it's not what I would call fun. I didn't yet get time to wrap the rest of the interpreter. But the idea is to make a tool for wrapping c++ via simpler extern (C++). If one isn't quite sure upfront what will work and not then it's much more pragmatic. I can't see how it won't work but we will know in a week or two. My first version is here. https://github.com/kaleidicassociates/cpp-reflect-d There is another route people don't think of. Calypso can introspect on C++ too. You might not want to use it in production but you don't need to. Either I guess you could use it to generate wrappers or you can use it to replace a chunk of cpp code. The surface area of a method must be larger than thr surface area of a chunk. Well chosen then it's easy to write glue code semi automatically. But it's nice to be able to replace a method at a time and have working code at every step. You don't need to trust Calypso in production to be able to use it for this purpose.
D for a safer Linux kernel
I noticed a Rust post so why not post. https://www.reddit.com/r/linux_programming/comments/cs0ime/d_for_a_safer_linux_kernel https://www.reddit.com/r/programming/comments/cs0iec/d_for_a_safer_linux_kernel
OT: in economic terms Moore's Law is already dead
https://www.infoq.com/presentations/moore-law-expiring/ At the same time as the arrival of Optane persistent storage in relatively chest machines changes the game a bit. If storage prices do keep falling at 40% annualised or thereabouts, it's possible one might see a little more respect being given the writing performant code than currently.
PoC: Runtime Reflection in D on C++ code
It's rough and ready - no proper build and not at all well-tested. But it will definitely work in time since it uses the fork of libcling for cppyy that's used at scale for CERN. cppyy generates python bindings for C++ code on the fly using the cling interpreter (it handles templates by doing the specialisation at python runtime). I'm a bit short of time, so putting this out here in case it's useful for anyone - might be some months before I get to look at it again. https://github.com/kaleidicassociates/cpp-reflect-d ROOT: https://github.com/root-project/root https://cppyy.readthedocs.io/en/latest/ http://wlav.web.cern.ch/wlav/Cppyy_LavrijsenDutta_PyHPC16.pdf
Re: Autonomous driving company is looking for D software engineers
On Sunday, 23 June 2019 at 12:22:18 UTC, XavierAP wrote: On Tuesday, 18 June 2019 at 19:05:05 UTC, Dragos Carp wrote: AID GmbH (https://aid-driving.eu) a subsidiary of AUDI AG is looking for experienced D-evelopers in Munich. If you want to employ your D expertise and be part of the autonomous driving revolution, apply under: https://jobs.lever.co/aid-driving/c4b243bd-c106-47ae-9aec-e34d5bbe0ce1?lever-via=vcPRnEaCR3 Thank you very much for sharing. You work at AID? As Laeeth says, could you let us know whether it would be ok to add a mention to AID to the Dlang website? https://dlang.org/orgs-using-d.html https://www.reddit.com/r/programming/comments/c4f1hu/dlang_being_used_for_autonomous_driving_research?sort=confidence
Re: Autonomous driving company is looking for D software engineers
On Tuesday, 18 June 2019 at 19:05:05 UTC, Dragos Carp wrote: AID GmbH (https://aid-driving.eu) a subsidiary of AUDI AG is looking for experienced D-evelopers in Munich. If you want to employ your D expertise and be part of the autonomous driving revolution, apply under: https://jobs.lever.co/aid-driving/c4b243bd-c106-47ae-9aec-e34d5bbe0ce1?lever-via=vcPRnEaCR3 Nice work. Could somebody perhaps check with AID and if it's okay add their name to the list of companies using D.
Re: my first kernel in betterC D
On Wednesday, 19 June 2019 at 13:45:45 UTC, matheus wrote: On Sunday, 16 June 2019 at 16:14:26 UTC, Laeeth Isharc wrote: ... Nice indeed, maybe you should mention this on reddit? Matheus. Feel free to. But I didn't do any work - I changed a few lines in the C code and of course it just worked. So I would feel embarrassed posting to Reddit because the original author did the hard bit and I just made trivial changes. You know I think Atila is right about social factors and integration being everything. The objections to using D are just that - it's not really about what people say mostly, but those are excuses to rationalize how they feel. One aspect of that is just showing something is possible. Adam Ruppe's talk at dconf a while back has had a lasting influence on how we approach things, mostly for giving me permission to do what I'm naturally inclined to do anyway. If you're not sure then bet a little time to try - the worst thing that can happen in user code is a segfault and so what. For example our business is not primarily about network programming at a lowish level. But when people say file transfers to Asia are slow because of the speed of light and latency one doesn't need to accept that. It's quite a similar problem - latency and packet loss - to the days of 300 baud models and XModem and there's an obvious solution. But before doing it myself I figured someone must have solved it and I found UDT. I spent half a Saturday wrapping it so it built but wouldn't work and Robert Schadek finished the job in a day or two. What's a decent performance improvement these days? Well I'm pretty happy with a 300 times (not 300%) improvement in file transfer speed between regions! And we can pull that plus libzfs in D plus our little language to have a tool for managing zfs snapshots and replication that makes everything simple because it's coherently designed and integrated. Anyway I think sometimes a barrier to adoption is sometimes just nobody has yet shown the problem is easily solved using D in your domain. We are in an age that's short on daring and ambition, which means a little bit of courage goes a long way. Nobody could break the four minute mile. One guy did it and then lots of people followed. Most people closest to using D that aren't I guess will have a decent size C or C++ code base. DPP keeps getting better in relation to C++ and we want to get it to a stage where it can be used to expose an internal library that's still got a C++ interface but is being replaced step by step with D. Thanks, Daniel Murphy for showing the way there, though we aren't able to do the translation programmatically. DPP has paid for the modest support we provided many times over already even just considering direct benefits. I wonder a bit about translation from C. Rust 2C was a multi million DoD project. We could steal the front end that dumps out the libclang C AST as CBOR. I suppose it shouldn't be hard to translate that to C-style D programmatically. It "adds nothing" to libclang in theory but it saves a lot of time as libclang is not the most complete or pleasant API I have seen. If we had something dependable it would be much easier to move a C codebase incrementally to D because you could just do what you can manage at that time and you don't need that much imagination or courage because it doesn't end up being a big binary bet. I guess translating C++ programmatically is a much harder, maybe almost impossible problem. But C would be a start. I have my hands full right now but I would play with doing it myself if I had more time... Laeeth
my first kernel in betterC D
https://github.com/kaleidicforks/mkernel-d I spent a few minutes on just turning the C code to betterC D - was curious to see if it would work. It seems to. I didn't try loading with GRUB. The dub.sdl isn't quite right, so best run ./build.sh Cannot push to code.dlang.org - it complains about registering a forked package, even after renaming.
Re: DConf 2019 Livestream
On Wednesday, 8 May 2019 at 08:04:08 UTC, Mike Parker wrote: On Wednesday, 8 May 2019 at 08:00:15 UTC, Andrej Mitrovic wrote: On Wednesday, 8 May 2019 at 07:57:40 UTC, Mike Parker wrote: The venue uses WebEx for livestreaming. All the information is available in this PDF: https://drive.google.com/open?id=1yekllbfOmxHqJNuuWIVeP9vNeROmfp1I "When joining: Please connect using Internet Explorer, not Google Chrome or another web browser." You guys can't be serious, you're using WebEx? Not us. The venue. Sorry about that. It was supposed to be streaming to YouTube, but it fell through the cracks. We are looking into it now. Laeeth
OT - Git training Lon/HK and book recommendation on taste in programming
Hi. First question - can anyone recommend git / Gitlab training providers in HK and London? Two distinct audiences - highly intelligent people that may or may not really program, and experienced developers with a finance background that could benefit from knowing how to use git properly (finance is often in the dark ages). On the former we are even getting HR, legal and compliance to start to use git for documents. So some handholding will be required. I would like a combination of classroom, small group on-premise training and somebody being in the office a few hours a week to help show people. No experience is necessarily required for the latter provided you know git well and can patiently explain things in a way less advanced people will understand. It could even be a nice part-time job for a student and we could pay well. Not that we wouldn't look at a professional either - I just mean that I am open minded. Second question. Lots of people these days start to program to solve their problems at work but they may never have been shown the basic principles of design, structuring and maintenance of their code. If I could give them one book (and a few YouTube links) what should it be ? Simple things like it's okay to write functions, start with getting the data structures right, quality is fractal (Walter making little improvements to DMD for example), value of simplicity and things that are harder to explain like the proper composition of a system. I would appreciate any suggestions on either one. Laeeth
Re: Phobos in BetterC
On Friday, 8 March 2019 at 09:24:25 UTC, Vasyl Teliman wrote: I've tried to use Mallocator in BetterC but it seems it's not available there: https://run.dlang.io/is/pp3HDq This produces a linker error. I'm wondering why Mallocator is not available in this mode (it would be intuitive to assume that it's working). Also I would like to know what parts of Phobos are available there (e.g. std.traits, std.typecons...). Thanks in advance. I would guess it's not available because it was written before betterC mode was a thing and nobody has yet updated it. If you look at spasm on code.dlang.org there is a version you can copy paste that should work in betterC mode if I remember correctly.
Re: DConf 2019: Shepherd's Pie Edition
On Thursday, 27 December 2018 at 17:00:05 UTC, Robert M. Münch wrote: On 2018-12-22 21:38:42 +, Laeeth Isharc said: On Saturday, 22 December 2018 at 18:47:40 UTC, Robert M. Münch wrote: On 2018-12-22 12:18:25 +, Mike Parker said: Thanks to Symmetry Investments, DConf is heading to London! We're still ironing out the details, but I've been sitting on this for weeks and, now that we have a venue, I just can't keep quiet about it any longer. Hi, you should consider the upcoming Brexit chaos, which is expect to have a high impact on all airlines. Currently I wouldn't bet that all parties involved get things sorted out until May... I would be happy to bet they do. The EU and US are already agreed. https://www.bbc.co.uk/news/business-46380463 Well, we will see. But it's not the EU and US, but UK and US that agreed after your reference. Since I'm not from the US this information doesn't help a lot. And the significant part of your reference is this: "Theresa May's Brexit agreement with Brussels says that the UK and EU have agreed to negotiate a "comprehensive air transport agreement" for UK-EU flights during the planned transition period but it would not apply if the UK left the EU without a deal. In September the government warned a no-deal Brexit could cause disruption to air travel between the UK and European Union countries." You might be aware that the "No Deal Scenario" is currently much more likely... but again, everyone is free to do what they want. In the event of no-deal, flights will continue as before except UK operators flying _within_ Europe on domestic or intra-EU flights will need to get a license. UK operators can continue to fly to Europe, and we already said the European operators can fly here. This is a relatively recent official confirmation of what was always fairly obvious - a negotiating position is not quite the same thing as the position in actuality. http://www.travelweekly.co.uk/articles/319768/updated-european-commission-reiterates-flights-will-go-ahead-post-brexit You can read the technical guidance if you wish. Naturally it comes with the spin you would expect. And since flights to and from the EU will continue to operate, I doubt very much that flights between Britain and anywhere else will cease to operate. Britain has a current account deficit with every European nation bar Ireland and I think Malta, meaning we import more than we export. The wilder scenarios painted assume that one of the two parties would deliberately sabotage their own economy. I don't think so. I had lunch with a lawyer who advised Cameron and Osborne in their negotiations with the EU. He has written five books on Brexit, approaching it from a technical rather than political perspective. He pioneered the suggestion of enhanced equivalence which will likely be the roadmap for financial services. He says Brexit consists of a multitude of small problems which will have to be overcome by the people closest to them. But a no-deal Brexit would be fine and quite quickly rather positive. All of this stuff "if there is a no-deal Brexit, Theresa May _could_ run out of insulin" - that word could is like nasal demons in UB with C. It's a funny use of the word could - the lawyer called the insulin suggestion an insult to the intelligence. And my sister in law is a partner in a pharmaceutical regulatory firm here in Germany where I write from, and she agrees the suggestion is nonsense. There's a lot of such stuff about, generated for partisan reasons. The track record of such suggestions is pretty dire - both Mervyn King, former Governor of the Bank of England,and Paul Krugman, a former trade economist, haha, suggested that the Bank was damaging its reputation by making such political arguments. So it's best to go to the primary sources and technical documentation. There are more entertaining ways to scare oneself if that's what one wants. But flights will be running as good or bad as they ever do,as best I can tell.
Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 18:47:40 UTC, Robert M. Münch wrote: On 2018-12-22 12:18:25 +, Mike Parker said: Thanks to Symmetry Investments, DConf is heading to London! We're still ironing out the details, but I've been sitting on this for weeks and, now that we have a venue, I just can't keep quiet about it any longer. Hi, you should consider the upcoming Brexit chaos, which is expect to have a high impact on all airlines. Currently I wouldn't bet that all parties involved get things sorted out until May... I would be happy to bet they do. The EU and US are already agreed. https://www.bbc.co.uk/news/business-46380463
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 28 November 2018 at 13:30:37 UTC, Guillaume Piolat wrote: On Wednesday, 28 November 2018 at 12:48:46 UTC, Laeeth Isharc wrote: Nassim Taleb raises the question of how do you choose between two surgeons, both recommended. One looks the part and hangs his many certificates on his office wall. The other looks scruffy with the appearance of a tradesman. Who do you pick? Taleb says pick the guy who doesn't look the part because if he got there without signalling he must have something going for him. It's definately the kind of surgeon one should choose - programmers that are not necessarily well groomed etc.. - but is it the kind of surgeon people will actually recommend? I'm doubtful. If X has the social signalling then people will recommend X even without trying, because it's socially safe. If one doesn't have the signalling, I've found the hard way even supporters will hesitate a bit before making recommendations, because of the social standing _cost_ it may have. But then, perhaps recommendations don't matter, because opinions don't matter much? I think they matter to be even heard on public places. And I think early adopters need a nudge, the influent need to be bothered by less influents (influencers are not especially on the lookout for new options, as they are already influent). Above all I think the niche of early-adopters is smaller than the larger market for languages, and the early-adopters are going elsewhere. The innovator's dilemma, which is really an insight that dates back to Toynbee, and before that Ibn Khaldun, is not so obvious. I am not sure that you have understood it. I suggest reading the book if you are interested, but otherwise I unfortunately don't have so much time at the moment to try to persuade you of what this phenomenon is like and there's limited value to talking about talking rather than having a discussion based on a shared understanding of what this is about.
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 28 November 2018 at 13:05:34 UTC, Guillaume Piolat wrote: On Wednesday, 28 November 2018 at 12:48:46 UTC, Laeeth Isharc wrote: D isn't really marketed and it's definitely not sold. That's an implicit strategy in itself. What I see in my (absurdly competitive) market is that the people that truly do no-marketing tend to close shop, sometimes despite very competitive offerings. It colors my perception of course, since it can be very tempting to appeal to a limited pool of discerning customers; but that would mean death. What is the ratio of expenditure of your best customer to an average customer? Not much. That's one main reason why your intuition developed by organising your emotions according to your business domain fits this domain less. What is the ratio of expenditure of the biggest 'customer' of Python to the average 'customer'? Measured by resources lent to the community directly or indirectly, or by the wage bill of programmers at that firm working in Python this ratio is enormous.
Re: D compilation is too slow and I am forking the compiler
On Monday, 26 November 2018 at 16:00:36 UTC, Guillaume Piolat wrote: On Thursday, 22 November 2018 at 04:48:09 UTC, Vladimir Panteleev wrote: On Wednesday, 21 November 2018 at 20:51:17 UTC, Walter Bright wrote: Unfortunately, you're right. The title will leave the impression "D is slow at compiling". You have to carefully read the article to see otherwise, and few will do that. Sorry about that. I'll have to think of two titles next time, one for the D community and one for everyone else. If it's of any consolation, the top comments in both discussion threads point out that the title is inaccurate on purpose. Please don't get me wrong, it's an excellent article, a provocative title, and fantastic work going on. I didn't meant to hurt! In my opinion language adoption is a seduction/sales process very much like business-to-consumer is, the way I see it it's strikingly similar to marketing B2C apps, unless there will be no "impulse buy". I think that there are different strategies - decent appeal to a broad market and having a very high appeal to a small market (but there has better be something good about your potential customer base ie 'D, if you find VBA too difficult' is probably not a good strategy!). And you probably don't get to pick which situation you are in, and then one had better realise it and play the game you're in. The particular kind of market will shape what works - in my business you approach a retail client base differently from regular institutional investors and then the worlds' largest pools of money involved something else again. D isn't really marketed and it's definitely not sold. That's an implicit strategy in itself. Nassim Taleb raises the question of how do you choose between two surgeons, both recommended. One looks the part and hangs his many certificates on his office wall. The other looks scruffy with the appearance of a tradesman. Who do you pick? Taleb says pick the guy who doesn't look the part because if he got there without signalling he must have something going for him. But in general you can appeal on merits mostly to an audience that is highly discerning and very capable. If you haven't got any money to appeal to an audience that judges based on heuristics and social factors well then you can try to avoid accidentally putting people off, you can be creative with guerilla marketing but the key thing is to make the most of what you got. If everyone else does things a certain way then if for some reason that's closed off to you for now then if you look closely, with active perception,you may well see opportunities that are neglected to approach the problem another way. Actually no less than 3 programmer friends came to (I'm the weirdo-using-D and people are _always_ in disbelief and invent all sorts of reasons not to try) saying they saw an article on D on HN, with "D compilation is slow", and on further examination they didn't read or at best the first paragraph. But they did remember the title. They may rationally think their opinion of D hasn't changed: aren't we highly capable people? It doesn't matter what most people think. It matters what people who are on the fence or using D already a bit think. Or people who have a lot of problems to which D is in part a solution only they didn't know about or think of D yet. The messenger matters too. If someone you trust and rate highly tells you something based on their experience that counts for a lot more than all the blog posts in the world. And working code and lived experience dominates the social talk about it. I've talked about D with the CTO of Bloomberg, the outgoing COO of Barclays investment bank, the number two guy at a 30bn hedge fund, the COO of the largest hedge fund in the world (depending on how you count) and more. That's not going to change anything tomorrow but in time those kinds of conversations matter much more than what people might say on Reddit. It's not either /or of course, but it's just not worth sweating your reviews. Finally the reasons people buy things are not what you might reasonably think! Ask Walter how he was able to compete successfully for so long as a one man band with Microsoft. I don't think his edge was in the beginning something calculated. Reasonable people may think marketing and biases don't apply to them but they do, it works without your consent. The thing is that we had a bubble in synthetic manufactured marketing. And now increasingly people are tired of that and seek what's authentic, real and that doesn't pretend to be perfect. That doesn't mean a bit of thought is a bad idea,just that it might matter less than you think that the D community isn't particularly interested in marketing. Sometimes one can see that hidden in what superficially seems to be a weakness is a strength.
Re: xlsxd: A Excel xlsx writer
On Wednesday, 7 November 2018 at 16:49:58 UTC, H. S. Teoh wrote:
On Wed, Nov 07, 2018 at 04:41:39PM +, Robert Schadek via
Digitalmars-d-announce wrote:
https://code.dlang.org/packages/xlsxd
Announcing xlsxd a OO wrapper for the C library libxlsxwriter
[1].
Run:
import libxlsxd;
auto workbook = newWorkbook("demo.xlsx");
auto worksheet = workbook.addWorksheet("a_worksheet");
worksheet.write(0, 0, "Hello to Excel from D");
and you have created a Excel spreadsheet in the xlsx format
with name
demo.xlsx
that contains the string "Hello to Excel from D" in row 0,
column 0.
[1] https://github.com/jmcnamara/libxlsxwriter
Is there support for reading xlsx files too?
T
There are various C libraries.you could just use DPP to call
them..
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Thursday, 1 November 2018 at 22:37:59 UTC, unprotected-entity wrote: On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote: Actually, code within a module *should* be tightly coupled and cohesive -- that's the whole reason to put that code inside a single module in the first place. If two pieces of code inside a module are only weakly coupled or completely decoupled, that's a sign that they should not be in the same module at all. Or at the very least, they should belong in separate submodules that are isolated from each other. How does one determine, whether a 10,000 line module, is tightly coupled and cohesive? You take a look through it and make a judgement. Only the author can make that statement - which they naturally will, even if it's not true. ? An outsider, seeking to verify that statement, has a hell of a job on their hands...(I for one, think code smell immediately). There is a basic question in life. Do you believe in discernment (if possible informed by data) or are you someone who makes decisions on the basis of evidence and believes that anything else is completely arbitrary and nothing more than a matter of opinion. My impression is that the values of the D community tend more in the direction of recognising the importance of discernment. If someone is somebody who believes more in 'evidence', policy and rules then it probably isn't going to be satisfying expecting one's values to be shared on a wide scale here. People also differ in their working memory and the degree to which they naturally think associatively. Chopping up everything into small pieces favours those who have a smaller working memory and who think more analytically but it's a disadvantage for those who have a large working memory and think associatively. For a private project that's something to be resolved between the relevant people, but I don't think it's reasonable to say that large files per se are wrong, just because they aren't your cup of tea personally. I think that lots of things seem clear in theory but the difference between theory and practice is often quite large. In practice Phobos is very readable. And on the other hand, I have seen an experienced and capable C# programmer struggle to understand an intranet site written in the approved way by an experienced person who was well-trained at Microsoft. I couldn't understand it either so I concatenated all the little itty bitty files, pulled out the data structures and then it was easy. I don't use a particular language. I'm more interested in design and architecture. Can one really speak of that kind of design in the abstract ? Language features shape your choices and lead to large shifts in the optimum. If you don't have design by introspection as a possibility you are going to pick something else. In the age of 'lock-down-everything', increased modularity is becoming more important. A monolithic module approach, is already outdated, and risky, in terms of developing secure, maintainable software If you can't understand the program does that make you more or less secure? Security requires also to understand the behaviour of the system as a coherent whole. I think D programs are pretty easy from that perspective. Is that really such a bad idea? Are there no programmers out there in the D world that might think this could be a good, additional tool, to give programmers, so they can better architect their solution? Burden of proof is on you to write a DIP and make an argument for it. I am not sure you would find it easier to get a change into C++. Look at how difficult it is for Walter sometimes ; and he has just a little earned credibility. Same thing for Guido - he had such little fun with a recent PEP he decided to retire from BDFL of python. The amount of push back in the D community on this idea, is really odd to me. I'm still trying to understand why that is. Persuading people isn't easy even if it's a good idea. Look at the pushback from C++ over static if. They crippled it when they finally did relent. It's a bit entitled to think that if you can't persuade people without having written a DIP that it's them not you! Are D programmers just hackers, insterested in getting their code to work, no matter what? Are their not enough Java/C# programmers coming to D - and bringing their design skills with them? Would you mind explaining why you think that people from mass communities have design skills by virtue of having come from a mass community? Walter and Andrei are just a little bit known for their design capabilities so the bar is quite high. I think it's possible you might have things topsy turvy. Making D code work is rarely a problem. Every nation has its own strengths and weaknesses and the same is true of language communities. Having worked with D professionally since 2015 and with a decent size codebase in
Re: New Initiative for Donations
On Friday, 26 October 2018 at 06:19:29 UTC, Joakim wrote: On Friday, 26 October 2018 at 05:47:05 UTC, Neia Neutuladh wrote: On Fri, 26 Oct 2018 02:38:08 +, Joakim wrote: As with D, sometimes the new _is_ better, so perhaps you shouldn't assume old is better either. There's no assuming going on. Cryptocurrencies are worse than credit cards for everything that normal people care about, Such as? I already noted that they're easier and cheaper, you simply flatly state that "normal people" find them worse. and they're better than credit cards for illegal transactions. Yes, just like cash, and have other benefits that come with cash too. This might eventually change, and we can re-evaluate then. If for some reason cryptocurrencies become popular and sufficiently stable to be used as currency, I have no doubt that existing credit card companies will start offering automatic currency exchange, so you can have an account in USD and pay a vendor who accepts only Ethereum, or vice versa. As such, accepting credit card payments is good enough. I don't know what we'd be waiting for, the tokens I mentioned are all worth billions and widely used, particularly by techies: https://coinmarketcap.com Why would I wait for antiquated credit-card companies to accept these tokens? The whole point of these new tokens is to obsolete the credit card companies. Cryptocurrencies are worse is better for some people in some contexts. HSBC started the process of shutting down my company bank account because payments to programmers in Russia triggered some alerts and you get caught up in this Kafkaesque maze where there is nobody reasonable to talk to. I wrote to the Chairman in Hong Kong and only then could I get them to see reason and apologize. So for making payments to Russia, yes if the other side accepts them, worse is better in this case. For Venezuela or some African countries worse is obviously better quite a lot of the time. For making smaller payments overseas cryptocurrencies with low fees like BCH can be more efficient than a bank wire, even in the West. As regards particular currencies, deadalnix, member of the D community and creator of SDC compiler project is the man behind Bitcoin ABC, the largest Bitcoin Cash client, and one of the key people technically for Bitcoin Cash overall.
Re: New Initiative for Donations
On Saturday, 27 October 2018 at 14:33:43 UTC, Neia Neutuladh wrote: On Sat, 27 Oct 2018 10:54:30 +, Joakim wrote: I see, so you want other taxpayers to bail you out for your mistakes, interesting. One of the major points of having a government is to create these regulations that make it less likely for individuals to suffer from the actions of other people and organizations. Another major point is to help people in need using the collective efforts of society. Programs like FDIC in the United States exist to serve both of these: it's an extra set of regulations for banks, and compliant banks will be bailed out if circumstances require. If I choose an FDIC bank and the owners run off with my money, I didn't make an avoidable mistake, any more than being mugged in the street is me making a mistake. If you oppose that, you're gunning for an eventual repeat of the Great Depression. Banks are special because of the payments system and because of lending. In October 2008 Gordon Brown was within two hours of shutting down the banking system and declaring a state of emergency. If that had happened nobody would have been able to make payments and new lending would have come to a halt. In 2038 you won't need banks to make payments because cryptocurrencies will be a viable alternative. And lending is already being provided by asset managers. So the justification for the combination of leverage and the mismatch in liquidity and risk of banks deposit liabilities and their assets will disappear. The component of TARP that constituted aid to the financial system made a profit, but nonetheless there will be very little public appetite for a repeat the next time around. At the request of the UK debt management office, I met the representative of the IMF financial stability review in early 2005. He had a bee in his bonnet about the dollar yen carry trade and hedge funds: generals always fighting the last war. I told him to worry about the banks and what they were buying. He didn't listen. So regulators have little skill when it comes to understanding systemic risk posed by the asset and liability decisions of banks and so it will be good to make that function redundant. So cryptocurrencies matter. They are far from mature right now though and it's not the most important thing if you have limited resources to accept them. The best way to get the Foundation to accept them might be to do the work to help...
Re: Will the core.stdc module be updated for newer versions of C?
On Saturday, 8 September 2018 at 01:12:30 UTC, solidstate1991 wrote: While for the most part it still works very well, however when porting Mago I found a few functions that are not present in C99 (most notably wcsncpy_s). While I can write my own functions to do the same (already done this with C++'s array since a few classes inherited from std::vector, hopefully I don't need to fiddle too much with it on the Debug engine to limit reliance on GC) I think it would be a good idea to do some updates on the runtime library in this regard, especially as it's a very easily available @nogc library too. dpp has worked for most C headers I tried and if not then file a GitHub issue and we will fix it. I think C++ will come step by step in time, though it's quite a lot of work.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Thursday, 6 September 2018 at 14:42:14 UTC, Chris wrote: On Thursday, 6 September 2018 at 14:30:38 UTC, Guillaume Piolat wrote: On Thursday, 6 September 2018 at 13:30:11 UTC, Chris wrote: And autodecode is a good example of experts getting it wrong, because, you know, you cannot be an expert in all fields. I think the problem was that it was discovered too late. There are very valid reasons not to talk about auto-decoding again: - it's too late to remove because breakage - attempts at removing it were _already_ tried - it has been debated to DEATH - there is an easy work-around So any discussion _now_ would have the very same structure of the discussion _then_, and would lead to the exact same result. It's quite tragic. And I urge the real D supporters to let such conversation die (topics debated to death) as soon as they appear. The real supporters? So it's a religion? For me it's about technology and finding a good tool for a job. Religions have believers but not supporters - in fact saying you are a supporter says you are not a member of that faith or community. I support the Catholic Church's efforts to relieve poverty in XYZ country - you're not a core part of that effort directly. Social institutions need support to develop - language is a very old human institution, and programming languages have more similarity with natural languages alongst certain dimensions (I'm aware that NLP is your field) than some recognise. So, why shouldn't a language have supporters? I give some money to the D Foundation - this is called providing support. Does that make me a zealot, or someone who confuses a computer programming language with a religion? I don't think so. I give money to the Foundation because it's a win-win. It makes me happy to support the development of things that are beautiful and it's commercially a no-brainer because of the incidental benefits it brings. Probably I would do so without those benefits, but on the other hand the best choices in life often end up solving problems you weren't even planning on solving and maybe didn't know you had. Does that make me a monomaniac who thinks D should be used everywhere, and only D - the one true language? I don't think so. I confess to being excited by the possibility of writing web applications in D, but that has much more to do with Javascript and the ecosystem than it does D. And on the other hand - even though I have supported the development of a Jupyter kernel for D (something that conceivably could make Julia less necessary) - I'm planning on doing more with Julia, because it's a better solution for some of our commercial problems than anything else I could find, including D. Does using Julia mean we will write less D? No - being able to do more work productively means writing more code, probably including more D, Python and C#. I suggest the problem is in fact the entitlement of people who expect others to give them things for free without recognising that some appreciation would be in order, and that if one can helping in whatever way is possible is probably the right thing to do even if it's in a small way in the beginning. This is of course a well-known challenge of open-source projects in general, but it's my belief it's a fleeting period already passing for D. You know sometimes it's clear from the way someone argues that it isn't about what they say. If the things they claim were problems were in fact anti-problems (merits) they would make different arguments but with the same emotional tone. It's odd - if something isn't useful for me then either I just move on and find something that is, or I try to directly act myself or organise others to improve it so it is useful. I don't stand there grumbling at the toolmakers whilst taking no positive action to make that change happen.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Thursday, 6 September 2018 at 20:15:22 UTC, Jonathan M Davis wrote: On Thursday, September 6, 2018 1:04:45 PM MDT aliak via Digitalmars-d wrote: D makes the code-point case default and hence that becomes the simplest to use. But unfortunately, the only thing I can think of that requires code point representations is when dealing specifically with unicode algorithms (normalization, etc). Here's a good read on code points: https://manishearth.github.io/blog/2017/01/14/stop-ascribing-meaning-to-un icode-code-points/ - tl;dr: application logic does not need or want to deal with code points. For speed units work, and for correctness, graphemes work. I think that it's pretty clear that code points are objectively the worst level to be the default. Unfortunately, changing it to _anything_ else is not going to be an easy feat at this point. But if we can first ensure that Phobos in general doesn't rely on it (i.e. in general, it can deal with ranges of char, wchar, dchar, or graphemes correctly rather than assuming that all ranges of characters are ranges of dchar), then maybe we can figure something out. Unfortunately, while some work has been done towards that, what's mostly happened is that folks have complained about auto-decoding without doing much to improve the current situation. There's a lot more to this than simply ripping out auto-decoding even if every D user on the planet agreed that outright breaking almost every existing D program to get rid of auto-decoding was worth it. But as with too many things around here, there's a lot more talking than working. And actually, as such, I should probably stop discussing this and go do something useful. - Jonathan M Davis A tutorial page linked from the front page with some examples would go a long way to making it easier for people. If I had time and understood strings enough to explain to others I would try to make a start, but unfortunately neither are true. And if we are doing things right with RCString, then isn't it easier to make the change with that first - which is new so can't break code - and in some years when people are used to working that way update Phobos (compiler switch in beginning and have big transition a few years after that). Isn't this one of the challenges created by the tension between D being both a high-level and low-level language. The higher the aim, the more problems you will encounter getting there. That's okay. And isn't the obstacle to breaking auto-decoding because it seems to be a monolithic challenge of overwhelming magnitude, whereas if we could figure out some steps to eat the elephant one mouthful at a time (which might mean start with RCString) then it will seem less intimidating. It will take years anyway perhaps - but so what?
Re: What changes to D would you like to pay for?
On Wednesday, 5 September 2018 at 07:00:49 UTC, Joakim wrote: The D foundation is planning to add a way for us to pay for changes we'd like to see in D and its ecosystem, rather than having to code everything we need ourselves or find and hire a D dev to do it: "[W]e’re going to add a page to the web site where we can define targets, allow donations through Open Collective or PayPal, and track donation progress. Each target will allow us to lay out exactly what the donations are being used for, so potential donors can see in advance where their money is going. We’ll be using the State of D Survey as a guide to begin with, but we’ll always be open to suggestions, and we’ll adapt to what works over what doesn’t as we go along." https://dlang.org/blog/2018/07/13/funding-code-d/ I'm opening this thread to figure out what the community would like to pay for specifically, so we know what to focus on initially, whether as part of that funding initiative or elsewhere. I am not doing this in any official capacity, just a community member who would like to hear what people want. Please answer these two questions if you're using or would like to use D, I have supplied my own answers as an example: 1. What D initiatives would you like to fund and how much money would you stake on each? (Nobody is going to hold you to your numbers, but please be realistic.) $50 - Parallelize the compiler, particularly ldc, so that I can pass it -j5 and have it use five cores _and_ not have the bloat of separate compiler invocation for each module/package, ie taking up more memory or time. $30 - Implement H.S. Teoh's suggestion of having an automated build system to periodically check which dub packages are building with official compiler releases: https://forum.dlang.org/post/mailman.3611.1536126324.29801.digitalmar...@puremagic.com $25 - Enable GC for the DMD frontend, so that dmd/gdc/ldc use less memory I would also stake smaller amounts on various smaller bugs, if there were a better interface than bountysource and people were actually using it, ie users knew about and were staking money and D core devs were fixing those bugs and claiming that money. 2. Would you be okay with the patches you fund not being open-sourced for a limited time, with the time limit or funding threshold for open source release specified ahead of time, to ensure that funding targets are hit? Yes, as long as everything is open-sourced eventually, I'm good. $500.00 to fix these three together - they may well be essentially the same bug: https://issues.dlang.org/show_bug.cgi?id=19179 https://issues.dlang.org/show_bug.cgi?id=5570 https://issues.dlang.org/show_bug.cgi?id=13957 Can delay fix if you wish if it's ultimately open-sourced.
Re: D kernel for Jupyter notebook
On Tuesday, 4 September 2018 at 04:58:41 UTC, Shigeki Karita wrote: On Monday, 20 August 2018 at 00:14:03 UTC, Shigeki Karita wrote: On Sunday, 19 August 2018 at 20:33:45 UTC, Laeeth Isharc wrote: Proof of concept works, but it requires some further development to be useful to do work in. [...] Great. I have tried DUB integration. It seems to work. https://github.com/ShigekiKarita/grain/blob/master/example/repl.d I'm making a jupyter based tutorial for my library. It might be the first example for jupyterd. https://github.com/ShigekiKarita/grain/blob/master/tutorial.ipynb Very cool. Thank you. I was looking into Jupyter widgets. I ported over some of it and had to add the extension to protocol for widgets into the notebook. It's not that bad and might be pretty useful to be able to access widgets from D. Half-finished code right now that doesn't even build but I don't have so much time and won't for a couple of months.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 05:38:49 UTC, Iain Buclaw wrote: On 4 September 2018 at 04:19, Laeeth Isharc via Digitalmars-d wrote: On Monday, 3 September 2018 at 16:07:21 UTC, RhyS wrote: A good example being the resources going into DMD, LDC, GDC... 3 Compilers for one language, when even well funded languages stick to one compiler. And now some people think its a good idea to have DMD also cross compile because "its not hard to do". No, maybe not but who will do all the testing, what resources are going to spend when things do not work for some users ( and the negative impact on their experience )... Its a long list but people do not look past this. It sounds like fun, lets think / or do it. What resources do you think go into GDC? I think Iain would love to hear about all these resources because I am not sure he has been made aware of them because they don't exist beyond him and possibly a tiny number of others helping in part at certain stages. *Looks behind self* *Looks under desk* *Looks under keyboard* There must be resources somewhere, but none appear to be within reach. :-) If Iain had a beer for every person that complained about the effort spent by team GDC without having first thanked him and his vast team then... People are sometimes quite disconnected from reality. At least I have no other explanation for people demanding others do this or do that without doing the minimum necessary to make it appealing for others to work on it. I mean my experience is that you can pay people a lot of money and ask them beforehand do you want to work on X, and it's no guarantee they actually will be willing to when it comes to it. Programmers in general can be very independent-minded people, and if somebody is looking for especially meek and compliant people then if you have come to the D forums you are in the wrong place! One can be much more persuasive with positive words than complaints. Most people are well aware of that so if they are complaining it's in my judgement because they want to complain. People with high standards will do that when they feel powerless. I'm not talking here about notorious highly intelligent trolls like Ola and sock-puppets who never seem to actually write code in D. But nobody who can keep up here is powerless. It's possible to change the world you know, and from the most unpromising start. Forget about what's realistic, and focus on what you want to achieve. Believe me, you can achieve an awful lot from the most unpromising start. People talk about how most people are not super-hackers and one shouldn't expect them to manage without polish. Well hacker is a state of mind,a way of being in the world. Ask Iain if his self-conception is as a super-hacker with l33t skillz that a mere professional programmer couldn't match and you might be surprised (I think his self-conception might be wrong, but that's Dunning Kruger in action for you). It's really much more about values and virtues then capabilities. Are you able to tolerate discomfort and the accurate initial feeling of conscious incompetence? Because that's what real learning feels like once you leave the spoon-feeding stream of education. D is a gift to the world from Walter, Andrei, and those who contributed after it was begun. Just demanding people do stuff for you without doing anything to contribute back - that's not how life works. I don't think I have ever seen this degree of a feeling of entitlement in my life! And I've been working in finance since 1993. If doesn't want to pay money towards the development of IDE integration, doesn't want to do any work themselves, then the least they could do is draw up a feature list of what's missing and find a way to help from time to time with the organisation of the work. That's the only way things ever get done anyway. Have you noticed how the documentation has gotten much better? Runnable examples too. Did that happen because people complained? No - it happened because Seb Wilzbach (and maybe others) took the initiative to make it happen and did the work themselves. A little money goes a long way in open source. So if you're a company and you're complaining and not donating money to the Foundation then what exactly do you expect? We have a few support contracts with MongoDB (a choice made before I got involved) and the legal fees alone were 20k and we pay about 30k USD a year. If a few companies contributed at that scale to the Foundation that's at least a couple of full-time developers. And if you disagree with Andrei and Walter choices about priorities you know you can just direct where the money should be spent as we are with SAoC.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Tuesday, 4 September 2018 at 02:24:25 UTC, Manu wrote: On Mon, 3 Sep 2018 at 18:45, Laeeth Isharc via Digitalmars-d wrote: On Monday, 3 September 2018 at 17:15:03 UTC, Laurent Tréguier wrote: > On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M > Davis wrote: >> Most of the work that gets done is the stuff that the folks >> contributing think is the most important - frequently what >> is most important for them for what they do, and very few >> (if any) of the major contributors use or care about IDEs >> for their own use. And there's tons to do that has nothing >> to do with IDEs. There are folks who care about it enough >> to work on it, which is why projects such as VisualD exist >> at all, and AFAIK, they work reasonably well, but the only >> two ways that they're going to get more work done on them >> than is currently happening is if the folks who care about >> that sort of thing contribute or if they donate money for >> it to be worked on. Not long ago, the D Foundation >> announced that they were going to use donations to pay >> someone to work on his plugin for Visual Studio Code: >> >> https://forum.dlang.org/post/rmqvglgccmgoajmhy...@forum.dlang.org >> >> So, if you want stuff like that to get worked on, then >> donate or pitch in. >> >> The situation with D - both with IDEs and in general - has >> improved greatly over time even if it may not be where you >> want it to be. But if you're ever expecting IDE support to >> be a top priority of many of the contributors, then you're >> going to be sorely disappointed. It's the sort of thing >> that we care about because we care about D being >> successful, but it's not the sort of thing that we see any >> value in whatsoever for ourselves, and selfish as it may >> be, when we spend the time to contribute to D, we're >> generally going to work on the stuff that we see as having >> the most value for getting done what we care about. And >> there's a lot to get done which impacts pretty much every D >> user and not just those who want something that's >> IDE-related. >> >> - Jonathan M Davis > > The complaints I have is exactly why I'm myself maintaining > plugins for VSCode, Atom, and others soon. Don't worry, I > still > think D is worth putting some time and effort into and I know > actions generally get more things done than words. > I also know that tons of stuff is yet to be done in regards > to > the actual compilers and such. > > It just baffles me a bit to see the state of D in this > department, when languages like Go or Rust (hooray for yet > another comparison to Go and Rust) are a lot younger, but > already have what looks like very good tooling. > Then again they do have major industry players backing them > though... Why is Go's IDE support baffling? It was a necessity to achieve Google's commercial aims, I should think. " The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." – Rob Pike I don't know the story of Rust, but if I were working on a project as large as Firefox I guess I would want an IDE too! Whereas it doesn't seem like it's so important to some of D's commercial users because they have a different context. I don't think it's overall baffling that D hasn't got the best IDE support of emerging languages. The people that contribute to it, as Jonathan says, seen to be leas interested in IDEs and no company has found it important enough to pay someone else to work on it. So far anyway but as adoption grows maybe that will change. It's been a key hurdle for as long as I've been around here. I've been saying for 10 years that no company I've ever worked at can take D seriously without industry standard IDE support. My feeling is that we have recently reached MVP status... that's a huge step, 10 years in the making ;) I think it's now at a point where more people *wouldn't* reject it on contact than those who would. But we need to go much further to make developers genuinely comfortable, and thereby go out of their way to prefer using D than C++ and pitch as such to their managers. Among all developers I've demo-ed or introduced recently, I can say for certain that developer enthusiasm is driven by their perception of the tooling in the order of 10x more than the language. That's only because you insist on working for compani
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 16:07:21 UTC, RhyS wrote: On Monday, 3 September 2018 at 15:41:48 UTC, Laurent Tréguier wrote: Yes. It almost sounds like a smooth experience would be a bad thing to have, especially with the classic "you don't need an IDE anyway" speech. Editing experience seems often dismissed as unimportant, when it's one of the first things new users will come across when trying out D. First impressions can matter a lot. I didn't give a you don't need an IDE speech, and I didn't say a smooth experience was a bad thing. But in my experience a strong reality orientation leads to good things coming out of life and telling the universe it should be something different from what it is is a recipe for misery and suffering, and why would you do that to yourself? So if you want the world to be different, come up with a plan. It could be I am going to donate X dollars a month to the Foundation to fund IDE development, or if could be figuring out how you can help with the work in whatever way. But just grumbling - I really think that mistakes the nature of the situation, and not to mention human psychology. You can accomplish things with a vision that's thought through and inspires others. Negativity is part of being creative but not if you stop there. Its the same issue why Linux as a Desktop has been stuck with almost no growth. Its easy to break things ( nvidia graphical driver *lol* ), too much is so focused on the Cli that people who do have a issue and are not system users quick run into a flooding swamp. Too much resources split among too many distributions, graphical desktops etc. Choice is good but too much choice means projects are starved for resources, comparability are issues, bugs are even more present, ... Chrome books and Android seem to be doing okay. I run Linux on the desktop and have done full-time since 2014. Maybe you're right that it's not for everyone at this point. And so ? There just wasn't a path for people to put effort into making it utterly easy for non technical people beyond a certain point. Does that mean Linux or Linux on the desktop has failed? I don't think so. It's just not for everyone. It's interesting to see Microsoft making it possible to run Linux on Windows - turns out a minority audience can be an important audience. A good example being the resources going into DMD, LDC, GDC... 3 Compilers for one language, when even well funded languages stick to one compiler. And now some people think its a good idea to have DMD also cross compile because "its not hard to do". No, maybe not but who will do all the testing, what resources are going to spend when things do not work for some users ( and the negative impact on their experience )... Its a long list but people do not look past this. It sounds like fun, lets think / or do it. What resources do you think go into GDC? I think Iain would love to hear about all these resources because I am not sure he has been made aware of them because they don't exist beyond him and possibly a tiny number of others helping in part at certain stages. Its just so frustrating that a lot of people here do not understand. Most programmers are not open-source developers, they are not coding gods, they are simply people who want things to good smooth. Install compiler, install good supported graphical IDE ( and no, VIM does not count! ), read up some simple documentation and off we go... We are not looking to be bug testers, core code implementer's, etc... Sure, and probably most people would be better off at this point using a language that makes getting started easy. One doesn't need to appeal to most people to succeed. That's just a pragmatic statement of the obvious. In time it will change but j don't see how recognising your observation could rationally lead anyone to do something differently from what they would have done before. To change the world you need a goal and a first cut at a plan for getting there. Whether the goal is entirely realistic is much less important than having a plan to begin. And I speak from experience here having at certain points not much more than that. Selfish, ... sure ... but this is how D gain more people. The more people work with your language, the more potential people you have that slowly are interested in helping out. I disagree. At this point the way for D to appeal to more people is to increase its appeal just a bit more to those who are already on the cusp of using D or would be if they had looked into it and to those who use D already in some way but could use it more. The way for D to appeal to more people is not to address the complaints of those who spend more time writing on the forum grumbling but don't use it much, because in my experience you do much better appealing to the people who are your best customers than to those who tell you if only you could do X there
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 17:15:03 UTC, Laurent Tréguier wrote: On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote: Most of the work that gets done is the stuff that the folks contributing think is the most important - frequently what is most important for them for what they do, and very few (if any) of the major contributors use or care about IDEs for their own use. And there's tons to do that has nothing to do with IDEs. There are folks who care about it enough to work on it, which is why projects such as VisualD exist at all, and AFAIK, they work reasonably well, but the only two ways that they're going to get more work done on them than is currently happening is if the folks who care about that sort of thing contribute or if they donate money for it to be worked on. Not long ago, the D Foundation announced that they were going to use donations to pay someone to work on his plugin for Visual Studio Code: https://forum.dlang.org/post/rmqvglgccmgoajmhy...@forum.dlang.org So, if you want stuff like that to get worked on, then donate or pitch in. The situation with D - both with IDEs and in general - has improved greatly over time even if it may not be where you want it to be. But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves, and selfish as it may be, when we spend the time to contribute to D, we're generally going to work on the stuff that we see as having the most value for getting done what we care about. And there's a lot to get done which impacts pretty much every D user and not just those who want something that's IDE-related. - Jonathan M Davis The complaints I have is exactly why I'm myself maintaining plugins for VSCode, Atom, and others soon. Don't worry, I still think D is worth putting some time and effort into and I know actions generally get more things done than words. I also know that tons of stuff is yet to be done in regards to the actual compilers and such. It just baffles me a bit to see the state of D in this department, when languages like Go or Rust (hooray for yet another comparison to Go and Rust) are a lot younger, but already have what looks like very good tooling. Then again they do have major industry players backing them though... Why is Go's IDE support baffling? It was a necessity to achieve Google's commercial aims, I should think. " The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." – Rob Pike I don't know the story of Rust, but if I were working on a project as large as Firefox I guess I would want an IDE too! Whereas it doesn't seem like it's so important to some of D's commercial users because they have a different context. I don't think it's overall baffling that D hasn't got the best IDE support of emerging languages. The people that contribute to it, as Jonathan says, seen to be leas interested in IDEs and no company has found it important enough to pay someone else to work on it. So far anyway but as adoption grows maybe that will change.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 11:32:42 UTC, Chris wrote: On Sunday, 2 September 2018 at 12:07:17 UTC, Laeeth Isharc wrote: That's why the people that adopt D will inordinately be principals not agents in the beginning. They will either be residual claimants on earnings or will have acquired the authority to make decisions without persuading a committee that makes decisions on the grounds of social factors. If D becomes another C++ ? C++ was ugly from the beginning (in my personal subjective assessment) whereas D was designed by people with good taste. That's why it appeals inordinately to people with good taste. [snip] Be that as it may, however, you forget the fact that people "with good taste" who have (had) an intrinsic motivation to learn D are also very critical people who take no bs, else they wouldn't have ended up using D in the first place. Since they've already learned a lot of concepts etc. with D over the years, it's technically easy for them to move on to either an easier language or one that offers more or less the same features as D. I don't think so. If we are talking about the set of technically very capable people with an aesthetic sense then I don't think easier or feature set in a less beautiful way is appealing. This is based on revealed preference, because the conversations I have with technically very capable people that know many other languages as well or better than D go like "what compensation are you expecting? X. But if it's to write D, I can be flexible" and so on. Template meta-programming in D is quite simple. C++ has many of the features that D has. Therefore it's easy to do template meta-programming in C++, and just as easy for others to read your code in C++ as D? I don't think so. Having learnt the concepts in D and that it can be beautiful and easy kind of ruins you for inferior approaches. BTW I was grumbling about some C# wrapper code written manually. It talks to a C style API (connected to an internal C++ code base developed before I became involved). So you have a low level C# side declaration of the C function that returns an exception string by argument. Then you have a C# declaration of a wrapper function that throws an exception if the exception string is not empty. Then you have a layer on top that puts the class back together. Then you have a high level wrapper layer. Then you have the bit that talks to Excel. I thought surely there must be decent code generation possibilities in C#. It's not too bad as a language. I looked it up. Microsoft say use HTML templates. Well, okay... but I'm not sure I like the trade-off of having to do stuff like that versus having to deal with some pain at the command-line now and then. So once they're no longer happy with the way things are, they can dive into a any language fast enough for the cost of transition to be low. You're making an implicit empirical statement that I don't believe to be accurate based on my experience. I would say if a representative programmer from the D community decides the costs no longer offset the benefits then sure they can learn another language because the representative programmer here is pretty talented. But so what?
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 11:32:42 UTC, Chris wrote: On Sunday, 2 September 2018 at 12:07:17 UTC, Laeeth Isharc wrote: That's why the people that adopt D will inordinately be principals not agents in the beginning. They will either be residual claimants on earnings or will have acquired the authority to make decisions without persuading a committee that makes decisions on the grounds of social factors. If D becomes another C++ ? C++ was ugly from the beginning (in my personal subjective assessment) whereas D was designed by people with good taste. That's why it appeals inordinately to people with good taste. [snip] Be that as it may, however, you forget the fact that people "with good taste" who have (had) an intrinsic motivation to learn D are also very critical people who take no bs, else they wouldn't have ended up using D in the first place. Since they've already learned a lot of concepts etc. with D over the years, it's technically easy for them to move on to either an easier language or one that offers more or less the same features as D. So once they're no longer happy with the way things are, they can dive into a any language fast enough for the cost of transition to be low. One has to be practical too. Yes! And being practical involves recognising different objectives, starting points and considerations apply to different situations and contexts. Programming involves more than just features and concepts. Good, out of the box system integration (e.g. Android, iOS) is important too and he who ignores this simple truth will have to pay a high price. Important for whom? It depends a lot! Ask Sociomantic, Bastian, Weka if the lack of Android or iOS integration is a big problem for them, and I don't think you will get the answer that it is important. For what I am doing, Android or iOS would be nice, but it doesn't need to be out of the box, and you can do quite a lot on Android already. I compiled ldc on my Huawei watch, which I never expected to be possible though given it has 4 Gig of RAM it's not that surprising. JNI is not that bad though could certainly be made easier with a bit of work. And I haven't tried, but I guess you could write the GUI stuff in Python or Lua for a simple app and do the heavy lifting with D. Of course for the ecosystem generally yes it matters. why developers of new languages are so keen on giving users a smooth experience when it comes to app development and cross compilation which leads me to the next point: IDEs. D has never been about smooth experiences! That's a commercial benefit if you think that hormesis brings benefits and you are not looking for programmers of the trained-monkey, strap a few APIs together type. It's a question of developmental stages too. I was a late developer as a person, but then I continued to develop into my 30s and perhaps 40s too. For human beings there are different kinds of people and implicit life strategies and natural fits with niches. Some are quick to grow up, but stop developing sooner and others mature more slowly but this process may continue long after others are done. I'm not saying a computer language is like a human being, but it is in part an organic phenomenon and social institutions develop according to their own logic and rhythm in my experience of studying them. D is a late developer, and I think that's because it is a tremendously ambitious language. What use case is D intended to target? Well it's not like that - it's a general purpose programming language at a time when people have given up on that idea and think that it simply must be that you pick one tool for the job and couldn't possibly have a tool that does many different kind of things reasonably well. So the kind of use cases D is suited for depends much more on the capabilities and virtues of the people using it than is the case for other languages. (In truth in a negative sense that's true also of other languages - Go was designed to be easy to learn and to use for people who didn't have much programming experience). No. You don't need an IDE to develop in D Indeed, and much less so than with some other languages because you can understand the code that's out of focus more easily and hold more of it in your head and reason about it. I personally use Sublime and vim, but tools are very personal because problems are different and people think differently and there's not much upside in engaging in a holy war about tools. However, an IDE can a) make coding comfortable and b) boost your productivity. Sure - in can do for some people in some cases. to a): maybe you just grow tired of the text editor & cli approach and you just want to click a few buttons to fix imports or correct typos and be done with it, and as to b): all this helps to boost your productivity, especially when you can easily set up an app or a web service with a few mouse
Re: DStep rocks [was Example of using C API from D?]
On Sunday, 2 September 2018 at 17:49:45 UTC, Russel Winder wrote:
On Sun, 2018-09-02 at 18:28 +0100, Russel Winder wrote:
[…]
It turns out that the GIR file is not usable, and so the
girtod route is not feasible. I shall try the DStep route.
Failing that it seems there is
https://github.com/WebFreak001/fontconfig-d
which is a manual transform of a snapshot of the C API, so not
an
ideal
way, but a definite backstop position. It seems someone has
trodden
the
"using Fontconfig in D" path before me.
I compiled DStep master/HEAD (v0.2.3-16-g1308991) against LLVM
6.0 and it seems to have done a rather splendid job of creating
a D binding to Fontconfig. Low-level obviously, but Fontconfig
is seriously low level anyway.
Now to work out how to make the project auto generate this D
module so as to avoid having it in the repository, and
potentially inconsistent with the platform in use.
You could also look at dpp. That's worked for most things I tried
and was written in part to avoid the problem of macros changing
behaviour at build time.
Example here:
https://run.dlang.io/?compiler=dmd=%23include%20%0Avoid%20main()%20%7B%0A%20%20%20%20printf("Hello%20dpp.");%0A%7D
https://github.com/atilaneves/dpp
Re: extern __gshared const(char)* symbol fails
On Friday, 31 August 2018 at 18:49:26 UTC, James Blachly wrote: On Friday, 31 August 2018 at 17:18:58 UTC, Neia Neutuladh wrote: On Friday, 31 August 2018 at 06:20:09 UTC, James Blachly wrote: Hi all, ... When linking to this library from D, I have declared it as: extern __gshared const(char)* seq_nt16_str; ***But this segfaults when I treat it like an array (e.g. by accessing members by index).*** I believe this should be extern extern(C)? I'm surprised that this segfaults rather than having a link error. A bare `extern` means "this symbol is defined somewhere else". `extern(C)` means "this symbol should have C linkage". I am so sorry -- I should have been more clear that this is in the context of a large header-to-D translation .d file, so the whole thing is wrapped in extern(C) via an extern(C): at the top of the file. In case you weren't aware of it, take a look at atilaneves DPP on GitHub or code.dlang.org. auto translates C headers at build time and mostly it just works. If it doesn't, file an issue and in time it will be fixed.
Re: This thread on Hacker News terrifies me
On Sunday, 2 September 2018 at 06:25:47 UTC, Nick Sabalausky (Abscissa) wrote: On 08/31/2018 07:47 PM, Jonathan M Davis wrote: However, many teachers really aren't great programmers. They aren't necessarily bad programmers, but unless they spent a bunch of time in industry before teaching, odds are that they don't have all of the software engineering skills that the students are going to need once they get into the field. And most courses aren't designed to teach students the practical skills. This is why we really should bring back the ancient practice of apprenticeship, that we've mostly gotten away from. Doesn't have to be identical to the old system in every detail, but who better to teach XYZ to members a new generation than those who ARE experts at XYZ. Sure, teaching in and of itself is a skill, and not every domain expert is a good teacher. But like any skill, it can be learned. And after all: Who really stands a better chance at passing on expertise?: A. Someone who already has the expertise, but isn't an expert in teaching. B. Someone who is an expert at teaching, but doesn't posses what's being taught anyway. Hint: No matter how good of a teacher you are, you can't teach what you don't know. Heck, if all else fails, pair up domain experts WITH teaching experts! No need for any jacks-of-all-trades: When people become domain experts, just "apprentice" them in a secondary skill: Teaching their domain. Sounds a heck of a lot better to me than the ridiculous current strategy of: Separate the entire population into "theory" (ie, Academia) and "practical" (ie, Industry) even though it's obvious that the *combination* of theory and practical is essential for any good work on either side. Have only the "theory" people do all the teaching for the next generation of BOTH "theory" and "practical" folks. Students then gain the "practical" side from...what, the freaking ether From the industry which doesn't care about quality, only profit??? From the "theory" folk that are never taught the "practical"??? From where, out of a magical freaking hat?!?!? I agree. I have been arguing the same for a few years now. https://www.quora.com/With-6-million-job-openings-in-the-US-why-are-people-complaining-that-there-are-no-jobs-available/answer/Laeeth-Isharc?srid=7h We de-emphasized degrees and those are information only unless for work permits it is a factor (and sadly it is) and also are open to hiring people with less vocationally relevant degrees. A recent hire I made was a chap who studied music at Oxford and played the organ around the corner. His boss is a Fellow in Maths at Trinity College, Cambridge and us very happy with him. And we started hiring apprentices ourselves. The proximate trigger for me to make it happen was a frustrating set of interviews with more career-oriented people from banks for a support role in London. "Is it really asking too much to expect that somebody who works on computers should actually like playing with them ?" So we went to a technical college nearby where someone in the group lives and we made a start this year and in time it will grow. The government introduced an apprenticeship programme. I don't think many people use it yet because it's not adapted to commercial factors. But anything new is bad in the first version and it will get better.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Saturday, 1 September 2018 at 12:33:49 UTC, rjframe wrote: On Thu, 23 Aug 2018 15:35:45 +, Joakim wrote: * Language complexity Raise your hand if you know how a class with both opApply and the get/next/end functions behaves when you pass it to foreach. How about a struct? Does it matter if it allows copying or not? The language was built because C++ was deemed too complex! Please see the thread about lazy [1] for a case where a question actually has an answer, but nobody seems to know it (and the person who does know it is hard pressed to explain the nuance that triggers this). By this rationale, C++ should be dead by now. Why do you think it's fatal to D? It's worth noting that C++ isn't always chosen for its technical merits. It's a well-known language whose more or less standard status in certain domains means it's the default choice; C++ is sometimes used for projects in which Stroustrup would say it's obviously the wrong language for the job. D is far more likely to require justification based on technical merit. If D becomes another C++, why bother taking a chance with D when you can just use C++, use a well-supported, commonly-used compiler, and hire from a bigger pool of jobseekers? That's why the people that adopt D will inordinately be principals not agents in the beginning. They will either be residual claimants on earnings or will have acquired the authority to make decisions without persuading a committee that makes decisions on the grounds of social factors. If D becomes another C++ ? C++ was ugly from the beginning (in my personal subjective assessment) whereas D was designed by people with good taste. That's why it appeals inordinately to people with good taste. In Hong Kong we had some difficulty hiring a support person for a trading floor. Spoke in some cases to the most senior person in HK for even large and well-known funds (small office in this case) and they simply were not good enough. Thanks to someone from the D community I met a headhunter who used to be at Yandex but realized the money was better as a headhunter. They don't have many financial clients I think, don't have connections on the talent side in finance. But the runners up were by far better than anyone we had found through other sources and the best was outstanding. Good job, I said. It's funny that the person we hired came from a big bank when other headhunters are looking in the same place and know that world better. By the way, how many people did you interact with to find X ? In London if a headhunter puts 10 people before you and you are really pretty happy then that's a good day. He said two hundred ! And they had to come up with a hiring test too. So the basic reason they could find good people in technology in finance when others couldn't is that they have much better taste. Do you see ? The others knew many more people, they had experience doing it, and somebody who had to persuade a committee would have found it hard to justify. Programming ability follows a Pareto curve - see the best and the rest. There might be many more C++, Python and C# programmers. The incidence of outstanding ones is lower than in the D community for the very reason that only someone obtuse or very smart will learn D for career reasons - intrinsic motivation draws the highest talent. It depends if your model of people doing work is an army of intelligent trained monkeys or a force made up of small elite groups of the best people you have ever worked with. Of course the general of the trained monkey army is going to be difficult to persuade. And so ? On the other hand, someone who is smart and has good taste and has earned the right to decide - D is a less popular language that has fewer tutorials and less shiny IDE and debugger support. Well if you're a small company and you are directly or in effect a proxy owner of the residual (ie an owner of some kind) it's a pragmatic question and saying nobody got fired for buying IBM - that's missing the point because the success is yours and the failure is yours and you can't pass the buck. The beauty of being the underdog is that it's easy to succeed. You don't need to be the top dog, and in fact it's not strategically wise to do something that might think you stand a chance - let them think what they want. The underdog just needs to keep improving and keep getting more adoption, which I don't have much doubt is happening. Modern people can be like children in their impatience sometimes! I've only been programming since 1983 so I had the benefit of high level languages like BBC BASIC, C, a Forth I wrote myself, and Modula 3. And although I had to write a disassembler at least I has assemblers built in. Programming using a hex keypad is not that satisfying after a while. It takes a long time to develop a language, its ecosystem and community. An S curve is quite
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 31 August 2018 at 09:37:55 UTC, Chris wrote: On Wednesday, 29 August 2018 at 23:47:11 UTC, Laeeth Isharc wrote: On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote: 9. I hope D will be great again Are you someone who lives by hope and fears about things that have a meaning for you? Or do you prefer to take action? If the latter, what do you think might be some small step you could take to move the world towards the direction in which you think it should head. My experience of life is that in the end one way and another everything one does, big or small, turns out to matter and also that great things can have quite little beginnings. So what could you do towards the end you hope for ?
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Monday, 27 August 2018 at 20:15:03 UTC, Ali wrote: On Monday, 27 August 2018 at 19:51:52 UTC, 12345swordy wrote: On Monday, 27 August 2018 at 18:20:04 UTC, Chris wrote: Then the D Foundation should work on it. Easier said then done. You can't go around demanding people to build factories without addressing the issues that comes with building factories, such as the big question of how is it going to be payed to be built. -Alex No one is (and no one should be) demanding anything, hoping maybe.. Walter, wants to build D, and he is doing what he can to continue building it Andrei and many others joined him If we are sharing our opinion, its not coming from any sense of entitlement, we are sharing our opinion, because the builders, provided the platform for us to voice our opinion And again, because I keep repeating this, if they want more donations, I think talking more about the future plans will help, D currently neither have a larger user base, or an ambitious future plan, it make sense that they are not getting a lot of donations, they are not really making it attractive to donate I think that most current donors are probably incentivized by negative factors, or negatively motivated, they are probably afraid D's Development will stop or they feel guilty for using the language and not providing much back I dont think many donors are doing so because they are excited about the future Nothing seriously wrong about negative motivation, it works, but positive motivation is off I donate to the D Foundation via my personal consulting company though it is listed under the name of Symmetry Investments. I see that I am the second biggest donor after Andrei. I think I can have more insight into my motivations than you can, and I can say that I am motivated by enthusiasm about commercial benefits and it wouldn't have occurred to me to donate out of fear, as you suggest. If one makes a mistake I am in a business where the custom is that one fixes the mistake and moves on. Suppose it were to turn out to have been a mistake to use D. Well I have made costlier mistakes then that this year and it's only August. And, as if happens, I don't think it was a mistake. So you may think what you wish about the motivations of donors, but I think you might do well to base your views on evidence not imaginings if you wish to be taken seriously :)
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote: On Tuesday, 28 August 2018 at 08:44:26 UTC, Chris wrote: When people choose a programming language, there are several boxes that have to be ticked, like for example: - what's the future of language X? (guarantees, stability) - how easy is it to get going (from "Hello world" to a complete tool chain) - will it run on ARM? - will it be a good choice for the Web (e.g. webasm)? - how good is it at data processing / number grinding - etc. I don't know if all their claims are 100% true, but let that sink in for a while: https://julialang.org/. Julia is great. I don't see it as a competitor to D but for us one way researchers might access libraries written in D. One could do quite a lot in it, but I don't much fancy embedding Julia in Excel for example, though you could. Or doing DevOps in Julia. Perhaps more of a Matlab substitute. Look around and you can find people grumpy about any language that's used. http://www.zverovich.net/2016/05/13/giving-up-on-julia.html Languages really aren't in a battle to the death with each other. I find this zero-sum mindset quite peculiar.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Sunday, 26 August 2018 at 19:34:39 UTC, Manu wrote: On Sun, 26 Aug 2018 at 12:10, RhyS via Digitalmars-d wrote: On Sunday, 26 August 2018 at 18:18:04 UTC, drug wrote: > It's rather funny to see how one man who forced to program in > programming language he doesn't like can triggers comments > from > lurkers that they don't like D too. No offense. > D is in great form and is getting much better and better and > I'd like to ask D community to continue their good work and > make D great again. Most people lurking here are people that WANT to use D but are offset by the issues. D is not bad as a language but it has issue. Their are issues at every step in the D eco system and each of those create a barrier. Its those same issues that never seem to get solved and are secondary citizens compared to adding more "future" features or trying to Up-one C++... Its not BetterC or static if or whatever new feature of the month, that brings in new people. You can advertise D as much as you want, but when people download D and very few people stay, is that not a hint... The fact that only recently the D Poll pointed out that most people are using VSC and not VS. I am like "what, you only figure that out now". Given the mass popularity of VSC... That alone tells you how much the mindset of D is stuck in a specific eco space. Industry tends to use VS, because they fork-out for the relatively expensive licenses. I work at a company with a thousand engineers, all VS users, D could find home there if some rough edges were polished, but they *absolutely must be polished* before it would be taken seriously. It is consistently expressed that poor VS integration is an absolute non-starter. While a majority of people (hobbyists?) that take an online poll in an open-source community forum might be VSCode users, that doesn't mean VS is a poor priority target. Is D a hobby project, or an industry solution? I vote the latter. I don't GAF about peoples hobbies, I just want to use D to _do my job_. Quality VS experience is critical to D's adoption in that sector. Those 1000 engineers aren't reflected in your poll... would you like them to be? Do you see a path from here to there that's planned? I think it's very difficult winning over people that expect to see the same degree of polish as in a project thats older and has much more commercial support. In other words as a thought experiment if everyone in the community were to stop and work only on VS and debugging polish, how many years would it be before your colleagues were willing to switch? I think it might be a while. I'm not suggesting that polish isn't worth working on, but one might be realistic about what may be achieved. I think D is a classic example of Clayton Christensen's Innovators Dilemma. In the beginning a certain kind of innovation starts at the fringe. It's inferior alongst some dimensions compared to the products with high market share and so it gets kind of ignored. But for some particular reasons it has a very high appeal to some groups of people and so it keeps growing mostly unnoticed and over tiny expands the niches where it is used. This can keep going for a long time. And then something in the environment changes and it's like it becomes an overnight success. For American cars it was the oil price shock of the 1970s. Japanese cars then might have been seen as inferior but they were energy efficient and they worked. I think it's possible that for D this will arise from the interaction of data set sizes growing - storage prices drop at 40% a year and somehow people find a way to use that cheaper storage - whilst processing power and memory latency and bandwidth is a sadder tale. But it might be something else. So people who say that there is no place for D in the kind of work they do might sometimes be right. Frustrating because if only the polish were there, but polish is a lot of work and not everyone is interested in it. They might not be right about broader adoption because the world is a very big place,most people don't talk about their work, and because some of the factors that present huge obstacles in some environments simply don't apply in others. Thinking about frustrations as an entrepreneurial challenge may be ultimately more generative than just hoping someone will do something. I do wonder if there isn't an opportunity in organising people from the community to work on projects that enterprise users would find valuable but that won't get done otherwise. Organising the work might not be difficult, but it takes time and attention, which enterprise users are not long on.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Sunday, 26 August 2018 at 08:40:32 UTC, Andre Pany wrote:
On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright
wrote:
On 8/25/2018 3:52 AM, Chris wrote:
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright
wrote:
Every programmer who says this also demands new (and
breaking) features.
"Every programmer who..." Really?
You want to remove autodecoding (so do I) and that will break
just about every D program in existence. For everyone else,
it's something else that's just as important to them.
For example, Shachar wants partially constructed objects to be
partially destructed, a quite reasonable request. Ok, but
consider the breakage:
struct S {
~this() {}
}
class C {
S s;
this() nothrow {}
}
I.e. a nothrow constructor now must call a throwing
destructor. This is not some made up example, it breaks
existing code:
https://github.com/dlang/dmd/pull/6816
If I fix the bug, I break existing code, and apparently a
substantial amount of existing code. What's your advice on how
to proceed with this?
In the whole discussion I miss 2 really important things.
If your product compiles fine with a dmd version, no one forces
you to update to the next dmd version. In the company I work
for, we set for each project the DMD version in the build
settings. The speed of DMD releases or breaking changes doesn't
affect us at all.
Maybe I do not know a lot open source products but the amount
of work which goes into code quality is extremely high for the
compiler, runtime, phobos and related products. I love to see
how much work is invested in unit tests and also code style.
DMD (and LDC and GDC) has greatly improved in the last years in
various aspects.
But I also see that there is a lot of work to be done. There
are definitely problems to be solved. It is sad that people
like Dicebot leaving the D community.
Kind regards
Andre
Dicebot should speak for himself as he wishes. But I was
entertained by the simultaneous posting by someone else of a blog
post from a while back with him asking for comments on the early
release of dtoh, a tool intended in time to be integrated into
DMD given its design.
I don't think he was very happy about the process around DIP1000
but I am not myself well placed to judge.
In any case, languages aren't in a death match where there can be
only one survivor. Apart from anything else, does anyone really
think less code will be written in the future than in the past or
that there will be fewer people who write code as part of what
they do but aren't career programmers?
I probably have an intermediate experience between you and Jon
Degenhardt on the one hand and those complaining about breakage.
Some of it was self-inflicted because on the biggest project we
have 200k SLoC a good part of which I wrote myself pretty quickly
and the build system has been improvised since and could still be
better. The Linux builder is a docker container created nightly
and taking longer to something similar on Windows side, where
funnily enough the bigger problems are. Often in the past little
things like dub turning relative paths into absolute ones,
creating huge paths that broke DMD path limit till we got fed up
and decided to fix ourselves. (Did you know there are six extant
ways of handling paths on Windows?)
Dub dependency resolution has been tough. It might be better
now. I appreciate it's a tough problem but somehow eg maven is
quick (it might well cheat by solving an easier problem).
And quite a lot of breakage in vibe. But nobody forces you to
use vibe and there do exist other options for many things.
Overall though, it's not that bad depending on your use case.
Everything has problems but also everyone has a different kind of
sensitivity to different kinds of problems.
For me, DPP makes a huge difference because I now know it's
pretty likely I can just #include a C library if that's the best
option and in my experience it mostly just works.
The plasticity, coherence and readability of D code dominates the
difficulties for quite a few things I am doing. Might not be the
case for others because everyone is different. Cost of my time
in the present context dominates cost of several programmers'
time but I don't think thats a necessary part of why D makes
sense for some things for us. I think by the end of this year we
might have eleven people including me writing D at least
sometimes, from only me about 18 months ago. That's people
working from the office including practitioners who write code
and add a handful of remote consultants who only write D to that.
There's no question from my perspective that D is much better
than a year ago and unimaginably better from when I first picked
it up in 2014. One can't be serious suggesting that D isn't
flourishing as far as adoption goes.
The forum really isn't the place to assess what people using the
language at work feel.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 10:52:04 UTC, Chris wrote: On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote: On 8/24/2018 6:04 AM, Chris wrote: For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. Every programmer who says this also demands new (and breaking) features. "Every programmer who..." Really? Sorry, but this is not an answer. The fact remains that D is in danger of becoming unusable for real world programming. Earlier this year I had to "unearth" old Python code from 2009 (some parts of the code were even older). And you know what? It still worked! The same goes for Java code I wrote for Java 1.5. If you want to achieve something similar with D you have to write code that is basically C code, i.e. you shouldn't use any of the nicer or more advanced features, because they might break with the next dmd release - which kind of defeats the purpose. Also, a. adding new features doesn't necessarily mean that old code has to stop working and b. the last breaking change I would've supported was to get rid of autodecode, but that was never done and now it seems too late, yet it would have been a change of utmost importance because string handling is everywhere these days. But maybe it would have been too much tedious work and no real intellectual challenge, so why bother. Other languages do bother, however. You may brush our concerns aside with a throw away comment like the one above, but I'm not the only one who doesn't consider D for serious stuff anymore. As has been said before, none of the problems are unfixable - but if your answer is indicative of the D leadership's attitude towards concerned (longtime) users, then don't be surprised that we go back to Java and other languages that offer more stability. I still have maximum respect for everything you, Andrei and the community have achieved. But please don't throw it all away now. And yet some of the heaviest users of D have said in public 'please break our code". I wonder why that could be. It's also not terribly surprising that D2 code from 2009 doesn't always compile when you consider the release date of the language. Do you think it's a bad thing that imports were fixed, for example? That broke a lot of old code. "If you want to achieve something similar with D you have to write code that is basically C code, i.e. you shouldn't use any of the nicer or more advanced features, because they might break with the next dmd release - which kind of defeats the purpose. " I don't think this is true. Have slices, arrays, associative arrays and so on broken ? On the other hand D written like C that didn't get the imports right would have broken when the module system was corrected. This is a good thing. "Every programmer who..." Really? Sorry, but this is not an answer. The fact remains that D is in danger of becoming unusable for real world programming." I don't think this is true either. It doesn't fit with my own experience and it doesn't fit with the growing enterprise adoption. That may be your personal perspective, but it's really hard to put yourself in the shoes of somebody in a very different situation that you have never encountered. There's intrinsically a tradeoff between different kinds of problems. Nassim Taleb writes about hormesis. I'm not sure that breakage of a non-serious kind is necessarily terrible. It might be terrible for you personally - that's not for me to judge. But it has the effect of building capabilities that have value in other ways. There are quite a few different sorts of concerns raised on this thread and they are linked by how people feel not by logic. I have a lot of respect for Shachar technically but I personally found the way he expressed his point of view a bit odd and unlikely to be effective in achieving whatever it is his goal was, also bearing in mind he doesn't speak for Weka. It might be helpful to go through the concerns and organise them based on logical ordering because an outburst of emotion won't translate in itself into any kind of solution.
Re: D is dead
On Thursday, 23 August 2018 at 07:27:56 UTC, JN wrote: On Thursday, 23 August 2018 at 06:34:01 UTC, nkm1 wrote: The only real problem with D is that it's a language designed with GC in mind, yet there are numerous attempts to use it without GC. Also, supporting GC-less programming gets in the way of improving D's GC (which is pretty damn bad by modern standards). That's the only real technical problem. I think a large part is defining what kind of users D wants to attract. There are two main groups of programmers, and there is a vast rift between those groups. One group is people who are closer to OOP programming and languages such as Java, C#, Javascript. These people are OK with things like garbage collectors and in cases where it matters, have learned to work around it (avoid allocations in hot loops, etc.). I feel like D1 was attractive for these people for having the convenience they are used to from their languages (batteries included standard library, automatic memory management), with additional features that their language/environments struggle with (C interop, native binaries), everything packed with a very clean syntax. The second group are the C/C++ programmers, the 'zero cost abstraction' group. For this group of programmers, any overhead is a disadvantage, garbage collector is unusable for most usecases (whether true or not, that's the perception). D1 appealed to those people, for having a clean syntax and the features they know without having to include the monster that is Boost. Battlefield was different back then too. Around D2 came the competition, be it Rust, Go, or C++17. Go is appealing more to the first group of programmers, since it has a GC, and mostly sticks to webservice usage. Rust is heavily appealing to the zero-cost abstraction group and C++17 obviously appeals to C++ folks. Is it possible to make a language that both groups would be happy to use? Perhaps, or perhaps the gap is too wide. Is adding features like dip1000 and betterC spreading ourselves too thin? Perhaps. Perhaps there are features that aren't really used, and should be reworked or cut from the language instead (has anyone ever used contracts?). D's not UNIX (DNU?), but the first rule of UNIX philosophy is "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new 'features'.". It may or may not be relevant here. BTW. on the offtopic note - the thread title doesn't look too good. Imagine being a newcomer, and the first thread you see on the forum is titled "D is dead". Not sure about your taxonomy. There are quite a few people involved in D who are native code C/C++ developers spiritually and by prior work focus who moved to D and don't mind, in fact maybe relish the GC. One might include Walter and Andrei in this. I don't want to speak for Atila but I would like to see his face if you tell him that he is deep down a Java programmer at heart, as I don't believe that's quite right. I don't think he despises the GC even though he has written libraries that make it easier not to use it. It's silly to think that languages are in a death match competition against each other in some zero-sum game because there's no justification for it. There have never been so many programmers in the world as today, and in twenty years i doubt there will be fewer. There have also never been as many practitioners who write code as part of their job doing something else as today. Furthermore the amount of code written depends on the extent to which one can express ones ideas efficiently in code. I personally would have programmed much less since 2014 if I had to write in a language I didn't find agreeable, and I would have hired fewer programmers too - quite a lot of code exists now that simply wouldn't exist without D. How can you possibly form an opinion on the different sorts of programmer ? Most programmers aren't active on social media and don't work for companies that talk in public about their work. Go for example just isn't a relevant alternative to what I am doing except perhaps for DevOps. It solves a different kind of problem and is intended to be used by a different sort of person - Google hire a lot of programmers without much experience and have to find a way to get useful work out off them. That's different from my own challenges. For me the relevant alternatives might be Julia and Python. And even then they aren't very close substitutes. Implicitly D is even a competitor for VBA because our little DSL written in D solves many of the problems VBA and Excel are used for in a much better way. One could have done that in many other languages too, but it is in D because it was originally written for another purpose and turns out it solves this problem too. There's a chap here with a family business where its PHP versus D. For Bastian it was a modern Pascal
Re: [OT] Leverage Points
On Monday, 20 August 2018 at 12:26:25 UTC, Laeeth Isharc wrote: On Monday, 20 August 2018 at 11:55:33 UTC, Joakim wrote: Finally, regarding leverage, I keep pointing out that mobile has seen a resurgence of AoT-compiled native languages, but nobody seems to be trying D out in that fertile terrain, other than me. I did try, but it's not exactly easy to make a complete app in D, even on Android. It would be great if there were some way to automatically wrap the APIs. Right now, the Android port is more suited for writing some performant libraries that run as part of an existing Android app. The kind of polish you're looking for will only come with early adopters pitching in to smooth out those rough edges. If we had autowrap for JNI and could dump the types and method prototypes as part of the pre-build process, what would the next stage be to be able to just call Android APIs from D and have them work? JNI isn't that bad (I know it's deprecated) and I used it already from D in a semi-wrapped way. So I wonder how much more work it would be to have autowrap for JNI. I didn't use reflection on the Java side because I wasn't wrapping that much code. Are there XML descriptions of Android APIs you could use to generate wrappers? For example, could we make something like this for D? https://github.com/opencollab/giws https://en.wikipedia.org/wiki/GIWS_(software) The above requires the user to specify the types in XML, but I guess you can dump them via reflection. I have done some work on wrapping given the types in the internal code below (which won't build by itself). It was written in a hurry and I didn't know Java, D, or JNI very well at the time: https://github.com/kaleidicassociates/import-java-d
Re: [OT] Leverage Points
On Monday, 20 August 2018 at 08:31:15 UTC, Dave Jones wrote: On Monday, 20 August 2018 at 03:04:30 UTC, Mike Parker wrote: On Sunday, 19 August 2018 at 19:52:44 UTC, Dave Jones wrote: What you need a blog post saying the GC has been made 4x faster. Stuff like that, hey we made D much better now, not stuff about some corporate user who does targeted advertising. If you look through the blog, you'll find posts like that. One of the most-viewed is titled, 'Find Was Too Damn Slow, So We Fixed It' [1]. There are a variety of posts that we've published. I started the series on Funkwerk last year because we needed more posts about D being used in production. Im not trying to be negative but if Nim or Rust released a blog post saying "We made find faster" is it going to get you to try them out? That is the wrong question to be asking. It isn't how branding works (just because D doesn't try and manufacture an image doesn't mean that that itself doesn't create a brand). A post like that is one element in a campaign that gets across what D is like as a language and a community. I would guess many people that have no attention of trying D might read that because it's an interesting topic covered in an interesting way. By far not every post needs to be a call to action, and in fact people that try to do that become extremely annoying and get filtered out. That's an old-fashioned approach to marketing that I don't think works today. Is it enough of an enticement to get over you preconceptions about those languages and to think maybe they are worth a try? I think the relevant question is at the margin of activation energy - the person poised on the edge, not the representative Reddit or Hacker News poster. D is a very practical general-purpose language, and that means most users over time will be in enterprises given that I guess most code is written in enterprises (or maybe academe - and lots of academic code isn't really open-sourced even if it perhaps should be). Large enterprises aren't going to be early adopters of things they didn't create themselves. And people in SMEs have a different calculus from the representative influential person that talks publicly about technology. Have you noticed too how people that actually use D in their business don't spend much time on forums? That's what Im trying to say. Im sure posts like that are popular within the D community but they are not going to make much headway bringing new users in. I disagree. I started using D before the blog, but it was that kind of thing that drew me in, and one way and another as a consequence more new users than me have been brought in. But the extension of that is that you need to have something enticing to write about and there seems to be very little happening at the moment. DPP is probably the most interesting thing happening atm. I think there is lots interesting happening. Dpp (No more manual writing of bindings); Android aarch64; web assembly; continuing improvements in C++ interop; Symmetry Autumn of Code; D running in Jupyter (it excites me, even if nobody else); opMove; the take-off of Weka (from what I have heard); Binderoo generating C# wrappers for D programmatically; a really quite useful betterC (you can use a lot of language and library now); betterC version of Phobos will keep growing thanks to Seb's work on testing; no-gc exceptions; DIP1000 and scope; LDC fuzzing and profile-guided optimisation; GDC moving towards inclusion in GCC finally; adoption of D in bioinformatics; other games companies following in Remedy's footsteps. I haven't even had time to follow forums or github much, but that's all just off the top of my head.
Re: [OT] Leverage Points
On Monday, 20 August 2018 at 11:55:33 UTC, Joakim wrote: "So how do you change paradigms? Thomas Kuhn, who wrote the seminal book about the great paradigm shifts of science, has a lot to say about that. In a nutshell, you keep pointing at the anomalies and failures in the old paradigm, you keep coming yourself, and loudly and with assurance from the new one, you insert people with the new paradigm in places of public visibility and power. You don’t waste time with reactionaries; rather you work with active change agents and with the vast middle ground of people who are open-minded." (Quoting from the article I think). Kuhn and Lakatos. Paradigm shifts don't take place when the dominant paradigm is defeated by logical or empirical means. Paradigm shifts take place when for some reason people say "how about we stop talking about that, and start talking about this instead". I think he described certain political changes in the Western World beginning in the mid to late 60s rather well. I don't think it describes how changes in the sphere of voluntary (non-political ie market and genuine civil society) activity unfold. Supposing it were a good idea (which it isn't), how would one be able to to insert people in places of public visibility and power who put forward a point of view that is very different from the prevailing one? Only via a program of entryism, and I don't think that in the end much good will come of that. So I think the original author has cause and effect the wrong way around (not too surprisingly because he is talking about things that relate to politics and activism). [NB one shouldn't mention the Club of Rome without mentioning what a failure their work was, and it was predictably and indeed predicted to be a failure for the exact same reasons it failed]. It isn't that you insert people representing the new paradigm in positions of influence and power. It is that people from the emerging new paradigm - which is nothing, a bunch of no-hopers, misfits and losers viewed from a conventional perspective - by virtue of the fact that it has something useful to say and has drawn highly talented people who recognise that start ever so slowly to begin things and eventually to accomplish things - still on the fringes - and over time this snowballs. After a while turns out that they are no longer on the fringes but right at the centre of things, in part because the centre has moved. The best illustration of this phenomenon was I think in a work of fiction - Neal Stephenson's Cryptonomicon. I never expected someone to write a novel based on a mailing list - the cypherpunks. It was about as surprising to me then as it would be to see Dlang - the movie - today. And of course that itself was an early indication that the ideas and ways of thinking represented by what was originally quite a small community were on the ascent. This pretty much reflects what Laeeth always says about finding principals who can make their own decisions about using D. "Places of public visibility and power" for D are commercial or open-source projects that attract attention for being well done or at least popular. Well - I understand what you mean, but I don't recognise this as being my point. Principals who can make their own decisions probably aren't today highly visible and visibly powerful. The latter comes much later on in the development of a project, movement or scene and if you're visible it's a tax that takes time away from doing real work. By the time you're on the front cover of Time or The Economist, it's as often as not the beginning of the end - at least for anything vital. We're doing both: most of the material on the D blog and my own D interviews are not with corporate representatives. We could stand for more of the latter though, especially the big successes, because people are more influenced by them. I'm not saying it's a bad thing to go for big stories. But it's a mistake to place the attention people today naturally tend to. It doesn't matter what influences most people - it matters what influences the person who is poised on the edge of adopting D more widely, adopting D as a beginning, or would be if they knew of the language. The latter is quite a different sort, I think. Liran at Weka picked up D because he saw Kent Beck post on Twitter about Facebook's Warp written in D (or maybe it was a linter) and it seemed like an answer to a particular problem he had (if I am remembering correctly). It wasn't because of a grand thing - it was because of a little thing that seemed like it might be a creative solution to a real problem. Signal:noise is much higher away from the limelight too. By far better to have a high share of attention in some specific domains or interest groups than to have a low share of attention of some enormous market. Many devs use large corporate deployments as a litmus test
Re: [OT] Leverage Points
On Sunday, 19 August 2018 at 18:49:53 UTC, Joakim wrote: On Saturday, 18 August 2018 at 13:33:43 UTC, Andrei Alexandrescu wrote: A friend recommended this article: http://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/ I found it awesome and would recommend to anyone in this community. Worth a close read - no skimming, no tl;rd etc. The question applicable to us - where are the best leverage points in making the D language more successful. I read the whole thing, pretty much jibes with what I've already realized after decades of observation, but good to see it all laid out and prioritized, as Jonathan said. I thought this paragraph was particularly relevant to D: "So how do you change paradigms? Thomas Kuhn, who wrote the seminal book about the great paradigm shifts of science, has a lot to say about that. In a nutshell, you keep pointing at the anomalies and failures in the old paradigm, you keep coming yourself, and loudly and with assurance from the new one, you insert people with the new paradigm in places of public visibility and power. You don’t waste time with reactionaries; rather you work with active change agents and with the vast middle ground of people who are open-minded." This pretty much reflects what Laeeth always says about finding principals who can make their own decisions about using D. "Places of public visibility and power" for D are commercial or open-source projects that attract attention for being well done or at least popular. Read Vilfredo Pareto on the circulation of the elites, Toynbee on the role of creative minorities, and Ibn Khaldun on civilisational cycles. There's not much point focusing on the influential and powerful people and projects of today - they have too much else going on; powerful people tend to become a bit disconnected from reality, complacent and they and hangers-on have too much vested in the status quo to change. When you have nothing, you have not much to lose, but after considerable success most people start to move to wanting to keep what they have. This doesn't bring open-mindedness to new ideas or approaches. But we live in a dynamic economy and time and the winners of tomorrow might look unremarkable today. Linus said it was just a hobby project, nothing big like Minix. Would you have thought a few German PhDs had a chance with no capital, starting amidst a bad financial crisis and using a language that was then of questionable stability and commercial viability? New things often start small, growing at the fringe where there's no competition because at that point it's not obvious to others there is even an opportunity there. It's much better to appeal to new projects or commercial projects where people are in pain and therefore open-minded because suffering will do that to you. D is a general purpose quite ambitious language so I wouldn't expect necessarily that there is a pattern by industry or sector. Probably it will be organic and grass-roots. You have one unusual person in an unusual situation who is open to trying something different. And in the beginning it might not look like much, particularly to outsiders. Note that when you start a small business it takes a long time before you hire significant numbers of people usually. Yet in the US SMEs create more than 100% of the jobs. So there is a lag between people starting to play with D and them doing a lot in it or hiring many people to work with it. Five years even isn't a long time. Perceptions also take a long time to change, but they do tend to catch up with reality eventually. When I started looking at D in 2014 it really wasn't yet ready for primetime. The compiler would crash too often for comfort, and I wasn't even trying to do anything clever. The std.algorithm docs were perfectly clear - if you had a training or sort of mind that understood formalisms. But j tried to interest one ex trader in D - he could work with Python but back then he was absolutely terrified of the Phobos documentation. It's much better today, but the reaction from past improvements is still unfolding. Little things like dpp /dtoh combined with BetterC can make a huge difference I think. Being able to incrementally replace a C codebase without having to do lots of work porting headers (and keeping them in sync) brings down cost of trying D a lot. If DPP works for C++ so you can just #include then even better but it will take some time. I am trying to persuade Atila to have possibility to just handle some types as opaque. You can always write shims for the parts of the API you need but at least this way you can #include cpp headers and get something. I'm not sure we're doing a good job of publicizing those we have though, here's a comment from the proggit thread on BBasile's recent post about writing a language in D: "I keep seeing articles telling me why D is so
D kernel for Jupyter notebook
Proof of concept works, but it requires some further development to be useful to do work in. https://github.com/kaleidicassociates/jupyterd It uses D repl currently - this was written for a console interface and probably you will encounter difficulties running it in a notebook environment. I guess one would like to treat all functions defined in a single notebook as part of the same session and to execute immediate statements as part of a main specific to that cell. The kernel is a bit flakey - takes time to come on line and you might need to reconnect to it sometimes. To Do: 1.Add HTML and markdown table output to display arrays of structs or of dicts in a useful manner 2.Integrate with mir and other numeric libraries 3.Integrate with charting 4.Consider adding to Dlang tour and run.dlang.io when stable 5.Integrate with dpp 6.Integrate with dub 1 and 3 should be quite simple. One wouldn't want to write a large program in Jupyter, but it's helpful for exploratory data analysis and programming where the code that does the work is already in D.
Re: Found on proggit: Nim receives funding from a company (D should be doing something like this)
On Tuesday, 14 August 2018 at 07:05:12 UTC, Joakim wrote: On Tuesday, 14 August 2018 at 02:49:58 UTC, Mike Franklin wrote: On Monday, 13 August 2018 at 09:50:29 UTC, Joakim wrote: Announced last week, the Nim team will be adding two full-time paid devs and setting up grants for needed projects with this new funding: :jealous: However, there are other ways to raise funds. Companies using D could use the existing bountysource page to put up bounties for features/fixes or projects they need, to which community members who need some particular feature/fix could also donate: https://www.bountysource.com/teams/d I think bountysource would work if the bounties were significantly higher, but there are also the funding options at https://opencollective.com/dlang Yes, some of those bounties are too low for the amount of work, but nothing stops others who find them important to increase the bounty incrementally. Looking on the right column of the page there are several D enthusiasts contributing their hard-earned money to D. Maybe there's a better option for the masses, besides a T-shirt and a DConf discount, that might encourage more donors. For example, I might contribute somewhere between $100 or more if I could get some attention on some bugs/features that I care about (assuming I couldn't implement them myself). Maybe I'll post a bounty in the near future and see how it goes. A variation on that appears to be in the cards, as they've said there will be more funding targets: https://forum.dlang.org/post/orvcznlvraunkksjd...@forum.dlang.org I don't really care which website is used, bountysource or opencollective or whatever, but the community is unlikely to contribute unless they have a clear idea of where the money is going, which bountysource does a better job of showing right now. Right now, I'm the only one I know of working on the #dbugfix stuff, but I'm finding the bugs submitted this round exceptionally difficult. I don't know if I'll succeed with a fix this round (Sorry!), but contact me directly, or post an announcement on the forum, if you have a bug that you're willing to motivate with a financial contribution to the D Foundation, and I'll personally take a look at it. I'm generally only capable of fixing some of the more simple bugs, as my skills and understanding of DMD are quite limited, but I promise I'll try. This is not about me: I personally don't have any blocker bugs that I'm worried about. I'm concerned about the general pace of D development: I don't think we're as focused or organized on gathering resources as we should be. My preferred model is to turn D into a partially proprietary product, but I guess the core team doesn't like that approach: https://forum.dlang.org/thread/okuzksqzczprvuklp...@forum.dlang.org Back when I was a little kid decades ago, I had a neighbor who used to build model trains in his garage, what he did in his spare time. I remember seeing it then and being thrilled that it snaked all over his work area. 99% of open source projects are the "model trains" of software devs, something they work on for fun in their spare time, and never get used widely. To get into the 1% of OSS projects that are actually widely used, you need some way to gather resources to grow the project. There's the linux model where you get a bunch of consulting and support companies to use you. There's the llvm/clang model where you become a product in a large company, part of their portfolio alongside proprietary products or modules that pay the bills. There's the Firefox model where you sell ads alongside the OSS product. There's new models where you use crowdfunding sites like kickstarter or opencollective. D has so far used very little of any of these models. This project can give off the impression that it is simply a big model train for Walter and Andrei, a hobby that they've retired to work on. Instead, I'd like to see D much more widely used, which means work needs to be done on gathering resources beyond what the project has now. Have you read Peter Thiel's Zero to One and seen his YouTube talks on secrets etc? He says what I have always believed. I think market share is a legitimate approach if that's your cup of tea, but dominating a niche is a much better one if it fits you. I personally just by virtue of who I am as a person found that as a life strategy having a very high appeal to a tiny minority of people suits me by far better (I like to think they are the best people but who is really to say as it depends on your point of view). I truly don't think it's relevant what most people think of D at this point. The world is a very big place and there's room for many languages and I don't think there will be another C - that was a creature of its time, and time and conditions have changed since then. Most code is enterprise code that nobody much hears about and I guess most
Re: Found on proggit: Nim receives funding from a company (D should be doing something like this)
It's always good to steal insights from wherever you legitimately can. There's often more treasure in areas utterly different from your field of activity than in those that on the face of it fall into the same category. I think that in the hedge fund business for example I've learnt more in recent years from choirs, alternative wine makers that break the rules, open source communities, the Rotary Club, observations of artistic scenes, pondering what the punk Tom Jennings told me back in the day, and so on than I have from competitors in my field. I think each language community is founded on its own unique principles and trying to squash it onto a box that doesn't fit isn't going to go anywhere. D doesn't need a big corporate sponsor. It already has some corporate sponsors and now there is a beginning made with the D Foundation and enterprise adoption across many different sectors it's just a matter of nourishing the beginning we have and helping it unfold. The idea of any corporate sponsor having much luck with influencing the development of the language in a direction it doesn't want to go anyway is most entertaining to contemplate. Remedy Games asked for attributes I think - a really good idea - and even then there was grumbling. Not that I mind the grumbling. You know money is valuable but creative energy and involvement is much more so, even though you can't eat the latter. I am hoping in time that we would inspire others to see the benefits of being involved and I think that will happen. ICO sponsorship or from divers companies across many domains - I know which one I think creates the best foundation for future success. I did try funding bounty source but there doesn't seem to be much action there. I hope Nim succeeds too - it looks like a nice language and it's an amazing accomplishment for a small core team. Languages are not after all in a battle to the death - life is not a zero-sum game. My biggest challenge right now is hiring more of the right kind of programmers given that it takes a lot of time to find them the conventional way and I would like to keep raising the bar and not lower it. It's a firm where people matter so if someone wants to work on open source projects that are in a direction that helps the direction of the firm one day a week then it's something we can be open to for the right person. And if we end up continuing to find more strong people via the D community then it's easy to justify increasing our contribution. Headhunters charge 20% of first year's salary, after all, and they mostly don't have good taste and it ends up taking a lot of time I don't have. In a world where the system of credentials has broken down, what is left that still works? Focal points, resonance, sample work, and recognition by those who have reputation already. Maybe in a decade we will be reminiscing about those wonderful times before people realised there are great jobs in D. Success ultimately attracts a different kind of person - every moment in time is good for some purpose.
Re: Dpp on run.dlang.io
On Monday, 6 August 2018 at 13:32:23 UTC, bachmeier wrote: On Sunday, 5 August 2018 at 22:43:42 UTC, Laeeth Isharc wrote: One benefit of D is as a better glue language that integrates well with other languages and ecosystems. Many people who know a bit about D have no idea that interop can work so easily or well. So it might be worth mentioning this benefit as one link from main page and then linking from that to new page that mentions and has runnable examples (using HAR) for: Python (via autowrap:python and pyd) C (via dpp) C++ (extern(C++) for now) R (via embedr) Julia (via C interface, including julia.h via dpp) Lua (if LuaD stable enough) And Octave (via the .mex interface) - this one's important because it opens the door to using D as an extension language to Matlab If an Octave extension written in D works, do you have anywhere to point me to on what's needed to make it work with Matlab? (Is it usually drop-in compatible?)
dtoh
Hi Walter. Can dtoh be open-sourced now that dmd is? Laeeth.
Re: Dpp on run.dlang.io
On Saturday, 4 August 2018 at 13:15:24 UTC, Seb wrote: On Saturday, 4 August 2018 at 01:27:49 UTC, Laeeth Isharc wrote: Thanks to Seb and Atila it is now very easy to show a D program just #includeing C headers. If just works. Modulo bugs. In time I am hopeful Atila will start to have more of C++ headers working too. https://run.dlang.io/is/JlH3Th It now also supports multiple files (and compiling C files) with the Har format [1]: https://run.dlang.io/is/WwpvhT This should hopefully make it even more useful. [1] https://github.com/marler8997/har Thanks v much for this. One benefit of D is as a better glue language that integrates well with other languages and ecosystems. Many people who know a bit about D have no idea that interop can work so easily or well. So it might be worth mentioning this benefit as one link from main page and then linking from that to new page that mentions and has runnable examples (using HAR) for: Python (via autowrap:python and pyd) C (via dpp) C++ (extern(C++) for now) R (via embedr) Julia (via C interface, including julia.h via dpp) Lua (if LuaD stable enough) with just screenshot for: Excel (via autowrap excel / excel-d) C# via Binderoo Jupyter via pydmagic and just link for web assembly. Obviously a lot of work, but if you think a good idea we could work away at over time.
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Sunday, 5 August 2018 at 20:01:22 UTC, Nikos wrote:
On Tuesday, 31 July 2018 at 09:09:11 UTC, Nicholas Wilson wrote:
On Sunday, 29 July 2018 at 18:14:31 UTC, Nikos wrote:
But when I try to export the whole dmdEngine
export:
auto engine(char[] txt) {
return interpreter(dmdEngine());
}
Can you export an instance of `interpreter(dmdEngine())`?
e.g.
__gshared auto dmdi = interpreter(dmdEngine());
export ref dmd()
{
return dmdi;
}
or if that doesn't work, proxy it
__gshared auto dmdi = interpreter(dmdEngine());
struct Dmd
{
mixin Proxy!dmdi;
}
export auto dmd()
{
Dmd d;
return d;
}
That is pretty much required if you want to maintain state
across.
Also I'm working on a D kernel for Jupyter notebook which
should be done soon.
Thank you very much for your feedback. Unfortunately, none of
the above worked.
By the way, the reason I'm trying all this is to create a
Jupyter notebook. I've already made a simple version of it some
time ago
(https://github.com/nikoskaragiannakis/d-jupyter-kernel). Since
you are also working on a D kernel, maybe we could work
together?
Working example of Python calling D Repl is here.
https://github.com/kaleidicassociates/pydrepl
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Saturday, 4 August 2018 at 07:34:49 UTC, Manu wrote: On Fri, 3 Aug 2018 at 18:50, Laeeth Isharc via Digitalmars-d wrote: On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote: > > The difference is they would have to rework their existing > code. If you are writing D source code bindings for your > code, then you are essentially writing new code. You don't > have to worry about backwards compatibility. Why would you write bindings if the computer can do it for you, better, faster and consistently? Faster and consistently, sure. But I don't think 'better' is possible. From my experience, in many cases, C++ really doesn't express well in D by direct translation. I tend to do significant massaging of the C++ helper material to improve the experience from D. Usually C++ libs have a lot of helper material in the form of macros, little template utilities, inline wrappers, and they can almost always be expressed more nicely in D with some tweaking. I often also insert some additional inline D helpers/wrappers nearby the externs, which help adapt the signatures; ie, apply some attributes, or make a slice-based API that transforms to ptr+len args, maybe implement a range helper, that sort of thing. The goal is to make the API attractive such that a user is compelled to prefer interacting with the lib from D than from C++. C++ namespaces interfere with overload resolution in particular, and that makes this goal harder. It probably depends on your use. If you're just calling a C++ lib, and wrap it up in a box for use in your local code, a machine translation for the API might be fine. I'd call that 'making use of a feature lib'. If you are linking to a lib that is a fundamental part of your application infrastructure, you absolutely must do significant manual work to make the C++ code express nicely to D, otherwise the user-experience interacting with the C++ api from D will be worse than just using C++. If the C++ experience is better than from D, then D experience ceases to exist as no case can be made to prefer D over C++, the project is moot, and I have wasted my time. The D experience must not just be equal to the C++ experience, it must typically be substantially better in a variety of ways, and I have never been able to have such an experience interacting with C++ without making some manual effort towards quality bindings. The current namespace mechanics put SOOO much more strain on that goal than is necessary. One other important feature of quality bindings, is that the binding itself must be readable and maintainable. The binding itself is the very first showcase to C++ programmers of how their API's could be better in D. It must be well organised (like normal D code), and the current situation with boilerplate invading the works is destructive toward that end. Of course, thanks to this namespace situation, when involving with these hideous workarounds, they are usually objectively NOT better in D, and C++ programmers do indeed recognise that immediately. Would it be inaccurate to make a distinction between bindings and wrappers ? It's always going to be less pleasant to call even C bindings from D then an idiomatic D wrapper written on top. But if you have automatically generated bindings then you can put the effort into the wrappers and it's easier to do the latter incrementally. And being able to use a library at all even if slightly unpleasantly without having to pay a big price up front beats having no choice. At least for us the sequencing of cost matters more than the total cost, and the calendar time element of cost to being able to write a passable and useful first version is more important than the pecuniary element. We have many more people who are not C++ programmers but express their ideas in D then we do people who know C++ pretty well. BTW I almost think the D Foundation should organise a library wrapping as a service marketplace ;). Lots of people in the community are open to remote work part or full time. But the cost is in finding the right people and also to some extent supervising and organising the design and work. That could be just another forum in the beginning.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote: The difference is they would have to rework their existing code. If you are writing D source code bindings for your code, then you are essentially writing new code. You don't have to worry about backwards compatibility. Why would you write bindings if the computer can do it for you, better, faster and consistently? That's the idea behind DPP. You can just #include C headers and they will be translated before compile time. This is very helpful with projects like HDF5 that consider it acceptable in a minor release to replace a function with a macro. Wrappers are a bit different. In time C++ will follow. Not only that, who do you think even writes bindings for libraries? Most bindings are done by the community for libraries to other languages. How many companies do you know have bindings for their C/C++ libraries for D, that maintains them? We do for a few things - for other peoples' libraries not our own. But it would be better not to have to write bindings at all. damn hell no. That's what modules are for. So why are you trying to implement namespaces in D under the guise of C++ name mangling. I don't think either Manu or Atila want to be able to sneak in namespaces by the backdoor. They just want to be able easily to control namespace mangling of C++ linkage symbols. What extern(C++) should be used for is allowing you to call C++ code from D, not to be able to format C++ code into D. The only problem you have with breaking code up into multiple files is that it isn't 1:1. That's not a technical problem, it's a problem of conflicting personal opinion. If it's not 1:1, who cares? If some some odd reason you have two namespaces in one file in C++, odds are they are probably separated in that one file anyway. If not and for some reason the the code has multiple namespace definitions smashed together into one file, flip-floping between namespaces. That's not D's problem to fix the project's poor organization method. For automatically translated bindings I think that the request is not unreasonable because there's considerable value in being able to just #include C++ headers as you can already with C headers and just call the C++ code from D. D doesn't have libraries? Well it's got 1500 on code.dlang.org plus C and C++ libraries. What is it you think is missing? That's a good retort! I understand from Atila present choice just makes it a lot more complicated, not impossible.
Dpp on run.dlang.io
Thanks to Seb and Atila it is now very easy to show a D program just #includeing C headers. If just works. Modulo bugs. In time I am hopeful Atila will start to have more of C++ headers working too. https://run.dlang.io/is/JlH3Th
Re: [OT] Re: C's Biggest Mistake on Hacker News
On Sunday, 29 July 2018 at 09:35:06 UTC, Abdulhaq wrote: On Saturday, 28 July 2018 at 14:45:19 UTC, Paolo Invernizzi wrote: I forgot the link... here it is: https://www.quantamagazine.org/to-make-sense-of-the-present-brains-may-predict-the-future-20180710 An interesting article. I found that Dennet's Consciousness Explained, which is presumably debunked old hat by now, is full of interesting experiments and speculation about how we model things in our mind and how our perceptions feed into that. It's a long time since I read it but if I remember correctly he shows how we seem to have a kind of mental theatre which has an expectation of what will come next from the senses, leading to interesting mistakes in perception. It's a useful model of how the mind works. That website often carries good articles about new maths as well. Me and my colleague are pretty different, in the approach to that kind of stuff... Maybe I'll post on the Forum a 'Request for D Advocacy', a-la PostgreSQL, so the community can try to address some of his concerns about modern D, and lower his discomfort! :-P If you can explain to me what is the _direction_ of D in terms of interfacing with large C++ libraries it would be very much appreciated! I'd love to be using D for some of my projects but I have a perception that using e.g. VTK is still a difficult thing to do from D. Is that still true? What is the long term plan for D, is it extern(C++), a binding technology? Is there any interest in Calypso from the upper echelons? I want to know where D is trying to go, not just where it is now. I want to know if anyone has got their heart in it. My CV says my main languages are Java, Python and D. That last one is mainly wishful thinking at the moment. I wish it wasn't! Make me believe, Paulo! Well we are hiring D programmers in London and HK in case it's interesting. Dpp doesn't work with STL yet. I asked Atila how long to #include vector and he thought maybe two months of full-time work. That's not out of the question in time, but we have too much else to do right now. I'm not sure if recent mangling improvements help and how much that changes things. But DPP keeps improving as does extern (C++) and probably one way and another it will work for quite a lot. Calypso makes cpp classes work as both value and reference types. I don't know the limit of what's possible without such changes - seems like C++ mangling is improving by leaps and bounds but I don't know when it will be dependable for templates. It's not that relevant what Andrei or Walter might think because it's a community-led project and we will make progress if somebody decides to spend their time working on it, or a company lends a resource for the same purpose. I'm sure they are all in favour of greater cpp interoperability, but I don't think the binding constraint is will from the top, but rather people willing and able to do the work. And if one wants to see it go faster then one can logically find a way to help with the work or contribute financially. I don't think anything else will make a difference. Same thing with Calypso. It's not ready yet to be integrated in a production compiler so it's an academic question as to the leadership's view about it.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Saturday, 28 July 2018 at 01:03:10 UTC, Walter Bright wrote: On 7/27/2018 4:15 PM, Laeeth Isharc wrote: Can you think of a pragmatic solution to Atila's problem? One way is for the C++ => D translator to gather all the members of a namespace before trying to emit them. Since D does not impose an order on declarations (unlike C++) it is not constrained to follow the same order. So a new post preprocessor stage that parses the produced D code and regroups to group the declarations in the same namespace together ? Using DMD as a library or libdparse or something?
Re: [OT] Re: C's Biggest Mistake on Hacker News
On Saturday, 28 July 2018 at 13:55:31 UTC, Paolo Invernizzi wrote: On Saturday, 28 July 2018 at 12:43:55 UTC, Laeeth Isharc wrote: each project I start I give some very hard thought about which development environment I'm going to use, and D is often one of those options. The likely future of D on the different platforms is an important part of that assessment, hence 'predicting' the future of D, hard and very unreliable though that is, is an important element in some of my less trivial decisions. Since you already know D you need to answer a different question. What's the chance the compiler will die on the relevant horizon, and how bad will it be for me if that happens. Personally I'm not worried. If D should disappear in a few years, it wouldn't be the end of the world to port things. I just don't think that's very likely. Of course it depends on your context. The people who use D at work seem to be more principals who have the right to take the best decision as they see it then agents who must persuade others who are the real decision-makers. That's a recipe for quiet adoption that's dispersed across many industries initially and for the early adopters of D being highly interesting people. Since, as the Wharton professor, Adam Grant observes, we are in an age where positive disruptors can achieve a lot within an organisation, that's also rather interesting. A very interesting discussion... really. Perceptions, expectations, prediction... an easy read I suggest on the latest trends [1], if someone is interested... BTW, Laeeth is right in the last paragraph two. I was one of the 'principal' who took the decision to use D in production, 14 years ago, and he described the reasoning of that era very well. Today I'm still convinced that the adoption of D is a competitive advantage for a company, I definitely have to work to improve my bad temper (eheh) to persuade my actual CTO to give it another change. /Paolo (btw, I'm the CEO...) Thanks for the colour, Paolo. Yes - it's a competitive advantage, but opportunity often comes dressed in work clothes. We're in an era when most people are not used to discomfort and have an inordinate distaste for it. If you're fine with that and make decisions as best you can based on objective factors (objectivity being something quite different from 'evidence-based' because of the drunk/lamppost issue) then there is treasure everywhere (to steal Andrey's talk title). Opportunities are abundant where people aren't looking because they don't want to.
Re: [OT] Re: C's Biggest Mistake on Hacker News
On Saturday, 28 July 2018 at 11:09:28 UTC, Abdulhaq wrote: On Friday, 27 July 2018 at 23:42:47 UTC, Laeeth Isharc wrote: For me, I think that managing money is about choosing to expose your capital intelligently to the market, balancing the risk of loss against the prospective gain and considering this in a portfolio sense. Prediction doesn't really come into that I think this apparent difference of opinion is down to different definitions of the word prediction. When I say prediction I mean the assessment of what are the possible futures for a scenario and how likely each one is. It can be conscious or unconscious. I think my understanding of the word is not an uncommon one. By my definition, when you balance the risk of loss (i.e. predict how likely you are to lose money) against the prospective gain (i.e. multiply the probability of each possible outcome by its reward and sum the total to get a prospective value) then you are, by my definition and therefore, for me, by definition, making predictions. It's tough when dealing with genuine - Knightian uncertainty or even more radical versions. When one doesn't even know the structure of the problem then maximising expected utility doesn't work. One can look at capacities - Choquet and the like - but then its harder to say something useful about what you should do. And I think when dealing with human action and institutions we are in a world of uncertainty more often than not. It's not the prediction that matters but what you do. It's habits, routines, perception, adaptation and actions that matter. I agree they are integral to our behaviour and habits and routines do not involve the element of prediction. Perceptions come before and actions take place after the decision process is made (conscious or not) and so don't factor into this discussion for me. But it's a loop and one never takes a final decision to master D. Also habits, routines and structures _do_ shape perception. In truth I avoid discussions that are really just arguing about definitions of words, but you made a couple of sweeping bumper-stickery comments That's entertaining. I've not been accused of that before! Bear in mind also I tend to write on my phone. that trying to predict things was usually a waste of time and as an alternative we should 'be the change...'. I wholeheartedly agree we should 'be the change...' but it's not an alternative to making predictions, it goes hand in hand with it. I'm sure you've read Kahneman's Thinking, Fast and Slow. You made a generalisation that applies to the 'fast' part. I'm saying your universal rule is wrong because of the slow part. Yes I read Kahneman et al papers for the first time in 92 in the university library. I speed-read his book, and I thought it was a bad book. I work with a specialist in making decisions under uncertainty - she was the only person able to articulate to George Soros how he made money because he certainly couldn't, and she is mentioned in the preface to the revised version of Alchemy. She has the same view as me - behavioural finance is largely a dead end. One learns much more by going straight to the neuroeconomics and incorporating also the work of Dr Iain Macgilchrist. Kahneman makes a mistake in his choice of dimension. There's analytic and intuitive/gestalt and in my experience people making high stakes decisions are much less purely analytical than a believer in the popular Kahneman might suggest. What I said about prediction being overrated isn't controversial amongst a good number of the best traders and business people in finance. You might read Nassim Taleb also. I learnt D many years ago just after Andrei's book came out. I love it but it's on the shelf at the moment for me. I rarely get time for side projects these days but when I do I want them to run on Android with easy access to all the APIs and without too much ado in the build setup. They must continue to work and be supported with future versions of Android. At work, on Windows, JDK8/JavaFX/Eclipse/maven and python/numpy/Qt/OpenCascade/VTK hit the spot. Well it's a pity the D Android ecosystem isn't yet mature. Still I remain in awe of the stubborn accomplishment of the man (with help) who got LDC to run on Android. It's not that bad calling D from Java. Some day I will see if I can help automate that - Kai started working on it already I think. each project I start I give some very hard thought about which development environment I'm going to use, and D is often one of those options. The likely future of D on the different platforms is an important part of that assessment, hence 'predicting' the future of D, hard and very unreliable though that is, is an important element in some of my less trivial decisions. Since you already know D you need to answer a different question. What's the chance the compiler will die on the relevant
Re: C's Biggest Mistake on Hacker News
On Friday, 27 July 2018 at 15:04:12 UTC, Abdulhaq wrote: On Wednesday, 25 July 2018 at 23:27:45 UTC, Laeeth Isharc wrote: But making predictions is a tricky thing and mostly of not much value. I'm really surprised to hear you say this - so much money in the financial services is poured into making predictions, lots of them and as fast as possible. Isn't that one of the promises of D in that market? For me, I think that managing money is about choosing to expose your capital intelligently to the market, balancing the risk of loss against the prospective gain and considering this in a portfolio sense. Prediction doesn't really come into that I do personally sometimes write longer term pieces about markets - I wrote a piece in June 2012 asking if dollar is bottoming and I said it was. But that was based on a gestalt not some Cartesian predictive model. Whatever the reality about that, in the life of all humans the ability to make good predictions is fundamental to survival - if I cross the road now, will I be run over? If I build a chair to make money, will anyone buy it? I disagree. It's not the prediction that matters but what you do. It's habits, routines, perception, adaptation and actions that matter. What people think drives their behaviour isn't what actually does. See Dr Iain Macgilchrist Master and His Emissary for more. And in particular if you survive based on having insight then it's interesting to listen to what you say. If you are known as an expert but don't depend on having insight, it's interesting in how others perceive what you say and how that evolves, but the substance of your analysis is not - without skin in the game, it's just talk. Bernanke admits he has had no clue about economic developments before they happen. I used to trade a lot of gilts and the UK debt management office asked me to meet the IMF financial stability review guy in 2005. He had a bee in his bonnet about hedge funds and the dollar yen carry trade. I told him to look at the banks and what they were buying. He didn't listen. I had lunch with Kohn, Fed vice chair in summer 2006. I asked him about housing. He wasn't worried at all. So lots of people talk about all kinds of things. Look at how insightful they have been in the past. Predictions themselves aren't worth much - recognising change early is. And for what it's worth I think D is early in a bull market that will last for decades. The grumbling is funnily enough quite characteristic of such too. Likewise, if I am investing time in developing my skills to further my career, will learning D be a net benefit? It really depends. There are some very good jobs in D. If it should turn out we hired you some day then most likely you would find it quite satisfying and well paid and be rather glad you learnt D. If not and not someone else then who knows. I personally found following my intuition like in a Jack London novel to be better than trying to live by optimising and figuring out the best angle. But people are different and it's difficult to know. If you feel like learning D, do it. If it's purely a career move then there are too many factors to say. important question depends heavily on predicting the future of D (among many other things). If I use D for my startup, will it be the secret sauce that will propel us to the top, or will I be better off with JDK8 or modern C++? Things once alive tend to grow. The future is unknown if not unimaginable. I don't think life works like that. It's more like you pick something for your startup and the start-up fails because your business partner gets divorced. But through some unlikely chain of coincidences that leads to some better opportunity you never could have found by approaching it head on. So things are beyond calculation, but not beyond considering intuition and what resonates with you. See the work of my colleague Flavia Cymbalista - How George Soros Knows What He Knows. I think it's more interesting to be the change you wish to see in the world. This has a lovely ring but it doesn't mean not to assess / predict if what you do will provide a net benefit. It's really up to you what you do. People who make high stakes decisions - also commercially - I'm really not sure if predictions play the part you think they do. One little trick. If you have an insight nobody agrees with then you know you might be onto something when surprises start to come in your direction in a way nobody could have quite imagined. We are seeing this now with processor challenges for example.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Friday, 27 July 2018 at 22:50:20 UTC, Walter Bright wrote:
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D compiler how to
mangle symbols.
Namespaces have semantic implications, too, such as overload
resolutions. A namespace introduces a new scope, not just a
mangling.
> But why does this not compile?
> extern(C++, ns) { void foo(); }
> extern(C++, ns) { void bar(); }
For the same reason that:
struct ns { void foo(); }
struct ns { void bar(); }
doesn't. Being able to crack open a scope and stuff more
symbols into it at any point in a program is just madness :-)
However, one can do:
-- module A -
extern(C++, ns) { void foo(); }
-- module B -
extern(C++, ns) { void bar(); }
-- module C -
import A,B;
ns.foo(); // error, A.ns or B.ns?
A.ns.foo(); // ok
Because the compiler sees A.ns as utterly distinct from B.ns,
although the mangling will be the same - any conflicts will be
the linker's problem.
This is how, for example, extern(C) declarations can exist in
many files.
> Such a program can easily do that to `extern(C)`, but doing
that to `extern(C++)` is for some reason not allowed.
It is allowed. Just not reopening the same namespace.
Namespaces are a botch in C++, and it is understandable that
C++ code bases naturally have grown willy-nilly to utterly
ignore any encapsulation principles. It's analogous to how
monkey-patching in Ruby was seen initially as a cool feature,
but eventually people learned the hard way what a disastrous
idea it was.
Thanks for the explanation, Walter.
Can you think of a pragmatic solution to Atila's problem?
Because it's getting in the way of a decent prize - to be able
just to #include CPP headers and link with C++. Obviously some
work elsewhere still to do, but translation of headers is worth
quite a lot if you are a commercial user and don't have much time
to write a first exploratory version.
Already just having #include work for a lot of C libraries makes
an immense difference.
D "doesn't have libraries". Well there's some good stuff on
code.dlang.org plus every C library - a few of those, so I hear.
And with C++ on top it starts to become about as persuasive as
"there are no good jobs in D". (Reminder - we are hiring and we
pay well).
Re: C's Biggest Mistake on Hacker News
On Tuesday, 24 July 2018 at 00:41:54 UTC, RhyS wrote: On Monday, 23 July 2018 at 22:45:15 UTC, Walter Bright wrote: I've predicted before that what will kill C is managers and customers requiring memory safety because unsafeness costs them millions. The "just hire better programmers" will never work. I have yet to see a company Walter where higher ups will take correct actions to resolve issues. It might be that you are working for the wrong companies. Half the companies in the world are below average and few are excellent. And most manager are not going to rock the boat and stick their necks out. Not when they can simply blame issues on programmer incompetence or "it has always been like that with programming languages". I have yet to see managers really taking responsibility beyond guiding the projects so they do not get fired and hope to rack in bonuses. Issues can always be blamed on the tools or programmers. That's a good point, but the nice thing about not having dominant market share is it's easy to grow it. You don't need to convince most managers. Just a few more people who are on the edge already anyway. Quality is better than quantity because the former concentrate power. And frankly, good luck convincing any company to convert millions of C code into D code. The point is with betterC you don't need to. And on the other hand if you did, libclang would take quite a lot of the pain out once you did a bit of work upfront. See DPP I am sorry to say but to succeed as a language beyond being a small or hobby language it takes: Being established already or having a big name to hype behind your "product". I don't agree. We are in a time of positive disruption when old heuristics break down. All D has to do is to keep compounding its adoption and what average people think of D is completely irrelevant. What's important is what the best people amongst those who are principals rather than agents think of D. There's no point selling it to a committee, but who wants to deal with committees anyway - life is too short for that if one possibly has the choice. Its the same reason why PHP despite being a good language ( for what it is ) ! , still keeps getting the exact same crude on forums. If i am honest, DasBetterC is a for me unreliable D product because using specific D library function can be GC. Or DasBetterC needs to be sold as C only, ever, forget about everything else that is D ( library, packages, ... ). Until everything is 100% GC free, your going to run into this. And even when its 100% GC free, people have long memories. Don't use it if you don't want to. But making predictions is a tricky thing and mostly of not much value. I think it's more interesting to be the change you wish to see in the world.
Re: Symmetry Autumn of Code
On Wednesday, 18 July 2018 at 10:42:04 UTC, Andre Pany wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ Another proposal: Adding D support to gRPC I started to add D support to gRPC but paused it due to lack of knowledge and time. One solution would be to add a D wrapper to https://github.com/grpc/grpc/tree/master/src by making use of the C interface of gRPC (https://github.com/grpc/grpc/tree/master/include/grpc). As template e.g. C++ or python could be used (https://github.com/grpc/grpc/tree/master/src). Kind regards André Juniper have an alpha C higher interface on top of the low level C core grpc API. It didn't look too bad, but I didn't have time to finish what I started (making a crude D grpc API). https://github.com/Juniper/grpc-c
Re: dpp now compiles julia.h headers
On Friday, 13 July 2018 at 22:22:25 UTC, Meta wrote: On Friday, 13 July 2018 at 19:02:56 UTC, Laeeth Isharc wrote: Atila Neves' d++ now compiles julia.h. Modulo bugs this makes it possible to embed Julia in D (and probably the other way around, but I have not tried). https://github.com/kaleidicassociates/juliad Very cool. It's awesome to be able to directly #include C++ headers. C++ headers with all basic features are not yet there. Atila thought it might be a couple of months work full-time to be able to do #include It's not out of the question to make that investment, but we need to hire a few more programmers locally first.
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 07:09:21 UTC, Timoses wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ Typos "D programming lagnauge" (looks a bit french) : D "accept yor offer." Thanks for corrections. Great! Wish I was a student still : D. Me too ! Kidding aside, if you would be interested in a job programming mostly or partly in D please see our website. Lots of roles we haven't yet had time to post.
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 07:30:26 UTC, Joakim wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ "join us" for "submit an application" -> apply (confusing otherwise) Maybe sum up and make clear that each student can earn between $3000-4000, instead of capped at $1k. Why limit it to students? If the goal is to have a youth injection, just use an age limit- say 18-25- I see no reason for the stupid college bias. Hi Joakim. Thanks for suggestions. I don't know what legal aspects there are relating to targeting age in different countries. We are definitely targeting people earlier in their careers. I agree with you that talent isn't only found amongst students, and I've in the past hired someone that didn't even finish high school and has gone on to do good work for the D community. So as far as Symmetry goes we are very open to unusual talent. A degree is just one piece of interesting information. https://symmetryinvestments.com/careers/ There's quite a lot of work involved in organising something like this, and I'm very grateful to the D Foundation for doing such an excellent job. We can refine this for next year, but I wanted to make a start. Laeeth
Re: dpp now compiles julia.h headers
On Friday, 13 July 2018 at 19:42:56 UTC, bachmeier wrote: On Friday, 13 July 2018 at 19:02:56 UTC, Laeeth Isharc wrote: Atila Neves' d++ now compiles julia.h. Modulo bugs this makes it possible to embed Julia in D (and probably the other way around, but I have not tried). https://github.com/kaleidicassociates/juliad This is great news for me. A lot of new Julia code is being written by economists. I was going to work on this once I had a block of time. Glad to return the favour. We started using embedr to call R libraries from D - thanks for that. I guess the next stage would be to work on autowrapping Julia -> D and viceversa.
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification. What are your ideas? If you would like to expose C function and type declarations to D, you could take a look at DPP, which allows you to just #include a C header. If you encounter a bug, please file an issue and in time we will fix it. Does not yet work for C++ except in some cases. https://github.com/atilaneves/dpp
dpp now compiles julia.h headers
Atila Neves' d++ now compiles julia.h. Modulo bugs this makes it possible to embed Julia in D (and probably the other way around, but I have not tried). https://github.com/kaleidicassociates/juliad
Re: Pyd updates
On Monday, 4 June 2018 at 01:17:31 UTC, Norm wrote: On Monday, 4 June 2018 at 00:53:26 UTC, ROB wrote: On Wednesday, 12 July 2006 at 23:35:55 UTC, Kirk McDonald wrote: [...] has there been any updates since July 2006 there does not seem to be any new msg's since unless you have forked this forum to a new location. if you have please provide I am new to D I have been learning python for some time and thought Python and D would work well together. Also are there any Projects using it yet I would like to get involved and contribute if possible. Try this repo: https://github.com/ariovistus/pyd https://github.com/ariovistus/pyd/wiki https://github.com/kaleidicassociates/autowrap makes using PyD a little simpler.
Re: Remember the Vasa! by Bjarne Stroustrup
On Friday, 1 June 2018 at 18:18:17 UTC, Tony wrote: But with regard to various compile-time stuff and function annotations and other things that didn't exist years ago, has that resulted in noticeably faster programming and/or noticeably higher code quality by those utilizing it? Yes, though you also can't compare a typical programmer from the D world with a typical guy from an enterprisey language world. The D guy I am begging please to consider copying memory just this once, and guy from a certain different community I am trying to encourage to consider using a profiler. Anyway in one little comparison for a market data service some D code I pulled together was quite a bit faster than the code written in a certain other enterprise language. D was just storing binary blobs and the other one was talking to MongoDB so it's a totally unfair comparison. But what I wrote quickly in a few weeks not caring about performance at all and feeling guilty about it was 2,000x faster than the solution written in a more traditional language that took months to write. And there was almost no code, so with the exception of three hairy lines it was much more readable and clear. Of course it's unfair to compare two different back ends, but that's also the point - there's a difference in values between different communities. Somebody told me that XYZ company that developed his language are the experts and what do I know so I will not even think about how it works beneath. The D programmer has a virtue of a different kind (and one must never forget that any virtue, taken to the extreme, and out of balance with other virtues becomes a vice) - she knows that it's just code and whilst uncomfortable in the beginning with persistence one can figure it out. Who the hell do you think you are to write a C compiler? That's still echoing today from the founding moment. Values are perhaps much more important than features in determining whether one should use a modern basically sound language. Is it a problem that if you install the latest DMD on windows or Ubuntu it might not work the first time, and it definitely won't if you are trying to show someone. That very much depends. Are you someone and do you work with people who are put off by the first five minutes and indeed repeated encounters with the rough around the edges aspects of D? I was a bit daunted by the bleeding edge reputation of Arch Linux so I tried everything else, but when I found it I knew I had come home. For my own workstation, not something to use on critical infrastructure of course - though on the whole I would ideally be able to adapt to failure rather than try to make sure the impossible to prevent never happens. Nassim Taleb says that something is resilient if it survives stress and antifragile if it benefits from stress and disorder. Well, sometimes it has been a pain in the neck, but I would by far rather deal with regular small infelicities than less frequent big ones. We are in an age of specialisation and resulting fragmentation - not just in programming but in many other fields too. The edge in life is always shifting. In 1998 I was nervous about moving to DE Shaw as a trader and an older chap with white hair (we were all younger then so Angus was an anomaly) said don't worry - you have some technical skills that most people won't have for a decade, so if it doesn't work out you will be fine. And today it's the other way around - because I followed my interests I ended up knowing enough about quite a few different things where the package is not that common. And yet there's a value in knowing the whole picture in one mind that can't be substituted for by a committee. And what's true there is true with other skills too. So the infelicities of D actually serve as a moat to filter for the worthy and a training regime to keep you fit. Taleb talks about checking into an expensive hotel where there is a guy in a suit paying the bellboy to carry his bags upstairs. Then an hour later he sees the same guy in the gym lifting weights using a machine. And he has a point that to a certain extent it's possible to use found challenges to stay fit more than people are in the habit of doing today. There's also a breadth found in the community that used to be the norm when I started programming in 1983 but disappeared in the years. In which other community will I have dinner with a naval architect and come away with good ideas that I can steal and put to good use for what I am doing? Anyway beyond performance and the specific virtues of programmers from the D community (which may well be vices in an environment that ought to be based on different values), yes I do think CTFE, introspection, sane templates and code generation make a great deal of difference to code readability. There's much less of it for a start, and it's easy to understand what it's doing.
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 23:55:07 UTC, Dave Jones wrote: On Tuesday, 29 May 2018 at 05:29:00 UTC, Ali wrote: On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote: It seems C++ is following the road of PL/I, which is growing language way beyond the point anyone can understand or implement all of it. A key line from this paper We now have about 150 cooks; that’s not a good way to get a tasty and balanced meal. I don't think Bjarne is against adding feature to C++, or even constantly adding feature he even admits to support some of the features he mention in his list I think he is worried about 1. the huge number of features being targeted at once 2. the features coming from different independent teams, making them less likely to be coherent Which is ironic considering... Ken Thomson : " Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said “no” to no one. He put every feature in that language that ever existed. It wasn’t cleanly designed—it was just the union of everything that came along. And I think it suffered drastically from that." Donald Knuth : "Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said "OK, we'll do them both". So the language is too baroque for my taste." A dysregulation of caution is more the rule than the exception in modern times. People say yes when they should have said no, and then after the mess becomes evident in reaction to it they say no when they should be saying yes (in response to efforts to clear things up). Viz the response before and after the credit crisis.
Symmetry Investments is recruiting developers in London and Hong Kong
Hi. Walter+Andrei said this was okay to post here since it relates to D. This is for one role working with our analytics and research groups; more in the pipeline. Feel free to ping me directly if you are involved with the community already. Laeeth. Symmetry About Us: At Symmetry Investments, we seek to engage in intelligent risk-taking to create value for our clients, partners and employees. Symmetry Investments is a global investment company with offices in Hong Kong and London. We have been in business since 2014 after successfully spinning off from a major New York-based hedge fund. Currently we have about 110 full time employees and manage approximately US$4.2 billion of capital. We derive our edge from our capacity to generate Win-Wins – in the broadest sense. Win-Win is our fundamental ethical and strategic principle. By generating Win-Wins, we can create unique solutions that reconcile perspectives that are usually seen as incompatible or opposites, and encompass the best that each side has to offer. We integrate fixed-income arbitrage with global macro strategies in a novel way. We invent and develop technology that focuses on the potential of human-machine integration. We build systems where machines do what they do best, supporting people to do what people do best. We are creating a collaborative meritocracy: a culture where individual contribution serves both personal and collective goals - and is rewarded accordingly. We value both ownership thinking AND cooperative team spirit, self-realization AND community. D/C++ Quantitative Developer This is an outstanding opportunity for the right person in terms of the intrinsic challenges of the role, the responsibility, the exposure to senior management, the opportunity to shape the development of something new, and over time the compensation. Whilst we are a commercial enterprise, we highly value deep technical expertise and the cultivation of craft. You will be working closely with the Partner in charge of technology, who is a contributor to the open source community and a change agent for adopting modern development practices within the company. https://github.com/symmetryinvestments/overview https://github.com/atilaneves/dpp https://dlang.org/blog/2017/05/31/project-highlight-excel-d/ https://github.com/libmir/mir-algorithm As a D/C++ Quantitative developer you will work closely with the analytics and research groups to develop analytics and tools to support the investment and research processes of Symmetry. Hard Requirements: We are looking for mature hackers with a moral compass and sense of responsibility who have kept their imaginativeness. We value interest and capabilities as much as formal experience. Academic credentials are not a requirement if you can demonstrate outstanding capabilities, but for this role you should have a strong knowledge of quantitative techniques and computer science - data structures and algorithms. You should also have strong knowledge of declarative programming. You should be comfortable with the finer points of D and C++, and you should be ready and able to go deep when necessary to identify and address the root cause of problems. You are able to write and develop domain-specific languages where they are an appropriate solution to a business challenge. You will be working in a creative, often less-structured environment, with a high degree of autonomy to implement solutions. You are comfortable asking for help when you need it. You are capable of accepting direction should the longer-term strategic goals of the firm favour a particular solution fit. You are able to communicate both at the level of ideas and concretely either in writing or in person/by telephone. The ability to be diplomatic is valuable, but not absolutely required. You have a pragmatic devotion to excellence: the ability to recognize and evaluate interim solutions, while not being satisfied about retaining a hack in the long run. You should recognise the costs of boilerplate and appreciate the aesthetic and commercial benefits of designs that involve writing as little code as possible. You should care deeply about design and code quality, and recognise that performance matters more often than not. You are able to think about problems in a generic, high-level way AND pragmatically use common sense. You can think associatively and hold a complex mental picture in your head as well as work sequentially. An ability to think clearly and to act decisively in occasional high-pressure moments is desirable. Soft Requirements: Knowledge of the below will be helpful: Languages: 5 years or more experience with D and C++; Python and Haskell or Ocaml Location: We currently work with certain remote developers as consultants. We view remote work as a way to collaborate with outstanding talent beyond the locations where we
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Sunday, 13 May 2018 at 16:23:49 UTC, Nikos wrote:
I'm trying to wrap drepl
(https://github.com/dlang-community/drepl)
My dub.sdl files is
import autowrap.python;
mixin(
wrapAll(
LibraryName("drepl"),
Modules("drepl.interpreter"),
)
);
I also flagged `export` the interpreter function
export Interpreter!Engine interpreter(Engine)(return scope
Engine e) if (isEngine!Engine)
{
// workaround Issue 18540
return Interpreter!Engine(() @trusted { return move(e);
}());
}
I build the library with python35, but when I import it from
python idle, I cannot access the `interpreter` function at all.
I have the feeling I miss something essential here, but I don't
know what it is.
Any ideas?
Eg turn this into a function and try wrapping this instead:
auto intp = interpreter(dmdEngine());
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Thursday, 10 May 2018 at 19:50:40 UTC, Nikos wrote:
In my dub.sdl file I have
configuration "python35" {
subConfiguration "autowrap" "python35"
}
and I run
dub build --config=python35
which still tries to find python36. Why doesn't it look for 3.5?
Hi. On my phone so can't copy paste. Edit your dub.sdl under
the python35 subconfiguration and change python 36 to python35.
Re: A bit more Emscripten
On Thursday, 10 May 2018 at 08:32:07 UTC, Vladimir Panteleev wrote: On Tuesday, 8 May 2018 at 08:53:36 UTC, Vladimir Panteleev wrote: https://github.com/CyberShadow/dscripten-tools Progress update: - std.stdio.writeln() works - Using a D main() works (though unittests and static constructors still don't) - WebAssembly output works! - std.allocator works (at least, Mallocator + building-blocks do) Very cool, Vladimir. When I get time we will try to see if it's useful for some internal prototype tools.
Re: Binderoo additional language support?
On Thursday, 10 May 2018 at 02:39:41 UTC, Paul O'Neil wrote: On 05/09/2018 03:50 PM, Ethan wrote: On Tuesday, 8 May 2018 at 14:28:53 UTC, jmh530 wrote: I don't really understand what to use binderoo for. So rather than fill out the questionnaire, maybe I would just recommend you do some work on wiki, blog post, or simple examples. Been putting that off until the initial proper stable release, it's still in a pre-release phase. But tl;dr - It acts as an intermediary layer between a host application written in C++/.NET and libraries written in D. And as it's designed for rapid iteration, it also supports recompiling the D libraries and reloading them on the fly. Full examples and documentation will be coming. Would it make sense to build a REPL or Jupyter kernel on top of Binderoo? I made a start at writing a Jupyter library for writing kernels in D. Not sure how long it will be till its finished, but it is something in time we will need. Note that one would then need to write a D kernel on top, but that bit should be easy.
Re: A bit more Emscripten
On Tuesday, 8 May 2018 at 18:44:06 UTC, Vladimir Panteleev wrote: On Tuesday, 8 May 2018 at 09:51:11 UTC, Mike Franklin wrote: I've been recently assigned the task of building a web-based Ladder Logic editor/compiler (https://en.wikipedia.org/wiki/Ladder_logic). This would not be a short-lived application, however. Hmm, sounds like this would be an interactive application that would need access to the HTML DOM. Currently, this isn't directly possible - when running in an asm.js VM, there is no D type to represent a JavaScript object. It is possible to call out to / eval JavaScript, though, so perhaps it could be possible using a shim, where a JavaScript array holds JavaScript/DOM objects, and D refers to them by index. Maybe we could port something like this to D. Or wait till someday dpp can #include the STL. https://github.com/mbasso/asm-dom/blob/master/README.md
Re: Announcing Mecca
On Friday, 4 May 2018 at 05:23:51 UTC, Shachar Shemesh wrote: Hello everybody, I am very happy to announce that Mecca version 0.0.1 (sorry, no more zeros than that) is now officially available. You can get the source code at https://github.com/weka-io/mecca. The API documentation is at https://weka-io.github.com/mecca/docs. [...] https://www.reddit.com/r/programming/comments/8gxrkg/wekaio_open_sources_mecca_dlang_library_for_nogc?sort=new
Re: auto: useful, annoying or bad practice?
On Friday, 4 May 2018 at 04:12:09 UTC, Nick Sabalausky (Abscissa) wrote: On 05/02/2018 10:05 AM, H. S. Teoh wrote: [...] I don't doubt that. Similar to global namespace, if the structural typing is only used heavily by one or two components of a project (ie, libs, etc), then it's not too difficult to avoid problems. The real danger and problems come when a project uses several components that all make heavy use of either a global namespace (which D luckily doesn't really have) or structural typing. [...] Have you seen Atila's concepts library?
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Wednesday, 18 April 2018 at 15:28:07 UTC, Atila Neves wrote: http://code.dlang.org/packages/autowrap This came out of the need at work to take existing D code and make it available for both Excel and Python. Both pyd and excel-d make the reasonable assumption that one is using them to write code specifically for those environments. That breaks when there's existing production D code one wants to wrap. https://www.reddit.com/r/programming/comments/8eb12m/autowrap_v001_automatically_wrap_existing_d_code/
Re: Who says we can't call C++ constructors?
On Saturday, 21 April 2018 at 12:41:02 UTC, Atila Neves wrote: From https://dlang.org/spec/cpp_interface.html: "C++ constructors, copy constructors, move constructors and destructors cannot be called directly in D code". O RLY? Atila https://www.reddit.com/r/programming/comments/8eat5o/calling_c_constructors_from_d/ https://github.com/atilaneves/dpp
Re: Vtable for virtual functions in D
On Wednesday, 7 March 2018 at 21:14:12 UTC, Henrik wrote: Many important libraries like ICU have C interfaces even when written in C++. The direct support of C headers would be very convenient in migrating parts of C/C++ projects to D. It would also open up POSIX which is used extensively in our work. This looks great: https://github.com/D-Programming-Deimos/ but it must be tedious to keep such files up to date. "Are there any plans to support the direct inclusion [of] C header files?" Yes, very shortly, as an extra build step. Watch this space.
Re: [OT] Unity migrating parts of their engine from C++ into High Performace C# (HPC#)
On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
- Only structs are used, no classes;
- .NET collections are replaced by native collections that
manage their own memory
- No code that would trigger GC is allowed
- Compiler is aware of Unity features and is able to explore
SIMD, by doing auto-vectorization, and transparently
transform structs fields into optimal representations
The struct type in C# is more versatile than the D's
equivalent, mainly because of the fact that you can inherit
interfaces. You can have template constraints in D but this is
not as user friendly as a struct interface.
So in C# you can write code like this:
interface IRange
{
void popFront();
bool empty();
T front();
}
struct MyRange: IRange
{
//implementation
}
void foo(IRange someRange)
{
//do something with someRange even it's a struct
//this includes code completion and other IDE specific stuff.
}
In D, template constrains are not very clean and they not have
IDE support:
void foo(T)(T someRange) if (isInputRange!T)
{
}
You can do that in D too - see Atila's concepts library.
Re: [OT] Unity migrating parts of their engine from C++ into High Performace C# (HPC#)
On Tuesday, 3 April 2018 at 01:31:12 UTC, Laeeth Isharc wrote:
On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
- Only structs are used, no classes;
- .NET collections are replaced by native collections that
manage their own memory
- No code that would trigger GC is allowed
- Compiler is aware of Unity features and is able to explore
SIMD, by doing auto-vectorization, and transparently
transform structs fields into optimal representations
The struct type in C# is more versatile than the D's
equivalent, mainly because of the fact that you can inherit
interfaces. You can have template constraints in D but this is
not as user friendly as a struct interface.
So in C# you can write code like this:
interface IRange
{
void popFront();
bool empty();
T front();
}
struct MyRange: IRange
{
//implementation
}
void foo(IRange someRange)
{
//do something with someRange even it's a struct
//this includes code completion and other IDE specific
stuff.
}
In D, template constrains are not very clean and they not have
IDE support:
void foo(T)(T someRange) if (isInputRange!T)
{
}
You can do that in D too - see Atila's concepts library.
interface IFoo {
int foo(int i, string s) @safe;
double lefoo(string s) @safe;
}
@implements!(Foo, IFoo)
struct Foo {
int foo(int i, string s) @safe { return 0; }
double lefoo(string s) @safe { return 0; }
}
// doesn't compile
/*
@implements!(Oops, IFoo)
struct Oops {}
*/
Re: D beyond the specs
On Saturday, 17 March 2018 at 16:26:27 UTC, Guillaume Piolat wrote: While France is all about status (titles, living well over your means), and people prefer to learn "high-status" languages, I guess this is the profile of late adopters everywhere. Yes, status seems one of the most important things for normal people. But there's a repeating pattern in life. A small group, drawn to do something for intrinsic reasons starts to create something. And they get no face because it seems completely unrealistic and in truth the odds are very much against success. But they create something excellent because they care about intrinsic reasons and not social factors. And some people start to take notice, but it's still more or less a fringe but interesting project. And it stays that way until the world changes, and changes in a way that looks obvious with hindsight but nobody really expected at the time. At that point what's important changes and the project starts to become popular. Then people more ambitiously than intrinsically motivated start to be drawn by what's now obvious and the project starts to be popular, and yet with that popularity comes a change in its nature and sometimes people think back to the old days. So I think that pattern might apply to D, and if that's right one might as well focus on the challenges before one and enjoy the benefits from the present makeup of the community. Because as adoption grows eventually the makeup will change too. If you're good and care about what's important, eventually status comes to you. And now you've got more problems to worry about. But life isn't about banishing problems, but overcoming them.
Re: D beyond the specs
On Friday, 16 March 2018 at 18:38:44 UTC, Aurélien Plazzotta wrote: On Friday, 16 March 2018 at 11:44:59 UTC, Chris wrote: Would it be possible to find out at DConf in Munich why exactly D is so popular in Germany (my impression) and in other countries of Europe (and that general post code) like France, Italy, GB, Romania and Russia etc.? To the best of my knowledge, there is currently no job offer in D programming in France. It is not even required/highlighted as a second/bonus skill to apply for a job. Perhaps it is used within a research and development department of very few companies for very specific tasks but it's unheard of and the mentalities of top management won't change before long because we are a retarded population who needs a lot of safety nets and huge amounts of guarantees to actually to take action... Also, french citizens don't like taking financial and technological risks, now adopting D for profesionnal use is a big one. And yet in Paris lives a man, presumably a French citizen, who was working on a cryptocurrency scaling startup last dconf and that ended up being part of the path towards launching Bitcoin Cash. So some French citizens don't seem to mind taking risks or trying new things, and if there is a dampening of entrepreneurial spirits it might be the government and culture. That's just one example, but the outliers can often tell you more than those in the centre of the distribution. It seems like it's already beginning to change slowly. It wasn't long ago that speaking about the French startup scene was more like the punchline to a joke. Today it's something real and I think will grow further from here. Things change slowly in the beginning. Top management aren't the ones to start doing something creative unless they are a highly unusual kind of firm. It's people who can decide or who don't need to ask anyone's permission that are the early adopters. Anyway I asked Walter about why so many Germans in the D community. No final answer. It's interesting that Walter is of German descent. A controversial topic, but in my experience what you are from shapes who you are, how you think and what you value. And receptivity to a particular way of doing things isn't uniform across the world.
