Static Typing And Insularity

DeleteMe - I agree that the premise of this topic may not be well-formed enough yet to justify a dedicated topic. It is not that I don't think it is an important issue, but there is enough ill-will against me that I will focus on bigger fish in the pond of contention instead. I don't want to waste big bullets on small targets. Or, perhaps rename it, see below. Thank You, -- top

See for example ForeignFunctionInterface.

Top, as I figured out the hard way a few days ago, delete doesn't work if the page is more than 50 characters long (HowToDeletePages).

Top knows that. He's following a form of wiki etiquette by allowing people to see that he, himself, said "ok, delete this page", that he created. It's a question of timing; immediate delete vs deleting after a notice; the latter can avoid misunderstandings, and generally assist communication and consensus. (This is addressed somewhere in the howto pages, but I forget where.) -- DougMerritt

And you can learn a thing or two from your mistakes, Top. In particular, the opening statement:

"It seems that proponents of static/strong typing desire insular systems that perhaps don't connect well or relate well to external systems."

is borderline idiotic, and is an example of how not to open a discussion. You don't know much about typing, but you attribute to some generic category of folks (static typing and strong typing proponents) who you ought to presume at least as competent as you (to say the least) the desire to build lesser software ("insular" and "don't connect well"). You mix up your prejudices and ignorance with matter of fact, and on top of that you attribute invented stuff to your imaginary opponent in order to make the opposite side look bad. This is just ridiculous. It wouldn't hurt if you also read up a little bit in order to improve your English and your writing style. Other than that, this page is ripe for deletion, the pros and cons of static and dynamic typing are debated in dozens of other pages, while this one is not linked from anywhere.

It seems that proponents of static/strong typing desire insular systems that perhaps don't connect well or relate well to external systems. They prefer applications that can be "proved" by the compiler to be as close to "correct" as possible. However, one cannot compile all the possible external subsystems that may be connected to it. Thus, things such as databases, language-neutral GUI engines, etc., are viewed as a threat which must be wrapped in a protective shell that can be compiled and checked. While possible, it can be a hell of a lot of work to create and maintain the extra layer of indirection.

Such a technique may be applicable to some domains or circumstances but not others.

One of the reason that Unix-centric languages often use strings and files is that it allows multiple different languages and apps to more easily share the same information. Unix-influenced tools and apps thus have a mix-and-match flavor to them. However, this reduces the ability to check stuff by compilers. -- TopMind

CategoryTopMind?

I didn't say it was necessarily "bad". It may be a valid viewpoint, at least for some domains. If you can compile your entire world, that would be great. But if you live with or want to live with multiple tools that are not necessarily language-tailored, then it may be a hindrance. -- top

Doesn't matter what's your intention, it's one more example of your rants stemming from ignorance, unconnected to anything, incoherent and borderline idiotic. It only reflects your ignorance and prejudices. You're entitled to both, but Wiki is entitled to have such contributions clearly stamped with your brand.

