On Monday, 12 February 2024 at 17:30:23 UTC, H. S. Teoh wrote:
> On Mon, Feb 12, 2024 at 03:55:50PM +0000, Paolo Invernizzi via Digitalmars-d wrote:
>> On Monday, 12 February 2024 at 15:03:01 UTC, tim wrote:
>> > On Monday, 12 February 2024 at 14:49:02 UTC, tim wrote:
>> > > I thought I would get a discussion started on software bloat.
>> > > 
>> > > Maybe D can be part of the solution to this problem?
>
> No amount of D innovation is going to stop programmers infected with the madness of dynamic remote dependencies that pull in an arbitrary number of external modules. Potentially a different set of them every time you build.  Tools like cargo or dub actively encourage this model of software development.

Nothing can stop irresponsibility completely, but you can go a long way to simplify and encourage responsibility and sanity. A c program will have less dependencies then a js one.

> Reducing code size is, to paraphrase Walter, to plug one hole in a cheese grater. There are so other many things wrong with the present state of software that code size doesn't even begin to address.

I dont get this medafore, surely less grates makes clogging easier

On 13/02/2024 6:30 AM, H. S. Teoh wrote:
> No amount of D innovation is going to stop programmers infected with the madness of dynamic remote dependencies that pull in an arbitrary number of external modules. Potentially a different set of them every time you build. Tools like cargo or dub actively encourage this model of software development.
> 
> 
> Which is utterly crazy, if you think about it. Unless you pin every dependency to exact versions (who even does that?!), every time you build your code you're potentially getting a (subtly) different set of dependencies. That means the program you've been trying to debug 5 mins ago may not even be the same program you're debugging now. Now of course it's possible to turn off this behaviour while debugging, but still, the fact that that's the default behaviour is just nuts.

What? Dub doesn't upgrade dependencies for you without you asking for it.

It either has to be missing, or you ran ``dub upgrade``.

To prevent that being an issue long term, you can vendor your cache into your repository. ``dub build --cache=local``. Unfortunately you have to provide that on cli every time.

There are solutions here for those who care about it. If you don't care about it, of course it isn't a solved problem.

On Mon, Feb 12, 2024 at 11:49:31PM +0000, deadalnix via Digitalmars-d wrote:
> On Monday, 12 February 2024 at 17:30:23 UTC, H. S. Teoh wrote:
> > All this not even to mention the insanity that sometimes specifying just *one* dependency will pull in tens or even hundreds of recursive dependencies. A hello world program depends on a standard I/O package, which in turn depends on a date-formatting package, which in turn depends on the locales package, which in turn depends on the internet timeserver client package, which depends on the crytography package, ad nauseaum.  And so it takes a totally insane amount of packages just to print Hello World on the screen.
> > 
> 
> "Funny" example of that.
> 
> I wanted to learn of to do a react project from scratch. Not using a framework or anything, just pieces the stuff together to make it work myself.
> 
> So babel, webpack, react, jest for testing and stylex for CSS. That's it.  Arguably a lot by some standard, but by no means something wild, the JS equivalent of a build system and a test framework.
> 
> The project currently has 1103 dependencies. Voila. Pure madness.

Recently while working on my minimal druntime for wasm (one primary motivation for which is to let me write D code when I absolutely can't escape the tyranny of the browser instead of having to deal with the madness that is the JS ecosystem), I noticed a lot of cruft in druntime and Phobos, stuff that got piled on because we added this or that new feature / type modifier / etc..  Code that used to be straightforward acquired layers of complexity because now we have to deal with this or that case that we didn't need to worry about before.  Also, past mistakes that we're still paying for, like the ubiquity of TypeInfos in internal APIs dating from when D didn't have templates.

The recent push to templatize druntime has actually been a great saver, though: I got things like array operations working without incurring the bloat of TypeInfo's thanks to the current compiler emitting template calls instead of TypeInfo-dependent static calls for said operations. I think this is a very important step to move Phobos/druntime toward a pay-as-you-use model instead of the upfront cost of TypeInfo's.

If only more projects are built with the pay-as-you-use model instead of the blanket "I need this dependency, let's pull in the whole hairball of recursive dependencies too".  In an ideal world, things like std.stdio would only import things like floating-point formatting code only if you actually use %f and pass a float/double to format(). Otherwise it won't even import the module and you won't pull in anything that you don't actually need.  (I actually have an incomplete replica of std.format written according to this philosophy -- it doesn't even instantiate floating-point formatting code unless you actually passed a float to format() at some point. In an ideal world the whole of druntime / phobos would be built this way, tiny standalone pieces that only get pulled in with actual use.  Not like the last time I checked, where a Hello World program for some inscrutable reason pulled in BigInt code into the executable.)


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond

On Tue, Feb 13, 2024 at 01:56:08PM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> On 13/02/2024 6:30 AM, H. S. Teoh wrote:
[...]
> > Which is utterly crazy, if you think about it. Unless you pin every dependency to exact versions (who even does that?!), every time you build your code you're potentially getting a (subtly) different set of dependencies. That means the program you've been trying to debug 5 mins ago may not even be the same program you're debugging now. Now of course it's possible to turn off this behaviour while debugging, but still, the fact that that's the default behaviour is just nuts.
> 
> What? Dub doesn't upgrade dependencies for you without you asking for it.
> 
> It either has to be missing, or you ran ``dub upgrade``.
> 
> To prevent that being an issue long term, you can vendor your cache into your repository. ``dub build --cache=local``. Unfortunately you have to provide that on cli every time.
> 
> There are solutions here for those who care about it. If you don't care about it, of course it isn't a solved problem.

And that's the point, *by default* you get the bad behaviour, you have to work to make it do the right thing. You have the put in the effort to learn to use `--cache=local` (and you have to know enough to even be aware that you might need to use it in the first place -- most people wouldn't even care 'cos they don't even know this is an issue).  I'm not singling out dub here, I'm talking about the entire philosophy behind dub and similar tools. The defaults are very much designed such that you would just pull in hairball dependencies automatically without needing to give it so much as a thought.  There is little, if any at all, incentive to make do with as little as possible to get your job done. On the contrary, the whole idea is very much to "buy the package deal", so to speak, download (and build and link) the entire bundle of stuff which gives you everything, bells and whistles and all, even if you actually only need to use less than 10% of it.

A million LoC OS just to open the garage door, as the linked article puts it.


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the "window".