I have to admit to currently being of the opinion that Commensurability appears to be a feature for program code to perform rather than a programming language to perform, but openly admit to the possibility that I do not understand the concept fully enough for my opinion to be valid.
Your point is obviously valid, but regrettably I'm not looking to volunteer. On Fri, Aug 23, 2013 at 12:30 PM, Paweł Murias <pawelmur...@gmail.com>wrote: > 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 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. >> >> >
