Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 13:33:29 UTC, Russel Winder wrote: Brilliant, DConf comes to the UK, I can get to it… except… it's on at the exact same time as DevoxxUK 2019 which is at the Business Design Centre. :-( Programming languages are unimportant anyway.
Re: My Meeting C++ Keynote video is now available
On Tuesday, 15 January 2019 at 06:57:28 UTC, Paul Backus wrote: On Tuesday, 15 January 2019 at 05:18:45 UTC, aliak wrote: Quote from article: "The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python. On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits." Does this take into account the experience of the programmers writing in each language? Given their relative popularity, I imagine PHP and Python have many more beginning programmers writing code in them than Haskell and Clojure. Not that I saw in the paper no. But that is a good point.
Re: My Meeting C++ Keynote video is now available
On Tuesday, 15 January 2019 at 05:18:45 UTC, aliak wrote: Quote from article: "The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python. On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits." Does this take into account the experience of the programmers writing in each language? Given their relative popularity, I imagine PHP and Python have many more beginning programmers writing code in them than Haskell and Clojure.
Re: My Meeting C++ Keynote video is now available
On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 If nothing else please watch the opening story, it's true and quite funny :o). Now as to the talk, as you could imagine, it touches on another language as well... Andrei Awesome talk! As usual. Regarding this quote: "The ruby guy next to you is writing just as crappy code..." I don't think that's really correct. The reference is code complete, which is published in 93 (i.e. no java, no ruby, before the stl even?) and i believe (just googled this so may be wrong) the reference in that book is from a 1977 paper on programmer quality and productivity and the 2004 edition of code complete changes the number form 15 to 50 / 1000 to 1 .. 25 / 1000, but references the same paper afaik. Here's a more recent study: http://rayb.info/uploads/cacm2017-lang.pdf Here's an article that summarizes it -> https://www.i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html Quote from article: "The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python. On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits." Also this is more anecdotal, but for example going from objective-c to swift, the number of non-application-specific bugs per line (regardless of whether or not that's even a good measure 路♂️), i feel, has gone down by an exaggerated order of magnitude. Cheers, - Ali
Re: My Meeting C++ Keynote video is now available
On Mon, 14 Jan 2019 21:12:48 +, Paul Backus wrote: > On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote: >> Is it possible to declare a function whose name is a CTFE computed >> string? > > Yes, if you do it with a string mixin. And more simply, you can declare a function with a hard-coded name, then use an alias to expose it under a different name.
Re: My Meeting C++ Keynote video is now available
On 1/14/2019 10:49 AM, Jacob Carlborg wrote: But Ddoc has macros ;) Indeed it does. But the macros cannot be used to create syntax, and there is no token concatenation. Macros cannot define other macros.
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 21:22:32 UTC, Andre Pany wrote: On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote: On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 If nothing else please watch the opening story, it's true and quite funny :o). Now as to the talk, as you could imagine, it touches on another language as well... Andrei A lot of the questions were about documenting the hook API and catching misspelling errors when defining a hook. It seems like it would be nice if you could list the hook method names a static array or dictionary or struct containing a field for each method, etc. One each for the required and optional methods. The hook author could grab the name/signature of the method they're intending to implement from that data structure and any misspellings would be caught immediately. Is it possible to declare a function whose name is a CTFE computed string? For ranges there are concepts like Input Range. A struct/class must have several methods to be compliant. You can check the compliance using function isInputRange https://dlang.org/library/std/range/primitives/is_input_range.html Maybe something similiar can be done here. Not checking individual methods, but concepts... Kind regards Andre I don't think that's quite sufficient because a hook may/may not have the optional methods, and could have extra stuff. What you want is to specify per method "this method is part of the hook interface," which as I type it kind of sounds like the job of an annotation...
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote: On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 If nothing else please watch the opening story, it's true and quite funny :o). Now as to the talk, as you could imagine, it touches on another language as well... Andrei A lot of the questions were about documenting the hook API and catching misspelling errors when defining a hook. It seems like it would be nice if you could list the hook method names a static array or dictionary or struct containing a field for each method, etc. One each for the required and optional methods. The hook author could grab the name/signature of the method they're intending to implement from that data structure and any misspellings would be caught immediately. Is it possible to declare a function whose name is a CTFE computed string? For ranges there are concepts like Input Range. A struct/class must have several methods to be compliant. You can check the compliance using function isInputRange https://dlang.org/library/std/range/primitives/is_input_range.html Maybe something similiar can be done here. Not checking individual methods, but concepts... Kind regards Andre
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote: Is it possible to declare a function whose name is a CTFE computed string? Yes, if you do it with a string mixin.
Re: My Meeting C++ Keynote video is now available
On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 If nothing else please watch the opening story, it's true and quite funny :o). Now as to the talk, as you could imagine, it touches on another language as well... Andrei A lot of the questions were about documenting the hook API and catching misspelling errors when defining a hook. It seems like it would be nice if you could list the hook method names a static array or dictionary or struct containing a field for each method, etc. One each for the required and optional methods. The hook author could grab the name/signature of the method they're intending to implement from that data structure and any misspellings would be caught immediately. Is it possible to declare a function whose name is a CTFE computed string?
Re: My Meeting C++ Keynote video is now available
On Mon, Jan 14, 2019 at 08:38:39PM +, Guillaume Piolat via Digitalmars-d-announce wrote: [...] > Other people often lack interest because of real or perceived template > bloat, and it's critical. > > - I think it's important to emphasize CTFE over template > instantiations because (per Stefan's measurements) template > instantiations are a lot slower and CTFE is already surprisingly > faster than template meta-programming, and on the road to become even > faster with the superbly needed newCTFE. I think another angle of attack that AFAICT has been mostly overlooked is for the compiler to recognize certain common template patterns, and optimize away intermediate template instantiations that are not actually necessary. Not every template instantiation requires wholesale copying of the AST. I surmise certain patterns of templates could be profitably turned into some kind of compile-time executed code. T -- Без труда не выловишь и рыбку из пруда.
Re: My Meeting C++ Keynote video is now available
On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 If nothing else please watch the opening story, it's true and quite funny :o). Now as to the talk, as you could imagine, it touches on another language as well... Andrei About the adoption and success of DbI libraries: - Buried inside your talks there are lots of hard-earned principles: "What's missing is as important as what's here" "Big interfaces are good" etc... We have a lack of DbI designers such as yourself or Vladimir so a short text that teach how to design with DbI could be in order. I redirect people to "std::allocator is to allocation what std::vector is to vexation" because it seems to be the only tutorial on this. Other people often lack interest because of real or perceived template bloat, and it's critical. - I think it's important to emphasize CTFE over template instantiations because (per Stefan's measurements) template instantiations are a lot slower and CTFE is already surprisingly faster than template meta-programming, and on the road to become even faster with the superbly needed newCTFE.
Re: code-d 0.20.0 - serve-d 0.4.0 - Happy new year!
On Sunday, 13 January 2019 at 21:40:43 UTC, Murilo wrote: On Monday, 31 December 2018 at 17:42:46 UTC, WebFreak001 wrote: [...] It would be a good idea to publish that on the facebook group for users of D. There you would be able to spread the information fast. It is called Programming in D. Here is the link: https://www.facebook.com/groups/662119670846705/ sorry I don't use Facebook, but I would be glad if anyone who posts stuff there could share this :)
Top Five World’s Most Underrated Programming Languages
Of possible interest: https://www.technotification.com/2019/01/most-underrated-programming-languages.html
Re: My Meeting C++ Keynote video is now available
On 2019-01-14 15:42, Steven Schveighoffer wrote: That's a bad example :) The clear answer is mysql-native, which is what vibe.d recommends. Exactly, and I don't need five minutes for that. Five seconds is enough :) -- /Jacob Carlborg
Re: My Meeting C++ Keynote video is now available
On 2019-01-14 08:50, Walter Bright wrote: Interesting cites, which provide a basis for why I've opposed AST macros, and why Ddoc and unittest are builtin (and a few other things). But Ddoc has macros ;) -- /Jacob Carlborg
Re: My Meeting C++ Keynote video is now available
On Mon, Jan 14, 2019 at 03:57:36PM +, Adam D. Ruppe via Digitalmars-d-announce wrote: > On Monday, 14 January 2019 at 14:56:00 UTC, bachmeier wrote: > > Only a small sliver of programming involves anything where "overhead > > of a runtime" is an issue. I hope you intend this comment as > > pertaining to Better C usage. > > Real D is the true better C. These improvements can improve in various > situations. > > That said though, I'd be against removing built-in classes and > interfaces. They are useful in a lot of places built in... Yeah, much as I'm a big promoter of struct-based range-based template style D code, classes and interfaces do still have their place. When you need runtime dynamic polymorphism, it just makes sense to use classes and interfaces instead of trying to bandage your way around structs and CT introspection. I'm still searching for a theoretical model that would bridge the gap between the two and make one unified model, but for now, they each still have their place. > though I kinda wish the runtime code was a bit thinner and lighter > too. Yeah, the whole thing about the monitor field IMO is an unnecessary burden on a use case that isn't always needed. If synchronized classes or whatever needs it, then it should be an ABI specific to synchronized classes. Everybody else shouldn't need to pay tax on it if they never actually need to use it. T -- Shin: (n.) A device for finding furniture in the dark.
Re: My Meeting C++ Keynote video is now available
On 1/14/19 10:57 AM, Adam D. Ruppe wrote: On Monday, 14 January 2019 at 14:56:00 UTC, bachmeier wrote: Only a small sliver of programming involves anything where "overhead of a runtime" is an issue. I hope you intend this comment as pertaining to Better C usage. Real D is the true better C. These improvements can improve in various situations. That said though, I'd be against removing built-in classes and interfaces. They are useful in a lot of places built in... though I kinda wish the runtime code was a bit thinner and lighter too. Some of the old crufty features of classes can be jettisoned like toString and toHash, and object.factory. -Steve
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 14:56:00 UTC, bachmeier wrote: Only a small sliver of programming involves anything where "overhead of a runtime" is an issue. I hope you intend this comment as pertaining to Better C usage. Real D is the true better C. These improvements can improve in various situations. That said though, I'd be against removing built-in classes and interfaces. They are useful in a lot of places built in... though I kinda wish the runtime code was a bit thinner and lighter too.
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 03:58:37 UTC, Mike Franklin wrote: Because design by introspection allows us to "assemble programs atomically", perhaps high-level language features like classes and interfaces can become obsolete, and the language itself can be reduced simpler primitives that don't require the overhead of a runtime. Only a small sliver of programming involves anything where "overhead of a runtime" is an issue. I hope you intend this comment as pertaining to Better C usage.
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 10:06:48 UTC, Mike Franklin wrote: On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote: When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything. [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory) I think D's structs are a sufficient object system for such a focal point. With design by introspection, `alias`, templates, `alias this`, `static if`, CTFE, mixins, and a few new D features, classes would be unnecessary. Rust and Zig are pretty good examples of this. D's implementation could even be improved to keep its runtime, yet still allow D to be used as I'm suggesting, without introducing any breakage for anyone. I made some significant progress in that direction when I was working on the compiler in the 2017~2018 timeframe, but my abilities ultimately fell short, and I couldn't see a way forward without support. Mike Killing classes will kill my interest and investment in D. Alex.
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote: Scheme is probably the language that takes this idea of a minimal "core language" with powerful metaprogramming facilities the furthest, and the result is a fragmented ecosystem that makes writing portable, non-trivial programs close to impossible. (See "The Lisp Curse" [1].) Much as I hate to disagree with folks on the internet, this is an explanation in search of an example. Scheme was originally created as a toy language so Steele and Sussman could have an object oriented language with actors.[1] It later turned out to be a good language for SICP. Macros did not even appear in the Scheme standard until R4RS, and they were not part of the standard until R5RS in 1998, 23 years after initial work started on Scheme. That's not to say that individual implementations didn't have Common Lisp macros prior to R5RS, but the metaprogramming thing was more of a Common Lisp thing than a Scheme thing. To me, it's obvious why Scheme has never taken off. It wasn't created as a language for widespread commercial usage. That was the realm of Common Lisp, and to some extent Common Lisp succeeded. CL was not killed by excessive use of macros. I'll also note that R started as a dialect of Scheme, but it was designed for practical use from the start, and it has millions of users. D has little hope of ever achieving the popularity of R. You can do all kinds of metaprogramming with R. I got tired of R's lack of proper tail call support, so added a working implementation of Clojure's recur in a couple of hours. Extrapolating from Scheme to D is simply not the best use of one's time. [1] See page 33 of https://dreamsongs.com/Files/HOPL2-Uncut.pdf
Re: My Meeting C++ Keynote video is now available
On 1/14/19 5:18 AM, Martin Tschierschke wrote: On Monday, 14 January 2019 at 07:50:32 UTC, Walter Bright wrote: On 1/13/2019 9:31 PM, Paul Backus wrote: Scheme is probably the language that takes this idea of a minimal "core language" with powerful metaprogramming facilities the furthest, and the result is a fragmented ecosystem that makes writing portable, non-trivial programs close to impossible. (See "The Lisp Curse" [1].) When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything. [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory) Interesting cites, which provide a basis for why I've opposed AST macros, and why Ddoc and unittest are builtin (and a few other things). Also, before std::string came along in C++, everyone invented their own string class, and as a result, nobody could share code. This is exactly the argument to get a database driver (mysql,postgres...) and probably a webserver in std. I don't like the idea of it, because there are so many approaches. Even different approaches among one server protocol. But to avoid getting std.lib to big, the D Foundation might adopt some third party libs as core libraries, so they get maintained within the D Foundation Git account to make them somehow official. We are now approaching the 1500 Dub package, and the ecosystem becomes more and more complex. This is true, I searched yesterday for a decimal package that fits my use case (I'm getting decimal numbers as strings in a JSON library, with no limits as to what number of decimal places are supported). There were probably 4 or 5 that implement the general concept of a decimal type, but I was faced with a couple issues: 1. Is it maintained? Some of them are really old, some are old-ish, but could potentially be pretty stable 2. Does it have all the features I want? I am hesitant at this point to select something that has overflow problems, because I don't actually know how much would be too much. With one central package, I can be sure that 1 is answered, but then I don't actually have any choices for whether it works for me or not. If it doesn't implement the features I want (basically, I want completely arbitrary precision AND number of digits), then I still have to roll my own. Some packages are hard to solve every, if not most, requirements. Really that should be the defining feature of whether it goes into the standard library. (https://code.dlang.org/ 1482 packages: The search for mysql now returns 23 packages. Please tell me which to use for the back end, of your own vibe.d app. I give you 5 minutes...:-) Regards mt. That's a bad example :) The clear answer is mysql-native, which is what vibe.d recommends. -Steve
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 13:07:35 UTC, aberba wrote: Do people really use Rust in production beyond the safety die hards (of course Mozilla and few uses here and there, mostly C guys...lowlevel purists)? Its such a weird,complicated and academic lang... doubt it'll ever be mainstream like D is supposed to be. Actually, a lot of people do. Many big companies are getting interested in Rust and many game developers are investigating its capabilities. Rust seems to be mostly appealing to C/C++ programmers who are looking for an alternative.
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 10:06:48 UTC, Mike Franklin wrote: On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote: When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything. [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory) I think D's structs are a sufficient object system for such a focal point. With design by introspection, `alias`, templates, `alias this`, `static if`, CTFE, mixins, and a few new D features, classes would be unnecessary. Rust and Zig are pretty good examples of this. Do people really use Rust in production beyond the safety die hards (of course Mozilla and few uses here and there, mostly C guys...lowlevel purists)? Its such a weird,complicated and academic lang... doubt it'll ever be mainstream like D is supposed to be.
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote: [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html This part always feels familiar to me in D (just replace Lisp with D and Haskell with say Rust): Answer: The Lisp Curse kicks in. Every second or third serious Lisp hacker will roll his own implementation of lazy evaluation, functional purity, arrows, pattern matching, type inferencing, and the rest. Most of these projects will be lone-wolf operations. Thus, they will have eighty percent of the features that most people need (a different eighty percent in each case). They will be poorly documented. They will not be portable across Lisp systems. Some will show great promise before being abandoned while the project maintainer goes off to pay his bills. Several will beat Haskell along this or that dimension (again, a different one in each case), but their acceptance will be hampered by flame wars on the comp.lang.lisp Usenet group. also this one: I saw this 10 years ago when looking for a GUI to my Lisp. No problem, there were 9 different offerings. The trouble was that none of the 9 were properly documented and none were bug free. Basically each person had implemented his own solution and it worked for him so that was fine.
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 07:50:32 UTC, Walter Bright wrote: On 1/13/2019 9:31 PM, Paul Backus wrote: Scheme is probably the language that takes this idea of a minimal "core language" with powerful metaprogramming facilities the furthest, and the result is a fragmented ecosystem that makes writing portable, non-trivial programs close to impossible. (See "The Lisp Curse" [1].) When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything. [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory) Interesting cites, which provide a basis for why I've opposed AST macros, and why Ddoc and unittest are builtin (and a few other things). Also, before std::string came along in C++, everyone invented their own string class, and as a result, nobody could share code. This is exactly the argument to get a database driver (mysql,postgres...) and probably a webserver in std. But to avoid getting std.lib to big, the D Foundation might adopt some third party libs as core libraries, so they get maintained within the D Foundation Git account to make them somehow official. We are now approaching the 1500 Dub package, and the ecosystem becomes more and more complex. (https://code.dlang.org/ 1482 packages: The search for mysql now returns 23 packages. Please tell me which to use for the back end, of your own vibe.d app. I give you 5 minutes...:-) Regards mt.
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote: When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything. [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory) I think D's structs are a sufficient object system for such a focal point. With design by introspection, `alias`, templates, `alias this`, `static if`, CTFE, mixins, and a few new D features, classes would be unnecessary. Rust and Zig are pretty good examples of this. D's implementation could even be improved to keep its runtime, yet still allow D to be used as I'm suggesting, without introducing any breakage for anyone. I made some significant progress in that direction when I was working on the compiler in the 2017~2018 timeframe, but my abilities ultimately fell short, and I couldn't see a way forward without support. Mike
