www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: What Makes A Programming Language Good

reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Adam Ruppe Wrote:

 Vladimir Panteleev wrote:
 Your tool will just download the latest version of Y and the
 whole thing crashes and burns.

My problem is I don't see how that'd happen in the first place. Who would distribute something they've never compiled? If they compiled it, it would have downloaded the other libs already, so any sane distribution *already* has the dependent libraries, making this whole thing moot.

But if they haven't done any development on it for the last year, but the library it depends on has...
 The build tool is meant to help the developer, not the user. If
 the user needs help, it means the developer didn't do his job
 properly.

Isn't the developer the user?
 That said, the configuration file, as described in my last post,
 seems like it can solve this easily enough.

Jan 19 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
Jesse Phillips wrote:
 But if they haven't done any development on it for the last year, but
 the library it depends on has...

Unless you give library authors write access to your hard drive, it doesn't matter. They can't make your old, saved version magically disappear. If you then distribute that saved version with the rest of your app or library, it Just Works for the customer. I think I'm now at the point where I've spent more time posting to this thread than I've ever spent maintaining makefiles! If I have a different perspective on this from everyone else, there's really no point talking about it further. We might as well just go our separate ways.
Jan 19 2011
next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Adam Ruppe Wrote:

 Jesse Phillips wrote:
 But if they haven't done any development on it for the last year, but
 the library it depends on has...

Unless you give library authors write access to your hard drive, it doesn't matter. They can't make your old, saved version magically disappear. If you then distribute that saved version with the rest of your app or library, it Just Works for the customer.

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? Why is the tool going out to different URLs and downloading files when you are supposed to use the pre-built lib? I believe the reason for pushing a system like rubygems is not so that the original author can compile their program, it is already setup for them. The purpose is to make it easier on those that want to start contributing to the project, those that are using the library and need to fix a bug, and those that want to take over the project long after it has died. 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.
 I think I'm now at the point where I've spent more time
 posting to this thread than I've ever spent maintaining makefiles!
 
 If I have a different perspective on this from everyone else, there's
 really no point talking about it further. We might as well just
 go our separate ways.

Jan 19 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
 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. 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. 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.
 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.
Jan 19 2011
next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
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.
Jan 19 2011
parent reply Gary Whatmore <no spam.sp> writes:
Jesse Phillips Wrote:

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

I always wondered what happened to that boy. He had impressive coding skills and lots of pragmatic common sense. There was at least one weakness in his persona if he left D, he was dumb enough to not realize the capability our language has now. That's just plainly stupidest thing to do wrt programming languages.
Jan 19 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/11 9:04 PM, Gary Whatmore wrote:
 Jesse Phillips Wrote:

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

I always wondered what happened to that boy. He had impressive coding skills and lots of pragmatic common sense. There was at least one weakness in his persona if he left D, he was dumb enough to not realize the capability our language has now. That's just plainly stupidest thing to do wrt programming languages.

Gregor left when he started grad school, and grad school asks for all your time and then some more. http://www.cs.purdue.edu/homes/gkrichar/ Andrei
Jan 19 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 20.01.2011 00:54, schrieb Adam D. Ruppe:
 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.
 Why is the tool going out to different URLs and downloading files
 when you are supposed to use the pre-built lib?


Pre-built libs aren't all that useful anyway, for several reasons: 1. Templates 2. different operating systems: there would have to be pre-built libs for Windows, OSX, Linux and FreeBSD (if not even more) 3. different architectures: there would have to be pre-built libs for x86, AMD64 and, thanks to GDC and LDC, for about any platform supported by Linux.. Just provide source, so people can build their own libs from it or just compile the sources like their own source files. This can still be done automagically by the build-tool/package management. Cheers, - Daniel
Jan 20 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
 Pre-built libs aren't all that useful anyway, for several reasons:

By "pre-built" I mean all the source is in one place, so the compile Just Works, not necessarily being pre-compiled. So if you downloaded mylib.zip, every file it needs is in there. No need to separately hunt down random.garbage.0.5.3.2.tar.xz as well. Bascially, the developer can compile it on his machine. He sends me the files he used to build it all in one place. That way, it is guaranteed to work - everything needed is right there.
Jan 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 20.01.2011 14:48, schrieb Adam Ruppe:
 Pre-built libs aren't all that useful anyway, for several reasons:

By "pre-built" I mean all the source is in one place, so the compile Just Works, not necessarily being pre-compiled. So if you downloaded mylib.zip, every file it needs is in there. No need to separately hunt down random.garbage.0.5.3.2.tar.xz as well. Bascially, the developer can compile it on his machine. He sends me the files he used to build it all in one place. That way, it is guaranteed to work - everything needed is right there.

Ah, ok. I'd prefer a dependency-system though, so if mylib needs random.garbage.0.5.etc it should fetch it from the repository as well. So when there's a non-breaking security update to random.garbage, mylib automatically gets it upon rebuild. However, when there are breaking changes, random.garbage needs a new version (e.g. 0.6.etc instead of 0.5.etc).
Jan 20 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
 However, when there are breaking changes, random.garbage needs a new

