One thing to keep in mind is that while adding such things to the Perl 6
core might not be the highest priority at this point something like that
could be implemented as a module (if we have a consistent idea what we
want).
Currently it's possible to change the language to (a subset of) Perl 5 (
https://github.com/rakudo-p5/v5) so it should be possible to at least
prototype the units handling.
2013/8/23 Steve Pitchford steve.pitchf...@gmail.com
I'll start with your last point:
At this point, though, plans to expand on Perl 6's capabilities are taking
a back seat to getting Perl 6's existing capabilities implemented. This
has been true for some time now, in fact — which is all the more reason to
get Perl 6.0 fully implemented as soon as possible.
I've been lurking here for a while, and have learned a great deal whilst
reading. I've had previous plays with perl 6, would love to again, but find
myself limited by freetime. To those ends, I'm just here to chat about
something that seems interesting - not to try to influence the hard work
being done by all of those pushing the perl6 project forwards.
I'm a big fan of Eric Evans Domain Driven design - it's a fantastic book.
He pushes the importance of context and relevance with respect to object
orientated programming.
From that perspective - the answer to the following question is rather
brutal:
How would you implement, in a robust way, the following things:
1 kg + 1 kg = 2 kg
2 m * 3 m = 6 m^2
5 kg * (3 m/s)^2 = 45 J
The answer is that you wouldn't - the problem domain is so vague as to be
meaningless. 1kg or 1m of what?
Going back to apples - The value of 1kg of apples in terms of
representation depends on context.
For example, it would be a chore to try to arrange a group of apples to
make an exact kilogram. On an individual basis you may have 6 apples. In
some cases you may represent that as 6 instances. In another context, you
may represent a collection of apples in their tray form - which may have a
notional weight with a tolerance. Now, if one were writing a checkout
system, it may be sufficient for one to have a fruit class, of which
apples and oranges are instances, and both are charged in weight - and
their may be additional algorithms to predict stocking levels and
re-ordering thresholds, but from personal experience, these algorithms
often require the backup of business process such as stock takes to ensure
that waste, theft, and approximation errors are taken for granted, and we
don't end up with a backlog of rotten apples or empty shelves.
That's where software engineering comes in. Systems are sharded and
Classes are defined containing aggregations of behaviour. In a grocer, you
may never need to add 1kg of apples - you may sell 1.25kg in a single
transaction, you could sell 6 apples, depending on your pricing structure.
You could even sell 2kg of discounted fruit which includes apples and
oranges close to it's use by date.
Because you have moved away from primitive arithmetic and into object
behaviour and relationship, the notion of 1kg + 1kg becomes irrelevant.
Because systems are becoming fragmented, it may make no sense to hook the
checkout up directly to the purchase system. You can happily sell weights
of apples, but have stock control implemented by how many trays of apples
get sent to the shop floor - in this case, you may have an alarm that
indicates another tray is probably needed, but it tackles the inherent
disjoint between purchase and sale quantities without any complex, over
generic modelling of the relationships between trays of apples and weights
or other quantities sold on the shopfloor.
The fragmentation of the system in this way also allows the canny grocer
to flog bags of mixed fruit without worrying that his software developer
will charge him thousands and delay implementation of what seems the
exploitation of a simple opportunity by a few weeks.
-- Forwarded message --
From: Jonathan Lang datawea...@gmail.com
Date: Fri, Aug 23, 2013 at 9:47 AM
Subject: Re: Commensurability as Key
To: Steve Pitchford steve.pitchf...@gmail.com
On Aug 23, 2013, at 1:17 AM, Steve Pitchford steve.pitchf...@gmail.com
wrote:
I think James Bowery's comments are intended to address a real need for
programming languages to work with units of measurement. It might even
prevent aircraft accidents which have really happened because fuel was
delivered in Canadian gallons, or kilograms, when the pilots request was
for American pounds in his owners manual. Commensurable purchase orders
would be nice.
Putting tools like PHP and VB to one side for a second,
Maybe I'm getting the wrong end of the stick, but this just seems like a
case of what is known in object orientated terms as Primitive Obsession -
in this case, the overuse of integer and float arithmetic where objects
make far better use cases.
There does seem to be significant
