Re: Replacing C's memcpy with a D implementation
Don't C implementations already do 90% of what you want? I thought most compilers know about and optimize these methods based on context. I thought they were *special* in the eyes of the compiler already. I think you are fighting a battle pitting 40 years of tweaking against you...
Re: D on top of Hacker News!
On Tuesday, 5 June 2018 at 20:15:07 UTC, Jonathan M Davis wrote: On Tuesday, June 05, 2018 15:09:56 Dejan Lekic via Digitalmars-d wrote: On Sunday, 3 June 2018 at 17:40:46 UTC, I love Ice Cream wrote: >> Is D really a top 20 language? I don't remember seeing it >> anywhere close to the top 20. >> >> https://www.tiobe.com/tiobe-index/ has them in 31 > > Top comment is kind of depressing. The right place to look is https://www.tiobe.com/tiobe-index/d/ I agree with other comments regarding TIOBE - they are constantly changing how they do statistics so they are not relevant source at all. Just look where Kotlin is there and that should pretty much tell you everything. I know at least 10 large companies that are moving from Java/Scala to Kotlin, yet Kotlin is at the bottom 50 table... Ridiculous... The TIOBE has never been a measurement of how much any given language is used. At best, it's been a measurement of which languages folks have been searching for. That can tell you something, but you have to understand what it's measuring to have any clue what it does tell you. And of course, because of how difficult it is to measure search results for a particular language, they keep changing their criteria. The result is that while the tiobe index may be interesting, it must be taken with a very large grain of salt - and that's without getting into any discussions of how valid it is or isn't to use search results from google to do the measuring. - Jonathan M Davis And all of the other metrics done by other groups that was provided that paints a similar picture? http://githut.info/ http://pypl.github.io/PYPL.html http://sogrady-media.redmonk.com/sogrady/files/2018/03/lang.rank_.118.png https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages https://insights.stackoverflow.com/survey/2016 I'm not really intending to crap on anyone here. It's just the dismissal of a collection of data all pointing towards one particular conclusion is a bit strange. It seems like the interest in D is going down not up. I mean it could have a renaissance, but I'd imagine some work would have to be put into that to make it happen.
Re: D on top of Hacker News!
On Monday, 4 June 2018 at 19:21:22 UTC, Ethan wrote: On Monday, 4 June 2018 at 19:17:47 UTC, I love Ice Cream wrote: It seems you guys are undercutting the results because you don't like them: Never mind that it is a commonly accepted criticism of the Tiobe index. Someone on the internet wants to strawman, so it must be valid! (The only source you listed there that would give unbiased search results is Wikipedia. Every other aggregate engine weighs results per user. Can you name something without valid criticisms? Things could always be done better. But that doesn't mean they aren't useful. In this case it isn't meant to be an all encompassing answer, just a viewpoint that suggests a particular answer.
Re: D on top of Hacker News!
On Monday, 4 June 2018 at 19:17:47 UTC, I love Ice Cream wrote: On Monday, 4 June 2018 at 16:05:24 UTC, rikki cattermole wrote: On 05/06/2018 3:56 AM, I love Ice Cream wrote: On Monday, 4 June 2018 at 11:14:42 UTC, bauss wrote: On Sunday, 3 June 2018 at 17:40:46 UTC, I love Ice Cream wrote: Is D really a top 20 language? I don't remember seeing it anywhere close to the top 20. https://www.tiobe.com/tiobe-index/ has them in 31 Top comment is kind of depressing. Tiobe is based on Google searches, so it's not relevant anymore. Since when is Google not relevant? Google modifies search results per person/client and can hide results out right if it chooses to (unconfirmed, but its a good guess). When it comes to analysis it does not qualify as a research source anymore. It is merely a starting point for your research and does not play a major role. It seems you guys are undercutting the results because you don't like them: The index covers searches in Google, Google Blogs, MSN, Yahoo!, Baidu, Wikipedia and YouTube. http://githut.info/ http://pypl.github.io/PYPL.html http://sogrady-media.redmonk.com/sogrady/files/2018/03/lang.rank_.118.png https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages https://insights.stackoverflow.com/survey/2016 Looks consistent with other results.
Re: D on top of Hacker News!
On Monday, 4 June 2018 at 16:05:24 UTC, rikki cattermole wrote: On 05/06/2018 3:56 AM, I love Ice Cream wrote: On Monday, 4 June 2018 at 11:14:42 UTC, bauss wrote: On Sunday, 3 June 2018 at 17:40:46 UTC, I love Ice Cream wrote: Is D really a top 20 language? I don't remember seeing it anywhere close to the top 20. https://www.tiobe.com/tiobe-index/ has them in 31 Top comment is kind of depressing. Tiobe is based on Google searches, so it's not relevant anymore. Since when is Google not relevant? Google modifies search results per person/client and can hide results out right if it chooses to (unconfirmed, but its a good guess). When it comes to analysis it does not qualify as a research source anymore. It is merely a starting point for your research and does not play a major role. It seems you guys are undercutting the results because you don't like them: The index covers searches in Google, Google Blogs, MSN, Yahoo!, Baidu, Wikipedia and YouTube.
Re: D on top of Hacker News!
On Monday, 4 June 2018 at 11:14:42 UTC, bauss wrote: On Sunday, 3 June 2018 at 17:40:46 UTC, I love Ice Cream wrote: Is D really a top 20 language? I don't remember seeing it anywhere close to the top 20. https://www.tiobe.com/tiobe-index/ has them in 31 Top comment is kind of depressing. Tiobe is based on Google searches, so it's not relevant anymore. Since when is Google not relevant?
Re: D on top of Hacker News!
Is D really a top 20 language? I don't remember seeing it anywhere close to the top 20. https://www.tiobe.com/tiobe-index/ has them in 31 Top comment is kind of depressing.
Re: Can D not reduce template error messages?
On Saturday, 2 June 2018 at 09:48:26 UTC, IntegratedDimensions wrote: Getting N messages for N template parameter variations on a template. void foo(A,B)(); A and B are selected from N different values and all are used. If there is an error in the function then I get N^2 error messages, one for each combination. All the error messages say the same thing except A and B are different. If the error message is several lines then that is multiplied by N^2. Why can't D do a bit of error diagnostics. If the errors pertain to the same template and have every character the sample except the template values then just make a generic message: These are the actual error messages, I did not copy and paste!!! o.d(152): Error: function `foo!(float, float).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, float).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(274): Error: template instance `foo!(float, float)` error instantiating o.d(152): Error: function `foo!(float, int).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, int).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(277): Error: template instance `foo!(float, int)` error instantiating o.d(152): Error: function `foo!(float, int24).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, int24).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(280): Error: template instance `foo!(float, int24)` error instantiating o.d(152): Error: function `foo!(float, short).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, short).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(283): Error: template instance `foo!(float, short)` error instantiating o.d(152): Error: function `foo!(float, byte).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, byte).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(286): Error: template instance `foo!(float, byte)` error instantiating o.d(152): Error: function `foo!(float, ubyte).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, ubyte).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(289): Error: template instance `foo!(float, ubyte)` error instantiating o.d(152): Error: function `foo!(float, void).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, void).bar(string)` is not callable using argument types `(int)` and this is when A is constant! When I allow A to vary then it is squared in number!! It is ridiculous! It all could be simplified: .d-mixin-264(274): Error: template instance `foo!(A, B)` error instantiating o.d(152): Error: function `foo!(A, B).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(A, B).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` where A is float, B is ubyte, void, float, etc... Error messages like these are why language designers generally do not go the C++/D style template route, but instead do some limited meta programming, like with generics.
Re: Remember the Vasa! by Bjarne Stroustrup
When Bjarne and the D community is criticizing your complexity, that's saying something...
Re: auto: useful, annoying or bad practice?
On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote: D is very hard to make an IDE for that would actually tell you what type the return value is. This might sound a little hard, but that's probably a fundamental failure of the D language and explains some of the poor tooling around the language.
Re: auto: useful, annoying or bad practice?
On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote: The return type for range-oriented functions in std.algorithm is usually not terribly useful. So the first question that comes to my mind are what are the 'rules' of the output. Which is really what typing is. It's a series of rules. Your object is allowed to call these methods/properties. It is 'this' size. Languages have generic returns. D is not the only language with a concept of returning a 'compiler determined type'. But the rules are always baked into the API. If it's not, it's a design failure and more thought should be put into it. The only place I wouldn't be so strict with auto returns is in private methods. However, I still might tell someone to think about what they are trying to return there. It's not an unimportant piece of the API.
Re: auto: useful, annoying or bad practice?
'auto' in the sense that C# and other languages use 'var' makes perfect sense. There is nothing wrong with it and it takes out redundant 'noise': var i = "This is a string"; // don't need to know two times that this is a string. var j = SomethingThatReturns(); // IDE or function docs will have my back here... FYI, I wouldn't use this for 'time saving'. It's to take out redundant noise, which can clutter code. It also enables easy switching of return types from methods which occasionally means you don't have to change any code. It is frequent the type you change it to might follow the same protocol/interface as the previous type. Or you are just not using anything special with the type (maybe just forwarding a return). I do a ton of C# code and it's common with the .NET framework that this happens (for instance when working with collections). In short 'auto' or 'var' is not for time saving. It's to increase code readability and code refactorability. Those are it's benefits worth a damn. Most people spend more time reading code than writing code so if you are worried about the time it takes to type out 'auto' vs. 'SomeObnoxiouslyLongAndOverlyVerboseTypeName' then I think you are turning an anthill into a mountain. It's one thing when a language feature takes away the need to write hundreds of lines of common boiler plate code, but when it just prevents you from typing out a really long name? Come on...please...that's not why 'auto'/'var' has gained industry recognition. There's just a lot of people that use it because it's an idiom without taking the time to understanding why it _is_ an idiom. So they say things like 'I type less, so I like it'. Which brings me to where it probably is not a good place for it...in the return fadeclaration of a function/method. I'm very close to saying, even after having read some of the comments that try justifying it, that 100% of the time you want to specify the return type. When you create a function that returns something, you are actively deciding 'I need to return this thing, this is useful or the point of this function'. To not have that thing obviously spelled out in the API is a huge design mistake. Not only do you take away a self-documenting part of you function definition, you make someone have to either have a good IDE (which some people are adverse to using) or actually go read the source code. To not put the effort into thinking about the type (or constraints on the type when dealing with generic/templated code) is just lazy. And worse, it will facilitate libraries where people didn't think about their API as much as they should.
