Comment by avar | Hacker News Reader

Comment by avar | Hacker News Reader

Parent Full thread

She seems to be advocating that Python do pretty much what Perl has ended up doing, which is "we have some batteries, but we haven't been adding new ones for a decade or more".

The reasons are similar, it's a constant drag on core compiler development to need to support various batteries included that most core contributors aren't going to care about, so it's easier to tell people "use CPAN".

There was even talk of "distros" for the interpreter. Where the core bits would be similar to what Linux is, and all the batteries would be provide as collections of add-on packages.

Strangely enough these efforts seem to stop at OS distributors. They really seem to like to install just the one "compiler", and wouldn't stand for a project like Perl or Python telling them "we mean for you to distribute the core compiler plus these 100 packages, because that's what forms our 'language'". "Strangely" because you'd think they'd be the best positioned to make easy work of packaging up such a thing, and it shouldn't in principle make a difference if you need to install 100 RPMs / APTs by default.

And perl solved that perfectly: just let the OS/distro solve the 100s of packages. And it have been solved, despite you claiming otherwise on your last paragraph.

When did you have to use cpan in a modern system? Compare that to how many times you had to use pip.

Now, if you use a crappy OS or distro (or god forbid, some container built by you have no idea who on top of nobody knows what) then yeah, you are bound to do the leg work yourself, but you will be doing that regardless of the language/subsystem you are trying to use in that case.

Not to mention that it is the only way to do things professionally. For example, if you must have a system that parses XML but for company policy is not allowed to have even the means of performing a network request. With python you either have both xml and an http library and whatever else included and you will either have to do a special package with a striped down python+xml only or get a corporate exception. While on other languages you can install only the xml parser component package and your code will run happily and be compliant with company policy.

> When did you have to use cpan in a modern system? Compare that to how many times you had to use pip.

Well yeah. A sizable amount of new software is still being written in Python. But when I use Perl software (besides my custom scripts), it's always stuff that's old enough that the distribution is carrying packages for it.

If you disagree, please name a significant new software written in Perl that was released in the last, say, 5 years.

name one package you missed in those 5 years.

I see your comment as the goal, not the problem.

> if you must have a system that parses XML but for company policy is not allowed to have even the means of performing a network request. With python you either have both xml and an http library and whatever else included and you will either have to do a special package with a striped down python+xml only or get a corporate exception. While on other languages you can install only the xml parser component package and your code will run happily and be compliant with company policy.

...wouldn't the company policy involve removing the means of performing a network request from the computer, making the notional capabilities of the software irrelevant?

Python will let you drive network requests through the OS. It's just that you wouldn't normally want to.

+1 for this. Trying to ban programming languages that support network connections is both foolish and impossible. Any Turing complete language that allows any sort of OS interaction can be used to communicate over a network. Even if you have to manually do the syscalls yourself.

most companies i've worked for have special packages for perl/python/php/etc that compile the interpreter without support for system calls, for example.

That alone have probably paid of handsomely over the years considering all the XSS we patched, which could very well have been full network compromises.

I don't mean OS distributors can't package up CPAN modules. They can do that, no problem, same for the Python equivalents.

I mean that a significant use people get out of Python and Perl is that they aren't bare-bones like say Scheme or Lua where the standard library is really spartan.

It allows you to write useful code that works on the lowest common denominator of "just OS Perl or Python". Whether that's some random version on whatever Linux distro, or *BSD or Solaris or whatever without needing to write your own getopt library or whatever.

Which is why the "let's ship a bare-bones compiler and have people use CPAN or PyPi" is contentious. In theory it shouldn't matter, and for a lot of shops who install hundreds of packages it doesn't, but it does for people who target stdlib-only, which is a big use-case. Particularly since the people who have that use-case are drawn to these languages.

> Which is why the "let's ship a bare-bones compiler and have people use CPAN or PyPi" is contentious.

But you don't have to ship just a bare-bones interpreter to deal with the problem of stdlib staleness, you just need the stdlib libraries to be updatable via package manager, you don't need to not ship a baseline version of them with the interpreter.

That doesn't deal with the bloat issue raised with relatively unused libraries, but if they are relatively unused because they aren't good rather than because the use case is uncommon, upgradability could solve that.

Of course, you don't solve compatibility for versions before the move to upgradable packages, but at the same time if you solve problems going forward you increase the incentive to upgrade.

Sure, in Perl these are called "dual-life" modules. It makes things easy for users, but makes the life of the compiler-maintainer worse.

Now not only do they need to ship a stable compiler+large-stdlib, but they can't even rely on there being a 1=1 version relationship between the two, instead it'll be many=many as users might use multiple library versions with multiple compiler versions.

> Sure, in Perl these are called "dual-life" modules. It makes things easy for users, but makes the life of the compiler-maintainer worse.

Well, yeah, but you're not going to have much of a language at all if you optimize for quality of life of the language maintainer.

I use cpan constantly, though indirectly via carton. I used to use the OS for Perl libs but this starts to fail hard when you have multiple projects that all demand different versions of stuff.

You use CPAN all the time in perl develpment

The idea of "distros" for python is interesting, and to a certain extent has already happened: just look at Anaconda.

I've been using built-in environment isolation tools such as virtualenv for ages but have recently switched over to using miniconda for all things python. Among other things it has amazing support across all three major OS's, and I happen to be dealing with all three at any given time. Whether one uses miniconda, pipenv, virtualenv, or anything else like it, as far as I am concerned the days of ever using the system python are over. I will always create my own personal "distro" on the fly with full control over the python version and every add-on package.

> the days of ever using the system python are over

You don’t have any Python scripts in your bin folder?

As a non-scientific user of pyenv[0], would I benefit from switching to Anaconda/miniconda?

[0]: https://github.com/pyenv/pyenv

The default "Anaconda" install is like 7Gb after it grabs everything. Turnkey if you're using all that stuff anyway, but otherwise not particularly worth it. Miniconda on the other hand I'm finding meets my needs exactly. The base install is standard.

You don’t have to switch. You can install anaconda using pyenv, to get the best of both worlds.

not likely IMO. i've found conda - which is their environment management tool - to be a hassle unless one needs specific numpy/scipy/GPU libs. i'm using pipsi and pew, although i'll look into pyenv.

Former conda dev lead here. Definitely interested in more details regarding what part of the conda experience you found to be a hassle, if you’re willing to share.

https://wiki.python.org/moin/PythonDistributions

That problem does not seem to happen with the Haskell Platform. Maybe it's because GHC has almost no batteries at all, so nobody thinks it's sufficient, or maybe it's because distros get it in a single package, so it does not feel like installing 100 libraries.

> There was even talk of "distros" for the interpreter. Where the core bits would be similar to what Linux is, and all the batteries would be provide as collections of add-on packages.

Not a million miles from the modularisation that Java has been going through.

Reply on news.ycombinator.com