What Makes A Programming Language Good

[Jesse Phillips]

Adam D. Ruppe Wrote:

> Jesse Phillips wrote:
> > You can have the author release packaged libraries for developers
> > to use and the author should do this. So this begs the question of
> > what is the repository for?
> 
> It's so you have a variety of libraries available at once with
> minimal hassle when you are originally writing something.
> 
> I really don't care about those libraries' implementation details.
> I just want it so when I type "import something.lib;" in my
> program it actually works. If something.lib's author wants to
> use other.thing, great, I just don't want to think about it
> anymore than I think about his private classes or functions.

Perfect, so what you want is a is a repository of pre-built packages which have all the bells and whistles you need.

> > Why is the tool going out to different URLs and downloading files
> > when you are supposed to use the pre-built lib?
> 
> The second level of downloads is an implementation detail,
> aiming to provide the illusion of a pre-built lib when the
> author didn't actually provide one.

And this is where things stop "just working." You are providing an illusion that isn't their. And it is one that is very fragile. You can of course ignore the issues and say the software must be maintained to support newer versions of the libraries if the feature is to work.

I don't have an answer as to whether this is acceptable. The only way to find out is if a successful build tool takes this approach.

> The first level of downloads (the things you actually import in
> your own program) are there for your own convenience. It's
> supposed to make this huge ecosystem of third party libraries
> available with the same kind of ease you get with Phobos. You
> just write "import std.coolness;" and it works. No downloading
> anything, no adding things to the command line.

Right, and since the files are going to be downloaded you have to decide what you want to do with them. Pollute the programmers project with all the third-party libraries he imported? Save them to a location on the import path?

Both of these are reasonable, but both have drawbacks. It is more common to place third-party libraries into a reusable location.
 
> I want third party modules to be equally available. But, just
> like you don't care if Phobos uses zlib 1.3.x internally or
> whatever, you shouldn't care if third party modules do either.
> Phobos comes with "batteries included"; so should everything else.

Yes this is generally how Windows software is developed. Linux on the other hand has had a long history of making libraries available to all those who want it. Of course it is usually only something to worry about for much larger libraries, at which point we have package managers from our OS (well some of us do).

> > Having a standard way for which things are built, having easy
> > access to all relevant libraries, and knowing you can find most
> > of what you need in one place. Those are the reasons.
> 
> We agree here. The difference is I'm only interested in the top
> most layer - the modules I import myself. I couldn't care less
> about what those other modules import. In my mind, they are
> just like private functions - not my problem.

Right, unless you are making the software that is trying to hide those details from you.

I think there is a fine line between the person using the libraries and the person that is adding libraries for other people. We want the barrier to entry of both to be as minimal as possible. So the question I want to put forth is what is required to be done for that library writer to commit his work for use by this magical tool?

Should it be compilable without any command line flags? Should it contain all relevant code so their aren't external dependencies? Does it need to be packaged in a tar ball? Can it reside in a source repository? Does it need to be specified as an application or library?

Creating such a system around your simple needs just means it won't be used when things become less simple. Creating a complex system means it won't be used if it is too hard to use or it doesn't work.

DSSS seemed to provide a great amount of simplicity and power... the problem is that it didn't always work.