tag:blogger.com,1999:blog-5135517.post110452455463874676..comments2023-11-05T03:54:44.710-08:00Comments on Making it stick.: Languages and Data IntegrationPatrick Loganhttp://www.blogger.com/profile/02088461489050417591noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-5135517.post-1104837988377166432005-01-04T03:26:00.000-08:002005-01-04T03:26:00.000-08:00I think that the key point here was in the last pa...I think that the key point here was in the last paragraph of one of PJE's comments - it's about having a notation *in common*. This is a key issue in a number of areas - adaptation, interfaces, introspection, etc. People have created ways of doing all of these, and they work fine. But they aren't interoperable (without substantial effort). If I use Twisted interfaces in my code, I can't just plug it into something that uses Zope interfaces. To my mind, *that's* the reason for language support.<br /><br />Oh, and I'm fairly scared by Guido's latest posting on type algebras, inferencing, etc. If it can be done, great - but that looks like a lot of developer effort on something I don't (yet) see the benefit of - given that I'm another of the people who has no interest in static type checking, but might have an interest in the annotation aspects of type declarations.<br /><br />We'll see - I'm much clearer on what Guido's getting at after his second posting, so maybe it's just a matter of time. I don't see any of this happening soon, though, for better or worse.Paul Moorehttps://www.blogger.com/profile/17557923197983461835noreply@blogger.comtag:blogger.com,1999:blog-5135517.post-1104565459970553352004-12-31T23:44:00.000-08:002004-12-31T23:44:00.000-08:00"""Years of endless debates about static type anno..."""Years of endless debates about static type annotations regurgitating the same information over again have led me to shy awayfrom them in recent years. I've done pretty well, yet here I am in the gravity field of another one."""<br /><br />You may be debating about static typing, but I'm not. :) I agree with you about static typing; I'm only continuing to comment because I'm not yet sure you realize that, and may still be missing the use case I was (and am) trying to explain. Or, if you didn't miss it, and have some really cool way to do what I want without doing it in the way I think it would work best, then I'd still like to find out about it. :)<br /><br /><br />"""The language systems I have used that I can recall have tended to allow me a way to express these in the agile language itself rather than in a comment or<br />doc string, but that's a minor point."""<br /><br />I'm not so sure. It depends on what you mean by "express these in the agile language itself". Do you mean something like:<br /><br />@java_signature(jint, jstr)<br />def javaMethod(self, anInt, aStr):<br /><br /><br />Or do you mean something like:<br /><br />def javaMethod(self, anInt, aStr):<br /> anInt = jint2pyint(anInt)<br /><br />My point here is that something more like the former and less like the latter is more attractive to me, because it allows me to build the system on explicit metadata. For example, it would be easier to build a Python-to-Java translator that used explicit metadata, rather than implicit inference.<br /><br /><br />"""The point is, this is a burden rather than a feature. Why would I *want* to work at this level of detail? """<br /><br />I'm writing a library. The library has certain requirements of items passed to certain methods. These requirements are common across several methods. I would like to have a concise way to refer to them; an interface name is a concise, precise, symbolic way to do that.<br /><br />I've never programmed in Smalltalk, but I've heard that one common approach there is to define a "protocol", usually by adding an 'isFoo' method to the base object type. This is another way of addressing the same issue; you can at least document that such-and-such message requires an object for whom 'isFoo' is true, and then use 'isFoo' itself to hold the documentation explaining the semantics and interface, or at least to be the name you use to look them up by.<br /><br />In Python, a similar approach is to use an interface IFoo, and call 'IFoo(ob)' instead of testing 'ob isFoo', or whatever the correct Smalltalk is for that.<br /><br />My point is, it would be nice to be able to 1) explicitly state in computer readable form, "this method takes an IFoo", 2) be able to introspect that, and 3) automatically adapt to IFoo if a suitable object is passed to the method.<br /><br />This is *not* the same thing as "static typing"; please don't confuse it with that. It is type *annotation*. In fact, if PEP 246 semantics are used, there isn't necessarily any way for a compiler to prove at compile time that a program is incorrect, since an object can *dynamically* decide to support (or not support) an interface, and the interface can *dynamically* decide to put a wrapper around the object or not.<br /><br />I agree that required explicit static typing is a pain, and I am not advocating it. To the extent that Guido's proposal is mere static type enforcement, I'm against it.<br /><br />However, being able to *annotate* methods or classes with type information is useful, as is being able to do automatic adaptation with a compact notation. Having explicit annotation allows you to do things with the data, like generate a database schema or other syntax-driven machinery.<br /><br />For me, the main reason to support a type annotation syntax in Python is to pre-empt the fifty different kinds of decorators people will need to write to do type annotation in order to support these use cases. (E.g. one for ctypes, one for Jython, one for PyObjC, etc.)<br /><br />It would be really nice to be able to have a common syntax and semantics that could be leveraged to implement lots of different metadata-driven use cases. That way, whenever someone reads a Python program, the documentation purpose is served, even if they are reading the code in a plain ol' text editor, rather than a fancy type-inferencing IDE. :)<br /><br />Anyway, it's pretty clear we are talking about different animals; you keep saying "type checking is useless, type checking is bad", and I *agree with you*. I don't want annotation for type checking; I just want to be able to use type annotations to drive other things. (Btw, adaptation is not type checking either.)<br /><br />For example, Zope has this thing where it maps form fields into function arguments on the method of an object; if you POST a form to a URL that represents an object method, Zope introspects the method's argument names to see what form fields it should pass to the method.<br /><br />However, because there's no type information to extract, Zope uses this naming convention for form fields where you tack on things like ':int' or ':list:int' in order to put the type information into the HTML form! This is duplicative, to say the least, and it also causes interesting issues with client-side JavaScript at times. It would be much nicer if you could simply annotate the method with what types it wants, and the framework could then look up converters to map from the posted form data to the type desired by the method being invoked.<br /><br />This is a simple example of a case where the logical place to express needed type information is on the method itself, and it isn't even an inter-language integration issue, unless you consider HTTP form posts to be another language. Even then, it's certainly not a statically typed language being interfaced with; rather, the HTTP post is essentially typeless, and the typefulness is needed by the Python program in order to escape from everything's-a-string land.<br /><br />Notice that the issue here isn't type checking, it's type conversion; an example of one kind of metadata-driven transformation.<br /><br />Here's another one: create a GUI wrapper that uses argument metadata to "intuit" suitable forms to invoke methods, using the types to look up suitable widgets or subforms.<br /><br />Can you meet these use cases other ways? Sure, trivially, just write your own darn function/method decorators, or invent some other specification language outside the code, use code generators, or any of half a dozen other techniques. I just think it'd be nice to have a convenient, easy-to-read/use syntax that everyone would then have in *common*, instead of the decorator-per-use-case scenario.PJEhttps://www.blogger.com/profile/04688223805457202941noreply@blogger.comtag:blogger.com,1999:blog-5135517.post-1104527974898933572004-12-31T13:19:00.000-08:002004-12-31T13:19:00.000-08:00Static typing is only useful if it helps ME. I don...Static typing is only useful if it helps ME. I don't care if it makes the compiler's job easier, and I don't care if it makes someone else's job easier, unless that's someone I care about. The reality is that even Lisp and Smalltalk are perhaps 30 years behind where they should be because we continue to argue about quaint notions. <br /><br />For example, if Python wants to add type "annotation" to help out in the short term while type inferencing develops inside the compiler, then we can have an intellectual discussion. If it's just a fetishistic addition for a check-box, then it's counter-productive.Anonymousnoreply@blogger.com