My Meeting C++ Keynote video is now available

Steven Schveighoffer schveiguy at gmail.com
Mon Jan 14 14:42:14 UTC 2019


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


More information about the Digitalmars-d-announce mailing list