> ... to prevent silly mistakes like multiplying $100 with £20 Honest question, what should multiplying $100 with $20 give?
The type system is a programmer's best friend
41–50 of 467 posts
Re: The type system is a programmer's best friend
#42I can see a type system designed from the ground up to do something like this. But as a bolt on to existing languages it's pretty clunky.
Re: The type system is a programmer's best friend
#43>A string value is not a great type to convey a user's email address or their country of origin. These values deserve much richer and dedicated types this is a classic case of not needing more types but needing proper names . Types as concretions, i.e. simply collections of data or functions are a terrible idea because they're static and don't accrete. Data in the real world always does. This becomes very obvious whe…
Does having an EmailAddress type guarantee you won't accidentally accept crap? No, but when you get it wrong, you edit the validation in one place in the system.
Re: The type system is a programmer's best friend
#44There is an important difference between types and objects: types are basic building blocks. An email is not a basic building block nor is money. In the mature ecosystem of Java there are libs and standard libraries that handles these problems some are even in the standard library (timestamp with timezone, url...) It would be nice to have stuff for these in the standard libraries but currencies are a moving target an…
IMO the difference between types and objects is that objects have state and behaviour, whereas types only have state.
A type (of a term) represents the set of all possible values for a particular term. An "object" in OOP, does not have any formal definition, but is typically a first-class module with mutable state. As such, they can be represented by a term and therefore can have a type.
Re: The type system is a programmer's best friend
#45I once attended a meeting where a Professor from a University somewhere in Chicago gave a brilliant demonstration of using a similar type system for dealing with values in Electrical Engineering. It made quite sure you couldn't do things like add volts and amps. [Edit] it also handled things like parallel resistances, etc. It was in C++ if I recall correctly. This is a great idea, that I've haven't had cause to use y…
> "A NASA review board found that the problem was in the software controlling the orbiter's thrusters. The software calculated the force the thrusters needed to exert in pounds of force. A separate piece of software took in the data assuming it was in the metric unit: newtons.... Propulsion engineers, like those at Lockheed Martin who built the craft, typically express force in pounds, but it was standard practice to convert to newtons for space missions. One pound of force is about 4.45 newtons. Engineers at NASA's Jet Propulsion Lab assumed the conversion had been made, and didn't check."
https://www.wired.com/2010/11/1110mars-climate-observer-repo...
There could be issues with memory use, but it could also be implemented as an API, i.e. ensuring values exported from one software package to another were of the correct type, but then store them internally as simple types... Switching everything to a unified metric system would make more sense in the long run, however.
Re: The type system is a programmer's best friend
#46Question: isn’t a rich type system as described here similar to OOP?
Re: The type system is a programmer's best friend
#47> danger abstraction too high, big brain type system code become astral projection of platonic generic turing model of computation into code base. grug confused and agree some level very elegant but also very hard do anything like record number of club inventory for Grug Inc. task at hand
Re: The type system is a programmer's best friend
#48Earlier quoted context omitted.
I wish static typing were as uncontentious as units of measure.
I wouldn't say that UOM are uncontentious, things can get dicey around reference units and precision for instance, or the combinatorial explosion of composite units.
You could even double-down on it: "Have there been any studies that prove that using units of measure helps you get the right answer?"
Re: The type system is a programmer's best friend
#49I once attended a meeting where a Professor from a University somewhere in Chicago gave a brilliant demonstration of using a similar type system for dealing with values in Electrical Engineering. It made quite sure you couldn't do things like add volts and amps. [Edit] it also handled things like parallel resistances, etc. It was in C++ if I recall correctly. This is a great idea, that I've haven't had cause to use y…
This approach to typing could have saved the Mars Climate Orbiter, i.e a pounds of force type vs. a newtons type. > "A NASA review board found that the problem was in the software controlling the orbiter's thrusters. The software calculated the force the thrusters needed to exert in pounds of force. A separate piece of software took in the data assuming it was in the metric unit: newtons.... Propulsion engineers, lik…
Re: The type system is a programmer's best friend
#50> ... to prevent silly mistakes like multiplying $100 with £20 Honest question, what should multiplying $100 with $20 give?
2000 square dollars? If I'm choosing between ways to spend capital so as to improve the efficiency of a process, and that process currently produces five widgets per dollar, then the quantity I'm comparing to choose between my courses of action can be measured in widgets per square dollar. Hiring a better engineer for more money may create an efficiency improvement of 1 widget per dollar, with an outlay of $1k extra…
You have provided a real example, which I was looking for, of why one might need to express a square dollar; thanks.
I wonder if the people who want to argue "types save you from bugs" see your example as very unwelcome, since they'd want to use "squared dollars" as an example of something nonsensical that should be flagged as a type error. I hope those people can reflect rationally on the limits of type systems in the real world.