To be nicer to Top, it ought to be pointed out that StaticTyping (or DynamicTyping) is not an all-or-nothing proposition. (I'm sure he knows that, but it bears repeating here). Statically-typed languages, of all sorts, have no problems whatsoever embedding SQL queries (and numerous other tools) in them, despite the fact that such things are largely foreign to the language's type system. You may have to dynamically check the results when you cross back in to the static-typing domain, but so what?

Even languages like Haskell and ML, which are far less used in "glue" applications and CrudScreens, are capable of this. I'm not aware of any (mature) language who's type system prevents them from interacting with a database.

I didn't mean to imply that they couldn't deal with such info, but in some cases it is more difficult, and one kind of "wastes" the ability that the language and static/strong typing provides. Everybody agrees that Java could be used as a glue language, for example, but few would recommend it for such (unless it was the only language they knew). -- top

Wiki is entitled to have such contributions clearly stamped with your brand Frankly, I don't see where you're coming from. In fact, in this community, it seems to me that it may be more popular to argue against type safety than for it. How, then, does the essay above represent a unique, TopMind brand of thinking, particularly since it explicitly acknowledges that type safety is probably appropriate in many circumstances? My opinion - remove all the content below the first horizontal rule above.

Yeah, arguments against StaticTyping have been made around here, but nowhere near the irrelevant trolling rant as presented in this page. That's why the contribution should be signed according to signature guidelines. If TopMind made his purpose to pollute Wiki with trolling, he's welcome to do so as long as he signs his trolls. Remove everything and keep the top portion with the TopMind signature. -- CostinCozianu
I don't appreciate the unfriendly flavor of your reply. I try to practice diplomacy. I suggest you do the same, otherwise you may pick up bad habits that will spill over to other areas of your life. -- top
if you don't appreciate the unfriendly flavor of my replies, you should consider doing something about the unfriendly flavor of your trolls.
If content is not a direct attack on people, it is apples and oranges. However, I would be willing to make some mutual compromises, but you don't seem receptive to it.

I am not necessarily trying to argue against it rather than point out where it may work well and where it may not. If an app depends on a lot of outside services, the value of strong/static typing may not come through nearly as easily. Such language users may prefer a lot of libraries built just for that language. -- top

Actually, I've found dynamically-typed languages to be about as difficult or easy to interface with outside systems as statically-typed ones. Strongly-typed languages (whether static or dynamic) may try to enforce correctness wherever they can (signalling errors either at compile-time or run-time), but interfaces to external systems written in a different language necessarily involve an escape from the language's type model. This is recognized and dealt with by numerous languages with widely varying type systems. The claim of this page is wrong. Please consider deleting it, Top, unless you have some real evidence to back it up. -- DanMuller

The title does not make a claim. However, static/strong typed languages do seem to require more code to do "string mode". Example:

  // dynamic language
  x = 2;
  if(foo) {
    x = getValueFromExternalSystem();
  }
  print(4.0 + x);

  // strong typed language
  int x = 2;
  if(foo) {
    x = (int) getValueFromExternalSystem();
  }
  print(4.0 + (float) x);

The strong-typed language still needs type declarations and casting. I suppose one could argue that the dynamic approach still needs validation to make sure x is a valid number, for example. But, this depends on how much we trust the external system. If we trust the external system, then no validation/conversion is needed, and thus less code. For example, if we get a value from a database, we can use it without ever having an explicit conversion step done on it. That portion will be less code. -- TopMind

I didn't say anything about the title per se. The page starts with: "It seems that proponents of static/strong typing desire insular systems that perhaps don't connect well or relate well to external systems." That's silly. Yes, static typing is based on the notion that you want the compiler to prove what it can. It doesn't follow that users of static typing systems don't want to interface with external systems, or that it's more difficult to do with static rather than dynamic systems. (At the very least, you've confused static with strong typing.)

I agree I have been sloppy with the typing "taxonomy" designation. But in general, strong and static tend to go together.

[More accurately, you may be confusing ProvableSystem? advocates with StaticTyping advocates. Obviously, the use of external libraries and systems greatly increases the burden of proving your entire system. But it's not really relevant to a discussion of typing.]

The example is a red herring that doesn't illustrate anything related to the page's topic. In a manifestly typed language, everything's more verbose than in an implicitly or dynamically typed language. -- DanMuller

Dynamic type systems are actually *less* capable of "language neutrality", because the typing system is very complicated at runtime, while a statically typed system just needs to shove bits around.

Example? How can a typing system be complicated if there (potentially) is none?

[Dynamic typing is not no typing. In fact, it's the antithesis of no typing. If you have no typing at all, then you obviously can't have dynamic types.]
I generally use the thumbnail classification of "static types", "dynamic types", and "type-free". The first has compile-time side-flags, the second run-time side-flags, and the third has no side-flags. (See AlternativeTypeDefinitions for a description of the "side flag" typing model.)

As evidence, note that the de facto universal "glue" language, which all widely used languages can call, is C, which is statically typed. There is a very large difference between the concept of "glue" language as commonly used, which is as an interface layer between tiers, munging data so that 2 different systems can use it, and a "language neutral" interface. Simply speaking, the assumptions as well as the conclusions on this page are wrong. Really wrong, in fact, I can't even find a shred of truth to dredge out. It betrays a fundamental lack of knowledge about the construction of computer systems at a low level (which, considering the author, does not surprise me). There is no such thing as a language-neutral interface. Period. There are things which approximate, or preset the appearance of such, but they do not spring into existence out of nowhere and people have to write them. This is true in all languages and environments. Databases are an especially bad example, if you look at just how many abstraction layers and interfaces the typical database connection goes through. -- ChrisMellon?

Somewhere IIRC there was an agreement that "language neutral" was continuous, not Boolean. Generally to make an interface usable in more languages, strings are applied because they are one of the few commonalities. "integer" may be two bytes on some langs, and four bytes in others, and there is byte ordering, etc. to consider. Thus, strings are often used instead and it is up to the target language or adapters to adapt to language-specific representation.

[In the strictest, most real sense, it *does not exist*. I don't like your continued use of the term because it implies something impossible. There are *only* two ways to implement a language-neutral API, which is either serialization to a common language (binary or string based) or a shared (binary) calling convention.]

I am not sure why you conclude this. Can you please clarify?

[It's innate in the way (current, at least) computers work. Unless all languages involved share a common memory model, calling convention, and even much of the same environmental characteristics (exceptions, for example), you can't just call from one into the other. Note that the .NET environment provides exactly this, which is why it's sometimes called a "language neutral". But you couldn't call from, say, Java into .NET without a translation layer. Or from anything else into .NET unless that language were compiled to .NET bytecode. Even just using "strings" as your calling convention has issues. What kind of string? Null terminated? Counted? How do you know where the end is? How do you extract meaning? You're creating a new language, with all the problems that entails. Look at the details of the SOAP spec sometime and see just how verbose and cumbersome implementing a calling convention as a string is. Note that a database is a terrible, terrible example of language-neutral. Sure, the SQL you pass is strings, but what format is your result set in?]

Maybe we should rename this topic to InterProgrammingLanguageCommunication?. That way we could perhaps classify techniques for such communication hopefully without the kind of value judgements that trigger flamewars.

[These are the *only* possibilities and no amount of handwaving whatsoever will enable anything different. Any cross-language functionality will involve language-specific wrappers in both languages. These are no harder in static languages than they are in dynamic ones, and often they are easier]

There are two issues here. One is it being "harder", such as more code, and the other is that strong typing seems "wasted". Thus, if one is going to be interfacing with a lot of other tools using a string-basis, then perhaps a dynamic language may be the better way to go.

Such things are hugely dependent on situation. NASA might hypothetically find benefit in writing a certain module (navigation or life support or...) in a static strongly typed language that enables a greater degree of proof of correctness. That module might then be re-used in a simulator used in training, which might be written e.g. in Lisp. There is certainly nothing illogical about mixed use scenarios.
UseTheRightToolForTheJob?