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
