Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 05:43:13 UTC, Walter Bright wrote: Often I'll pipe the pretty-printed debug output to a file, as it can be voluminous, and then actually edit the file to bring out what I need. Not possible with a debugger. I think it is. Here is a small adjustment to consider for your workflow. Continue instrumenting your code with capability to print things as you like - data structures, etc. Then when you need to debug something, rather than (throw in print, compile, run, diagnose repeat) drop into gdb judiciously and call print, examine the output. Need more data do it again with the same executable. The savings is no need to repeatedly build/litter code with prints and you would use the debugger and your current style. I seriously doubt you would change your style as you appear quite fond of it - clearly it works for you. The point though is others do find value in the debugger and this is one reason. Also, there are pretty printers of data structures for gdb and if you don't like them you could write your own. (dmd can have pretty complex relationships between data structures and the path through the code. I might want to look at these fields of a type, but not those fields. Etc. I.e. I routinely build custom debugging aids for particular problems.)
Re: Walter's DConf 2014 Talks - Topics in Finance
On Monday, 22 December 2014 at 13:37:55 UTC, aldanor wrote: For some reason, people often relate quant finance / high frequency trading with one of the two: either ultra-low-latency execution or option pricing, which is just wrong. In most likelihood, the execution is performed on FPGA co-located grids, so that part is out of question; and options trading is just one of so many things hedge funds do. What takes the most time and effort is the usual data science (which in many cases boil down to data munging), as in, managing huge amounts of raw structured/unstructured high-frequency data; extracting the valuable information and learning strategies; This description feels too broad. Assume that it is the data munging that takes the most time and effort. Included in that usually involves some transformations like (Data - Numeric Data - Mathematical Data Procssing - Mathematical Solutions/Calibrations - Math consumers (trading systems low frequency/high frequency/in general)). The quantitative data science is about turning data into value using numbers. The better you are at first getting to an all numbers world to start analyzing the better off you will be. But once in the all numbers world isn't it all about math, statistics, mathematical optimization, insight, iteration/mining, etc? Isn't that right now the world of R, NumPy, Matlab, etc and more recently now Julia? I don't see D attempting to tackle that at this point. If the bulk of the work for the data sciences piece is the maths, which I believe it is, then the attraction of D as a data sciences platform is muted. If the bulk of the work is preprocessing data to get to an all numbers world, then in that space D might shine. implementing fast/efficient backtesting frameworks, simulators etc. The need for efficiency here naturally comes from the fact that a typical task in the pipeline requires dozens/hundreds GB of RAM and dozens of hours of runtime on a high-grade box (so noone would really care if that GC is going to stop the world for 0.05 seconds). What is a backtesting system in the context of Winton Capital? Is it primarily a mathematical backtesting system? If so it still may be better suited to platforms focusing on maths.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Monday, 22 December 2014 at 19:25:51 UTC, aldanor wrote: On Monday, 22 December 2014 at 17:28:39 UTC, Daniel Davidson wrote: I don't see D attempting to tackle that at this point. If the bulk of the work for the data sciences piece is the maths, which I believe it is, then the attraction of D as a data sciences platform is muted. If the bulk of the work is preprocessing data to get to an all numbers world, then in that space D might shine. That is one of my points exactly -- the bulk of the work, as you put it, is quite often the data processing/preprocessing pipeline (all the way from raw data parsing, aggregation, validation and storage to data retrieval, feature extraction, and then serialization, various persistency models, etc). I don't know about low frequency which is why I asked about Winton. Some of this is true in HFT but it is tough to break that pipeline that exists in C++. Take live trading vs backtesting: you require all that data processing before getting to the math of it to be as low latency as possible for live trading which is why you use C++ in the first place. To break into that pipeline with another language like D to add value, say for backtesting, is risky not just because the duplication of development cost but also the risk of live not matching backtesting. Maybe you have some ideas in mind where D would help that data processing pipeline, so some specifics might help?
Re: Walter's DConf 2014 Talks - Topics in Finance
On Tuesday, 23 December 2014 at 03:07:10 UTC, Laeeth Isharc wrote: At one very big US hf I worked with, the tools were initially written in Perl (some years back). They weren't pretty, but they worked, and were fast and robust enough. I has many new features I needed for my trading strategy. But the owner - who liked to read about ideas on the internet - came to the conclusion that Perl was not institutional quality and that we should therefore cease new development and rewrite everything in C++. Two years later a new guy took over the larger group, and one way or the other everyone left. I never got my new tools, and that certainly didn't help on the investment front. After he left a year after that they scrapped the entire code base and bought Murex as nobody could understand what they had. If we had had D then, its possible the outcome might have been different. Interesting perspective on the FI group's use of perl. Yes that group was one of the reasons a whole new architecture committee was established to prevent IT tool selection (like Perl and especially Java) the firm did not want to be used or supported. Imagine after that being prohibited from using Python. Having to beg to get to use it embedded from C++ and when finally granted permission having to rewrite the much of boost python since boost was not a sanctioned tool. Big companies make decisions differently than others. I believe D would not have been a help in that organization and requesting its use would have been the surest way to get a termination package. That said, in other organizations D might have been a good choice. So in any case, hard to generalise, and better to pick a few sympathetic people that see in D a possible solution to their pain, and use patterns will emerge organically out of that. I am happy to help where I can, and that is somewhat my own perspective - maybe D can help me solve my pain of tools not up to scratch because good investment tool design requires investment and technology skills to be combined in one person whereas each of these two are rare found on their own. (D makes a vast project closer to brave than foolhardy), It would certainly be nice to have matrices, but I also don't think it would be right to say D is dead in water here because it is so far behind. It also seems like the cost of writing such a library is v small vs possible benefit. I did not say D is dead in the water here. But when it comes to math platforms it helps to have lots of people behind the solution. For math julia seems to have that momentum now. Maybe you can foster that in D.
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 19:20:15 UTC, Walter Bright wrote: On 12/19/2014 7:38 AM, Daniel Davidson wrote: Could this lack of need be attributable to understanding of the entire code base being used? No. It's attributable to I use different methods of debugging. The dmd source code is littered with debugging aids I've written. The classic example is having a pretty-printer for each data structure. I don't find the typical debugger pretty-printer to be adequate at all - they never dump the type in the way that I think about the type. Sure, sounds like a winning strategy. Probably not applicable, but were you to run into an issue with vibe or websockets would you proceed to write pretty printers for the supplied data structures, the returned data structures, etc, or would you live with the not so pretty gdb structures just to get your debug session over with? The point is it seems like more of your work on code is working with your own code - i.e. fewer outside dependencies or outside dependencies that you are intimately familiar with due to years of experience. This reduces the benefit or need of the debugger.
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 12:52:32 UTC, uri wrote: This is true. The first week for a new developer where I work is developing a better boot loader. The debugger is not allowed during this induction week and as a result our devs learn how to write better code first time through careful planning and understanding of what's going on at the machine level. As you beat your chest over your boot loader - consider both this example and in general Walter's lack of need for a debugger. Could this lack of need be attributable to understanding of the entire code base being used? I imagine you don't have many outside dependencies for your boot loader. I imagine most of what Walter works on involves an entire stack that he has either written from ground up or when pulling outside dependencies in has much less surface area to deal with that is new to him. Contrast that with someone wanting to tie into a framework (vibed) or use a sophisticated library (websockets). Yes, you can stick with the real men don't use debuggers line, but that is much easier to stomach when your outside dependencies are small in scope. Isn't one of the best ways to learn a new codebase to step through it in the debugger? Maybe your devs learn how to write better code the first time through. But what happens when they are thrown new requirements on dependencies that are challenging to deal with?
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 16:27:03 UTC, H. S. Teoh via Digitalmars-d wrote: Could this lack of need be attributable to understanding of the entire code base being used? Nope. FWIW, I work with a large enterprise project that is far too large for anyone to grasp in its entirety, yet I don't find debuggers that helpful either. Well, they *are* helpful in some cases, just not as many as people often claim, as least not for me. The oft-maligned printf-debugging, when wisely used in a targeted way, is often better IME because I'm dealing with an embedded environment, where it's a pain to setup a debugger. Well, it *can't* run a full debugger; the best it can so is to run gdbserver which I then have to connect to remotely. Once that's setup, I run into the frustrating problem of gdb being unable to find the requisite symbols, needing to be in the same directory as the executable, being unable to locate the source file(s), being unable to resolve library symbols, ad nauseaum. I think that at least not for me is important there. Personally, I did not malign the printf debugging approach. However nothing is more painful than sitting through a printf debugging session with someone new to code who is using the printf to learn the code, when a perfectly good debugger is available. Is the embedded environment you describe the typical case? I'm not advocating, not reading or attempting to understand the code. But, assume you have your best understanding at hand and still have questions and/or bugs; you drop a breakpoint in code that is new to you. What you get is much more than the documentation: you get the callstack allowing you to navigate the code, you get the data allowing you to see the structures and their content. Problems with gdb does not take away from the benefit debugging in general. Remember this thread was started with someone having bugs in a windows environment. Not many advocate ignorance. Programmers do advocate laziness with good cause. In theory, if a person can successfully use code without understanding all details of its implementation then that person has made a mental cost savings. Maybe not so important to the set of coders here - but there is value in not being required to understand all details. One benefit of the separation of concerns between interfaces and implementation is the level of understanding required for the former might be significantly less than the latter. I imagine you don't have many outside dependencies for your boot loader. I imagine most of what Walter works on involves an entire stack that he has either written from ground up or when pulling outside dependencies in has much less surface area to deal with that is new to him. Unfortunately, your imagination isn't quite accurate in this case. How so? Is the bootloader using vibed or websockets? Does dmd use vibed or websockets? Of course your next reply can be all the complex libraries dmd uses internally to which I'll reply that all of those are code that Walter is likely intimately familiar with making it easy for him with his vast experience to not use a debugger. No one has to use a debugger, but I'm in the camp that they can make life easier especially when getting familiar with new code. Maybe here I'm in the minority. Contrast that with someone wanting to tie into a framework (vibed) or use a sophisticated library (websockets). Yes, you can stick with the real men don't use debuggers line, but that is much easier to stomach when your outside dependencies are small in scope. That is a false assumption, based on my experience as described above. How does your unfortunate situation of being with a large enterprise project that is far too large for anyone to grasp in its entirety, yet I don't find debuggers that helpful relate to the extent of dependencies and their impact on utility of a debugger? I get that in general you don't find debuggers useful, which is fine. When trying to understand a tangled mess of code that you did not write your preferred method is read the code and printf. Those are valuable. Maybe someone who rarely or never uses a debugger is not the best to gauge the benefit differential of a debugger on systems with few outside dependencies versus systems with heavy outside dependencies. Isn't one of the best ways to learn a new codebase to step through it in the debugger? [...] Absolutely not. You'd get lost in the forest *really* quickly and lose sight of the forest for the trees, especially in a large codebase where each logical operation may involve a dozen layers of abstraction, and lower-level code is all generic so you won't easily understand how it concretely fits into the big picture. For this, I recommend reading the source code instead(!). That's what the source code is for!! More chest beating. I don't see how the *addition* of a debugger causes one to get lost. I'm in
Re: Lost a new commercial user this week :(
So to sum things up 1. you blindly walked into something you had no real experience with, apart from some vague memory that some parts of vibed worked for you a while ago. Pure bile. No - reread the thread. 2. you knew the debugger might be an issue, if not _the_ issue, but chose not to test it beforehand, or couldn't test it beforehand, because 3. you were working on a foreign framework (and simply hoped things would work out fine, fingers crossed!). Isn't that what you would hope? I would. These are crucial bits of information that were missing from your first report. Please try to be more accurate the next time. Holding back crucial information gets us nowhere. It only leaves the (false) impression that D is completely unusable. How can you read this thread and think he was holding back anything. Everything he says is *easily* relatable and understandable. Besides he is trying to provide valuable information in a way that is much less abusive than many of the threads in this community. What I read was not that D is completely unusable but rather the D debug story on Windows is a big problem and it lost D some potential users.
Re: discuss disqus
On Tuesday, 5 August 2014 at 11:00:44 UTC, Klaim - Joël Lamotte via Digitalmars-d wrote: Hi, did you consider using Discourse at least as a replacement for comments system? http://www.discourse.org/ It's made by the guys who made stackoverflow.com and it's useful at least as an alternative to disqus and also obviously as a forum. Some blogs (using wordpress) do use Discourse for comments. However, Discourse backend is wrote using ruby so if you want to self host you have to do some install work but they simplified it apparently by providing a docker as the default installer. Curious why no one replied to this? I can not vouch for this one but it looks nice if you go to the demo site on the readme page: https://github.com/phusion/juvia As a meta-question - is there any way for threads like this be ended with some form of NextAction required? Or is the best course to just let it fall to the wayside? Thanks Dan
Re: My D book is now officially coming soon
On Monday, 3 March 2014 at 16:37:49 UTC, Adam D. Ruppe wrote: As some of you might know, I've been working on a D book over the last few months. It is now available as coming soon on the publisher's website: http://www.packtpub.com/discover-advantages-of-programming-in-d-cookbook/book Congrats. Is there a early access option, like Manning Early Access Program, instead of just pre-order? Thanks Dan
