On 08/27/13 13:55, Matthew Flatt wrote:
For what it's worth, I think you're worried about problems that will
have simple solutions in practice. For example, I don't think you
should rely a package whose author isn't invested enough to at least
put it on GitHub or otherwise archive old versions.

If one of your scenarios turns out to be a problem in practice,
however, then you should expect that we will improve the package system
to address the problem. That is, don't expect the package system to be
perfect, but do expect us to respond to concrete problems.

That opinion points to my general answer about relying on Racket for a
commercial enterprise:

  * You *cannot* rely on on Racket version X.Y.Z as the prefect design.

  * You *can* rely on Racket to keep changing and keep improving. It's
    natural and appropriate to worry about change and/or new designs,
    but we are committed to change and improvement, anyway.

  * You *can* rely on Racket to provide backward compatibility and/or a
    migration path so that your programs keep working as Racket
    improves.

As a case in point, this thread is about the new package system. We
have an old package system (PLaneT), and it is still supported. We're
building on the experience of the old system to solve some of its
problems and to create new opportunities. I have various reasons to
believe that the new package system is a step in the right direction
(not the least of which is the fact that DrRacket can now be a
package), but I'm even more sure that's the design is as good as we can
do without further practical experience.

Past performance is no guarantee of future results, as they say --- but
maybe past performance is the best indicator available, anyway. Racket
has been around for a while, so you can see how we work, and that
should help you decide whether Racket is stable enough to build on.

I spent some time looking at the Racket code, tests and mailing lists before choosing it. I don't seek perfection and have been very impressed with how responsive the racket development process has been. I am therefore sure that as problems arise, they will get sorted.

I am not against the new package management system per se, and agree that separating out the parts that make racket into packages is a great idea. It is purely the lack of version control and parallel version handling that I am concerned about. I have seen problems with version control crop up for so long and so often that I can't see why people think Racket and it's third-party packages would be immune to what has happened in every other package eco-system I have used: Ruby, Tcl, Shared C Libraries under Linux, Various Linux Distros, etc. All of these either started without distinct version control, or started with a single version package model and now all support multiple parallel versions of packages to overcome the dependency problems that arose.

Developers make mistakes, we are all human, no one knows what another is going to do and we can't
control it; all we can do is mitigate the risks.

I assume Racket itself is not going to drop distinct release version numbers for some of the same reasons that I am worried about this. In addition if it did then documentation would be a pain, as it will be for packages under this new scheme. Answering questions on this mailing list would be a pain, e.g. What revision of Racket are you experiencing that problem with?....Uh checksum 0xA3B432DE34F45C43...Ok,
I'll look that up and work out what state the API was in then.

For the moment I'm going to leave this and see how things get on and report back if I have any problems.


Lorry

--
vLife Systems Ltd
Registered Office: The Meridian, 4 Copthall House, Station Square, Coventry, 
CV1 2FL
Registered in England and Wales No. 06477649
http://vlifesystems.com

____________________
 Racket Users list:
 http://lists.racket-lang.org/users

Reply via email to