There Are No Types Discussion

Moved from IsDeclarativeLessExpressive

(I don't believe in the usefulness of "complex" types.)

[what, exactly, do you mean by a "complex type"?]
I assume they wish to extrapolate concepts of simple "types" such as integers and strings into "business objects", such as customers, products, etc.

There we go, the definitive statement I need to see, conversation over, you're nuts. Let's all go back to assembly. Those simple types you do believe in.. were complex types at one time to simpler languages, times move on, and abstractions grow, let's join the modern era won't you. We need not talk further, unless that opinion changes, because we'll never agree.

I don't appreciate being called a nut. There are many fans of dynamic and "loose" typing on this wiki. If you have objective information that strong typing is overall better, I would enjoy inspecting it.

Hey, I'm a fan of dynamic languages, guess what, they still have types and they still use complex types. Do I have to give you a lesson in types now too, you don't even know what you're talking about, quit pretending to be a programmer.

[DynamicTyping is different from Loose or WeakTyping, and often offers more complex types than static types. Don't call on DynamicTyping fans to back you up in this debate if you won't admit the usefulness of "complex" types. Most of us call for strong, dynamic typing, and have the same aversion to weak type systems that static-typing types do. -- JonathanTang]

Perhaps this involves issues in WhatAreTypes, such as are classes and types the same thing. If classes and types are judged to be the same thing, then we are perhaps right back to OO versus non-OO debates.

If it makes things clearer for you... forget types... think objects instead.

 var aNum = 1 <- that is an instance of an object called int
 var aNum = int.Parse("1") <- so is this
 var aString = "hi" <- that is an instance of an object called string

It really doesn't matter if you want to call int and string a type or not, what matters is that they are objects, they have methods, and this enables them to have behavior. I guarantee that if you write code, you use these two objects all the time. But they are only sufficient to solve simple problems, to do anything complex, you need more complex objects to play with, thus...

 var aNum = 1 <- that is an instance of an object called int
 var aNum = int.Parse("1") <- so is this
 var aString = "hi" <- that is an instance of an object called string
 var aCustomer = new Customer() <- that is an instance of an object called Customer
 var anOrder = new Order() <- that is an instance of an object called Order

To create new more complex objects to allow us to solve more complex problems, we need either classes or prototypes. If you never create new more complex data types than the ones built into the language, you aren't much of a programmer, and you're making things much harder on yourself than you have too. It doesn't matter if you work in dynamic or static languages, they both support the ability to create more complex types/objects/whatever you want to call it.

If you're writing a program that involves taxes for example, and your program needs to keep track of social security numbers for some reason, the smartest thing to do is to create an object for that.

 var anSSN = SocialSecurityNumber.Parse("555-555-5555")

Now you pass that object around rather than passing around the string "555-555-5555", for as long as you pass around the string, you'll never know if it's a proper ssn, is in a valid format etc... but putting it in an object specifically built for it prevents having any problems. Every fundamental piece of data in your problem domain, should have an object to represent it, you should express your program solutions with these objects. You can't write complex software easily if you only rely on the built in types, you must extend the type system to match the problem domain or you are shooting yourself in the foot.

I find that treating such things as strings is not the huge problem that some of you make it out to be. For one, one is often passing it around to different languages and tools in practice. Having to keep packing and unpacking them into and out of formal objects/types is a pain and code bloater. Validate them when they are saved in the database via triggers, etc.; that way nothing is saved that is a bad SSN. OO'ers seem to want everything to be born and die and the same language such that back and forth conversions are not needed. That is the Soviet view of programming. Unix proponents also tend to use multiple languages and tools to process stuff, and thus language-specific "types" like this can get in the way. -- top

Your users will hate you less if you validate them in the browser, or at least before your code mangles it. That way you don't waste their time reinputting data. -- JonathanTang

I never suggested that validation be skipped. (Ideally, language and database validation would be integrated to have OnceAndOnlyOnce validation spots, but the standards are not there yet.) -- top

I never suggested that you suggested that validation be skipped. I suggested that it be done before the database step, because errors caught earlier are much less aggravating.

Oh, you mean to validate them twice. You don't have a database on the web browser. How are you proposing to validate them?

(And I actually think that a SSN is a horrible example, because I'm perfectly fine with using strings for them too, for most uses. Most CRUDscreen data is similarly horrible, because you never do anything with it but shove it in the database. Try validating a network connection with a database though. For that matter, try shoving a network connection into a database.) -- jt

It doesn't matter if you like objects or not, they are a fundamental fact of programming, in just about every language, static or dynamic. Some functional languages jump through hoops to avoid assignment with patterns like the monad, so you certainly can program without objects, but it's a lot simpler to just accept that state exists, objects exist, and learn to use them when they are appropriate. Every good language provides functions as first class objects, for there are times when you need nothing more than a couple functions, a closure or two and shazzam, you're done. But there are also times when you really need those objects, the best languages provide them all... first class functions, objects, and dynamic typing, with optional static typing. But if you use strings and int's, you're already using objects, so get off the anti-OO soapbox and quit being a hypocrite.

Using your wide definition, "everything is an object" (DefinitionsForOo). Besides, what works for simple things like integers and SSN may not extrapolate to more complex, interlinked things, as already discussed in ThereAreNoTypes. I remember one of you started out trying to define a "color" object, and ended up with a big dripping mess. How colors were represented varied per tool, and something that tries to be a one-size-fits-all class will be nothing but a dumping ground for specilized methods. Sure, you could sub-type, but then something that used to be simple is now a sprawling red-tape tree. GenericBusinessFrameworkUnobtainable. -- top

What wrong with:

  struct Color { unsigned char red, green, blue; }; -- jt

There are other color models, such as YMK (?), the HTML format, etc. -- top

Which don't matter, as long as RGB does what your app needs done. -- jt

If that was the case, then a simple associative array would be sufficient to store 3 values. However, if we are dealing with mostly HTML, for example, then an HTML color string ("#rrggbb") would be more logical in a YagNi sense. That is my point: EverythingIsRelative. "Types" lean toward a Single Proper Interface or Single Proper Viewpoint. I have learned that the hard way when trying to make yet another Ultimate Generic Thing in the past. I used to strive for such a lot, but eventually realized it was futile due to the "Einstein thing". OO is not the answer. There is no existing answer. OO fanaticism has shot science in the head.

Types don't "lean toward a Single Proper Interface or Single Proper Viewpoint". Types don't lean any direction at all. A programmer can try to create one type to serve all uses or he can create just the types he needs for the problem at hand. This problem has nothing to do with types or OO, but with risk/reward calculations. -- EricHodges

If it is only local, then why bother with all the formality? Why make a color "type" that will only be used in one smallish module? And if it is shared, we can make a Color table. Referential integrity and/or triggers can ensure that valid values are put into it.

[Because small local objects make programming far far easier.]

Usually you guys suggest that you cannot demonstrate the power of OO with small local stuff. Yet here you are. So, I wish to see a small, local example of OO "types" making programming easier.

We bother with the formality because it makes our lives easier. It simplifies the code and makes it easier to maintain over long periods of time with a changing developer base. The color type we make today may end up being used in 20 modules. If we can re-use an existing type, we do. If we can't, we write a new one. If we need a table of colors, we make one of those (although that seems about as useful as a table of positive integers).

If formality is so wonderful, then how come you guys reject relational formality for attribute and link management discipline? In other words, why is the formality good for types, but not for attribute and link management? If one uses an map array for 3 colors, one gets almost the same thing as a "type". Any enforcement only works in strong-typed languages. SmallTalk or Python won't have that and relying on good graces and convention, and we are back to weak versus strong typing debates again.

We don't reject relational formality for attribute and link management, if I understand your usage of those terms.

Even if it conflicts with OO such that you either pick one or the other or have duplication?

[Deleted troll - even if top is a troll, the lucid explanations which result are quite worth the effort]

What['s] wrong with:

  struct Color { unsigned char red, green, blue; }; -- jt

There are other color models, such as YMK (?), the HTML format, etc. -- top

So first you define a type with a PossRep? (in TheThirdManifesto terminology) of whatever is most convenient for the application at hand (e.g. the HTML format). Then you add an R/G/B possrep (to the same Colo[u]r type). And then when you need to do manipulations in YUV space you add that possrep too.

In some cases ThereAreNoTypes does seem to apply -- and certainly ThereIsNoOneHierarchyOfTypes? e.g. those cases where whenever we use an object, we seem to need a different interface, and it is certainly debateable whether the clutter of making all those interfaces explicit is worth the benefit versus using, say, slot-based approaches.

But Colo[u]r is surely not one of those cases -- its almost the archetypal AbstractDataType candidate...