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