Andrew Ho wrote:

On Tue, 20 Apr 2004, Thomas Beale wrote:
...


Two comments about untyped languages:



Thomas, What is the definition of "untyped" language?



I was being sloppy. To be correct I should have said 'weakly typed'. There are various dimensions of typing in languages actually. "Statically typed" means that the types are known at compile time. Most typed OO languages have static typing with dynamic binding, which means that that all program entities (i.e. references or variable of any kind) are statically typed to the extent that at least an abstract type is known; at runtime, there may be "polymorphic dispatching" meaning that a reference may be attached to one of the subtypes of its declared type. Java, C++, Eiffel, C#, Modula-3 I think, and probably many others all follow this model.

Languages like Smalltalk are essentially weakly typed - types are not a feature of the language syntax or compile-time environment. As a result, the many checks that could have been done at compile time are not possible, and you discover a lot of things at runtime - in fact debugging your code is mostly a runtime testing activity. One of the problems with weak typing is that it makes mathematically provable programs very hard. Not impossible, but much harder than statically typed languages. It's still pretty hard in languages which take liberties with the type system, which is one area where C++, Java and C# are weak.

...


- trying to define a model representing a design without types borders
on the impossible.



A "type" is-a model. What are you trying to say?


A type is a really a mathematical logic construct - a template of one class of instances. When I said "model" above, I meant an entire model, such as a model of the EHR, or the model in PIDS; each class you see in a UML diagram documenting such models is the definition of a "type"; the exception is "generic" or "template" classes, which UML, C++, Eiffel and some other languages have - classes like List<T> are template classes. But List<T> is not a type - you can't have an instance of List<T>; instead it is a "type generator" - the cross product of the type List with the set of types T gives you a set of types generated by List<T>, e.g. List<String>, List<Integer>, List<Entry>, and so on.

So my point is that defining a model of say an EHR, or anything informational concept you like, without using types, is very hard. You can do it - using functions or even just predicates, but it makes for models which are very hard for normal people to apprehend.

I am quite interested to know why so many people use Python



1) It works in both Free and non-Free worlds.
2) Easy to read
3) Easy to learn
4) Easy to extend
5) Works with Zope


ok, apart from the last one (and probably not...), these are all subjective statements, which most people would probably say about their favourite language (ok, C++ loses on "easy to learn";-). What I am interested in is objective qualities which we could all agree are true of a language. Maybe it's an unreasonable question, so don't feel compelled to respond!



- what's its attraction for building large software



6) With Zope, it is easy to find the piece of code associated with any
specific user-accesible function


is that because the IDE has nice browsing capabilities?



I'd be interested in knowing the main reasons why everyone chooses a
certain language in health systems actually.



7) Easier for physicians to learn to program and debug Zope applications (relative to other languages).



Hm. I find this subjective. I don't find Python especially readable - it's better than Perl or C/C++, but a lot of other languages seem more readable to me, but then I'm not a physician. Why do you think physicians especially would find Python readable?

I guess someone will write it one day, and get us all out of the
terrible mire we're in now;-)



What "terrible mire"? :-)


It's recognised by a lot of people in IT that the current situation with languages is pretty bad, considering what is understood theoretically. This is partly to do with corporate influences, partly irrationalities in the IT marketplace, partly...But to give you an idea of why things are bad, consider:

- there is no language which directly implements the UML meta-model (C++ and Eiffel come closest)

- no popular language contains support for contracts and invariants, although they were invented by Dijkstra in the 60s (again Eiffel has them, Z is completely built on them); I find this especially bizarre given that the whole premise of Corba and distributed objects can only possibly work with contracts.

- all mainstream languages today have their syntax tightly bound to their object meta-model, which means that people often choose a language due to whether it is a [EMAIL PROTECTED] style language (C, C++, Java etc), a pascal style language (algol, pascal, simula, eiffel), a verbose language (VB, COBOL), etc, rather than due to the power of its semantics. But what we should have, and what is technically possible is a 2 level programming infrastructure, where the lower level defines a superset OO meta-model (say something like UML/OCL, with the bugs ironed out, and the type system fixed), and the upper level is populated with various language syntaxes, which implement more or less of the meta-model (some might not allow multiple inheritance for example), and provide a certain syntactic style (C-style, pascal-style, etc). The practical result would be being able to have 2 people programming in quite different syntaxes, but whose programs could be converted to the "p-code" (~ bytecode) of the lower level. Now, .Net sort of approaches this idea. The only problem is that the meta-model in the lower level (the .Net object model) is not a superset of all the languages that we might like to map into it, instead it is a rather weak subset.

In summary, today's situation is still one in which, as soon as one makes a choice of language, one is walled into some kind of corral, from which bridges to other corrals are more or less costly. Essentially, we are still stuck in a paradigm of creating islands of intellectual property rather than being free to use preferred syntaxes and programming models, and having near-perfect interoperability, and hence re-usability.

- thomas beale




Reply via email to