IMO the best way to do that would be to get everyone in the habit of including the version in their modules. module random.garbage.0.6; import random.garbage.0.6; That way, it is explicit, in the code itself, what you need and what the library provides. This also lets the two versions reside next to each other. Say I import cool.stuff.1.0. cool.stuff imports useless.crap.0.4. But I want useless.crap.1.0 in my main app. If they were both called just plain old "useless.crap", the two imports will probably break something when we build the whole application. But if the version is part of the module name, we can both import what we need and use it at the same time. There would be no "import useless.crap" module provided that actually does work. At best, it'd say pragma(msg, "useless.crap.1.0 is the most recent, please use it"); If the thing without version annotation actually compiles, it'll break eventually anyway, so forcing something there ensures long term usefulness. The bug fix version wouldn't need to be in the module name, since they are (ideally) forward and backward compatible. Unit tests could probably confirm that automatically.
Jan 20 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
 When you compile, you have to provide a path anyhow, less hostile to
 user and you don't have to change the code.

One of the things implicit in the thread now is removing the need to provide a path - the compiler can (usually) figure it out on its own. Try dmd -v and search for import lines. But requiring it on the user side just makes sense if versioning is important. Your program won't compile with a different version - you aren't importing a generic thing, you're depending on something specific. It should be explicit. (Btw, this is the big failure of Linux dynamic libraries. They started with a decent idea of having version numbers in the filename. But then they ruined it by having generic symlinks that people can use. They start using libwhatever.so when they really wanted libwhatever.so.4.2. It's a symlink on their system, so Works for Me, but if they give that binary to someone with a different symlink, it won't work. Gah.)
Jan 20 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-01-20 15:58, Adam Ruppe wrote:
 When you compile, you have to provide a path anyhow, less hostile to
 user and you don't have to change the code.

One of the things implicit in the thread now is removing the need to provide a path - the compiler can (usually) figure it out on its own. Try dmd -v and search for import lines. But requiring it on the user side just makes sense if versioning is important. Your program won't compile with a different version - you aren't importing a generic thing, you're depending on something specific. It should be explicit. (Btw, this is the big failure of Linux dynamic libraries. They started with a decent idea of having version numbers in the filename. But then they ruined it by having generic symlinks that people can use. They start using libwhatever.so when they really wanted libwhatever.so.4.2. It's a symlink on their system, so Works for Me, but if they give that binary to someone with a different symlink, it won't work. Gah.)

This is where the "bundle" tool (often used together with rails) shines. It's basically a dependency tool on top of rubygems which creates like a bubble for your application. * You specify, in a in a gemfile, all the package/libraries your application depends on, if you want to can also specify a specific version of a package. * Then when you want to deploy your application (deploy your rails site to the server) you lock the gemfile and it will create a new locked gemfile. The locked gemfile specifies the exact version of all the packages (even those you never specified a version for). * Later on the server you run "bundle install" and it will use the locked gemfile and it will install the exact same versions of the packages you had on your developer machine. -- /Jacob Carlborg
Jan 20 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-20 13:12, Daniel Gibson wrote:
 Am 20.01.2011 00:54, schrieb Adam D. Ruppe:
 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.
 Why is the tool going out to different URLs and downloading files
 when you are supposed to use the pre-built lib?


Pre-built libs aren't all that useful anyway, for several reasons: 1. Templates 2. different operating systems: there would have to be pre-built libs for Windows, OSX, Linux and FreeBSD (if not even more) 3. different architectures: there would have to be pre-built libs for x86, AMD64 and, thanks to GDC and LDC, for about any platform supported by Linux..

And then one library for each of the compilers (ldc, gdc and dmd), do the math and one will soon realize that this won't work. Although pre-built libraries that only work for a given platform might work.
 Just provide source, so people can build their own libs from it or just
 compile the sources like their own source files. This can still be done
 automagically by the build-tool/package management.

 Cheers,
 - Daniel

-- /Jacob Carlborg
Jan 20 2011
prev sibling next sibling parent so <so so.do> writes:
On Thu, 20 Jan 2011 16:30:40 +0200, Adam Ruppe <destructionator gmail.com>  
wrote:

 IMO the best way to do that would be to get everyone in the habit
 of including the version in their modules.

 module random.garbage.0.6;

 import random.garbage.0.6;

Even better, we could enforce this to only module writers. module random.garbage.0.6; import random.garbage; When you compile, you have to provide a path anyhow, less hostile to user and you don't have to change the code.
Jan 20 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 20 Jan 2011 09:58:17 -0500, Adam Ruppe <destructionator gmail.com>  
wrote:

 When you compile, you have to provide a path anyhow, less hostile to
 user and you don't have to change the code.

One of the things implicit in the thread now is removing the need to provide a path - the compiler can (usually) figure it out on its own. Try dmd -v and search for import lines. But requiring it on the user side just makes sense if versioning is important. Your program won't compile with a different version - you aren't importing a generic thing, you're depending on something specific. It should be explicit. (Btw, this is the big failure of Linux dynamic libraries. They started with a decent idea of having version numbers in the filename. But then they ruined it by having generic symlinks that people can use. They start using libwhatever.so when they really wanted libwhatever.so.4.2. It's a symlink on their system, so Works for Me, but if they give that binary to someone with a different symlink, it won't work. Gah.)

Hm... I thought the symlink was meant to point to binary-compatible bug-fix releases. So for example, if you need libwhatever.so.4.2, you have a symlink called libwhatever.so.4 which points to the latest point revision that is binary compatible with all 4.x versions. I think you still simply link with -lwhatever, but the binary requires the .so.4 version. I have seen a lot of libs where the symlink version seems to have nothing to do with the linked-to version (e.g. /lib/libc.so.6 -> libc-2.12.1.so), that doesn't really help matters. Given that almost all Linux releases are compiled from source, it's quite possible that one OS' libwhatever.so.4 is not compiled exactly the same as your libwhatever.so.4 (and might be binary incompatible). This is definitely an issue among linuxen. -Steve
Jan 20 2011