https://news.ycombinator.com/item?id=19948642

On Sunday, 19 May 2019 at 03:33:15 UTC, Andrei Alexandrescu wrote:
> https://news.ycombinator.com/item?id=19948642

>Brown asserted that there were many such dependencies from the standard library to PyPI: typing works best with mypy, the ssl module requires a monkeypatch to connect to non-ASCII domain names, datetime needs pytz, and six is non-optional for writing code for Python 2 and 3.

Actually I see no problem here. I'm using python as everyday tool, and yes, there is lot of packages in Pypi repo that are more user-friendly or more complete than standard library modules, but not every pypi module works on every platform where python library works and not always compatible with every python version (and this sometimes is real PITA).

Her point is to move some parts of standard library to PyPI, but I'm not sure if this is good.  The real point should be to get better support for modules regardless of their location - std library or PyPI.

On Sat, 2019-05-18 at 23:33 -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> https://news.ycombinator.com/item?id=19948642

I'd say Amber Brown is right, the Python standard library needs stripping back quite a lot and stuff moved to PyPI. Or pip-able using Git,Mercurial, Breezy, etc. directly so as to access packages not in PyPI.

Go and Rust have both gone with the small standard library and strong support for bringing in dependencies. Go only uses DVCS mechanisms, shunning a central repository of packages. For me this is wrong. Rust has gone with support for a central repository and DVCS. I find this the right route.

D has a central library but no support for DVCS for getting dependencies in Dub. This should be fixed.

I failed to do anything about it at the D hack day, but what I think is needed is a library separate from Dub (or perhaps split off from Dub that Dub then uses) for accessing the central D library. This will then allow Meson, SCons, etc. to better support working with the central D repository and used DVCS to access packages. This should then make adding DVCS support relatively straightforward.

With this in place Phobos can then be stripped back to only that that is absolutely needed.

Rust is a really good model here. Python, Go, and D should follow suit.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Sunday, 19 May 2019 at 04:10:22 UTC, ikod wrote:
> Actually I see no problem here. I'm using python as everyday tool, and yes, there is lot of packages in Pypi repo that are more user-friendly or more complete than standard library modules, but not every pypi module works on every platform where python library works and not always compatible with every python version (and this sometimes is real PITA).

Yup, seems like people somehow forgets what a scripting language traditionally has been used for as they now also increasingly are used for applications.

The libs that have been outdated the most is the HTTP/Web ones, and that is absolutely crucial as a builtin for a useful scripting language.

Anyway, with the standard lib I can just install the default Python build and set up a script to set up daily transfer of stuff from some old windows server to the cloud. All I need is MSIE+notepad. Cost saving efficiency, even despite having to do some workarounds. Get it done same day on a an outdated nothing-installed server with no hickups.

Solving boring tasks like these on time is what has made Perl, Python, bash/unix popular.

Actually, I've found it bothersome and time consuming that the std lib lacked key crypto algorithms. I've also had to improvise my own encoding for HTTP POST on site. So, no, the Python 2 library was not too big at all, it was quite deficient in terms of features.

Anyway, Python is a scripting language often used for hashing out solutions on-site at a break-neck pace (near real time). Python should ship configured as a swiss armyknife and then some.

As long as weaknesses are documented in the Python docs, then it is ok that some of it is imperfect. I'd rather have a leaky firehose when the house is burning than none at all!

D and Go are not scripting languages! Scripting languages need builtins that enable fast deployment and quick fixes.

On Sunday, 19 May 2019 at 11:48:44 UTC, Russel Winder wrote:
> Rust is a really good model here. Python, Go, and D should follow suit.

I don't think Python should not follow suit. It is in a different league.

I can trust the standard library to not contain malicious code. Buggy code is far less problematic than the possibility of facing trojans.

If I use code from a third party I will have to read and vet every single line of code to ensure that there is no backdoor.  So that limit me to very short code segments. I've done it for crypto code. I'd rather not do it.

I'd rather use imperfect standard library code. You want code that has had many eyes on it and where the flaws are well documented when you install scripts behind firewalls of commercial entities.

On 5/18/2019 8:33 PM, Andrei Alexandrescu wrote:
> https://news.ycombinator.com/item?id=19948642

Unfortunately, there's no clear answer to this problem.

One issue not mentioned - while it shouldn't be, Phobos is an essential part of the compiler test suite.

1. the compiler test suite is inadequate
2. breaking Phobos is a good predictor of what will break in user code

On Sunday, 19 May 2019 at 13:39:04 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 19 May 2019 at 04:10:22 UTC, ikod wrote:
> D and Go are not scripting languages! Scripting languages need builtins that enable fast deployment and quick fixes.
I don't know about Go, but I use D for "scripting," a lot. (Go rdmd!) Both D and Python can be described as general-purpose languages. (Hell, D's landing page advertises it as such.) And a good general-purpose language, for me, is one that gives a nice, stable stdlib that allows you to build your initial solution without having to worry about dependencies. In fact, I wish D's stdlib was bigger! Ms. Brown has ostensibly lost sight of this.

On 2019-05-19 13:48, Russel Winder wrote:

> I failed to do anything about it at the D hack day, but what I think is needed
> is a library separate from Dub (or perhaps split off from Dub that Dub then
> uses) for accessing the central D library. This will then allow Meson, SCons,
> etc. to better support working with the central D repository and used DVCS to
> access packages. This should then make adding DVCS support relatively
> straightforward.

How about a new command for Dub that allows it to work like a package manager without the building stuff?

-- 
/Jacob Carlborg

On Sunday, 19 May 2019 at 18:54:03 UTC, Francis Locke wrote:
> I don't know about Go, but I use D for "scripting," a lot. (Go rdmd!)

Yes, I remember I was amazed that a compiled language could be used like that the first time it was introduced. :-)

I view D more as a language that originated with aspirations towards systems-programming then ended up with more emphasis towards application programming and bends the limits towards scripting (or prototyping).

Whereas I view Python primarily as a scripting language ("real time" patch-things-together coding) that has bent the limits towards application development.

> And a good general-purpose language, for me, is one that gives a nice, stable stdlib that allows you to build your initial solution without having to worry about dependencies. In fact, I wish D's stdlib was bigger! Ms. Brown has ostensibly lost sight of this.

Got ya. :-) I guess there are three contradicting views:

1. For a low level system programming language then you want a small runtime and small library that is easy to port and that makes it possible to reuse other libraries without too much bloat (so all third party libraries only depend on a limited standard library).

2. For scripting and high level programming you want the exact opposite. You want a large coherent standard library that provides a shared set of concepts and names for constructs that becomes a shared language between programmers (e.g. ranges in D stdlib).

3. For system level application development you want a standard library that complement the native operating system you target in a very clean and coherent fashion. And provides access to the specific features of the OS (like subscribing to file directory changes, GPS location and what not).

On Sunday, 19 May 2019 at 19:08:27 UTC, Jacob Carlborg wrote:
> How about a new command for Dub that allows it to work like a package manager without the building stuff?

In *nix land, there's the foo-config idiom, i.e., a command that gives you the flags needed to compile something with foo.

For example, sdl-config:

$ sdl-config --libs
-lSDL -lpthread
$ sdl-config --cflags
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT

Typical usage:
$ gcc $(sdl-config --cflags) --other --flags -c thing_using_sdl.c

It's useful because it works with any build system.

In the past I've used dummy projects containing nothing but a dub.json, and parsed the output of dub describe.  But I've only made an 80% solution, not something good enough to release as an official tool.