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 clear water between the use of procedural/functional languages for Maths and the rising trend of using OO languages ( though all too often badly ) for implementing industrial solutions - does this represent a split between computer science and software engineering? > > OO - done right - emphasises relationships and the strengths of type over traditional, potentially clumsier coding. This is obviously not without overhead, and does appear to be a paradigm shift too far for many, but I'm wondering if anyone can explain to me why OO is not the most appropriate solution to the "Commensurable" problem space in perl 6? > > Steve I'm not sure if this is an answer; but: 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 Bear in mind that the above assumes that a common system of measures is in use; things get messier once you start trying to add miles and kilometers together, and messier still if you need to differentiate between (tons of) apples and (tons of) oranges. I'm not saying that there isn't an OO-based solution for this; in fact, I suspect that there probably is. But it's not a trivial one; nor is it clear that Perl wouldn't benefit from a bit more syntactic sugar here. Would it be possible, given an "apple" role, to be able to say something like the following? my $x = 1 apple; $x *= 5; # $x == 5 apples. $x -= 2; # error: can't subtract a unitless number from 5 apples. $x += 2 orange; # error: can't mix apples and oranges. That is, attach a collection of roles to a numeric value in a manner where the roles represent some sort of "units" for that value, instead of being applied directly to the value in question. --- 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.
