Wednesday, September 5, 2007

5 Reasons Static Typing Sucks

Static typing is a pedantic construct, bred from experiments of the first Object Oriented languages, in the same way that the Vienna Circle was an experiment with the Tractus - a confused failure (for those robbed of a formal philosophical education I'm not just being an asshole here, the case is apt and expanded below). I am not against all forms of static typing, and for example, do appreciate how ECMAScript 2.0 uses a mix of static and dynamic types (adopted by ActionScript 2+).

It is not type-safety I am against, per se, it is the mindless parroting of virtues of "compile-time checking" while citing none of its drawbacks. I am against being forced to statically type everything in a language when it is not always necessary (consider in Java giving an Object a type, just to put it into a Map, where its type is lost, and convert it, at runtime, back into a type - though to be fair, generics go a long way to fixing that mess. But I maintain that a real type-safe system would have no need for ClassCastException). In my opinion type safety has one shining virtue: to solidify APIs. But I feel the trade-offs between the dangers of dynamically-typed languages versus the constraints and verbosity of statically-typed ones is an easy choice to make. I will create my own safety, thankyouverymuch. For those craving a visual experience, here is my belief codified:


Perhaps it would be hyperbolic to claim - being forced back into wrestling with a static type system - I'd prefer to wrestle with the business end of a shotgun. But I do have reasons - a mix of Ivory Tower and practical reasons which are sure to sway no die-hards on either side of the isle, but must be made mention for posterity - so at least our progeny can rest in the knowledge we weren't all mad.

1. Static typing requires extra typing

Keyboard typing, that is. As far as I am concerned - anything that adds more code is a Bad ThingTM. It slows down development and increases the potential for defects. Working around the rules of a type system requires extra code that detracts from the problem at hand. All I ever hear in response to this is: yeah, but the compiler catches type errors. Have you ever run into a ClassCastException in Java code? How is that type-safety? Moreover, how common are type errors - I mean, really? I so rarely come across them at my job (where we have a whole staff of developers working on the same Ruby project) that it is hardly ever a consideration. All I can figure is that type-safety stops bad developers from doing dumb things, which my stance is quite simple on bad developers: fire them.

But the larger point is that programming will never get away from the need to give variables meaningful names and some sort of rudimentary documentation (even if that documentation is merely simple and readable code). If you use meaningful names, you can always figure out a type. In fairness, I have, in Ruby, been forced to resort to the following when running across unfamiliar code:
puts var.class
Before you start yelling "fowl!" I'll have you know I've typed my fair share of this kind of crap, too:
System.out.println(list.get(0).getClass().getName());
Have I ever written dynamically typed code that has run for two hours, only to return and find that it broke because of a typeo or a wrongly-used type? Yes. But in almost every case it could have been fixed by better unit tests. Besides, those few situations pale in comparison to the man-months saved in typing, digging through verbose code, and wrestling with the type system.

2. Static types are unreal

Real things are not statically typed. If you accept Phenomenology's basic views of reality (which - if you are an existentialist, Eastern philosopher, or relativist - you do by fiat, and you are an Objectivist - well, there is no hope for you), "objects" are only signaled (or named) by their utility. For example, we have a word "hammer" because in our system of perception we have a use for declaring it as a single class of objects with a common utility. What do you do if you need to bang on a nail and you don't have a "hammer"? You find a substitute - a rock for instance. You use the rock "as a hammer" in which case it too becomes a "hammer".

Even if you do not buy the above statement - in every day life, as long as we can successfully use something for which it is needed (as Heidegger would say Zuhandensein, it is "at hand"), that is good enough.

Consider that I am building a deck behind my house. My requirements for materials are: sturdy, cuttable, nailable, and looks_nice. Now I'm given objects of type "Wood" and some objects of type "Plastic". As long as my objects work for all criteria of which I require, it hardly matters what they are actually made of - even if I did not know in advance what I would be using those objects for.

Static typing not only requires you to know what you want to do with those objects in advance, it requires you to codify it (via either common inheritance or codifying for all known desired types - think if...instanceof in Java). This brings up the next problem:

3. Static typing requires you to know the future

Logical Positivism has failed. This is the philosophy that a comprehensive view of the world (via proven scientific statements - note the key word: proven) can be built up from simple to more complex statements like mathematical theorems. Of course, this was quickly shown unworkable via the criticisms of guys like Karl Popper and W. V. Quine - basically, science cannot "prove" anything (only disprove and give a best guess - or theory) and that since language can change with new discoveries, previous theories are all suspect (the term "gravity" has a different meaning after Einstein than it did after Newton, so building mathematical statements from the proofs of "gravity" would be to build on a house-of-cards).

Yet - despite the fundamental inability for a workable theory to be built off of a language of static terms - this is precisely what statically typed languages attempt. For example, consider that we create a software system that models a ball manufacturing company. Undoubtedly, we have an object named "Ball" that has a property "radius" and specialize (extend) that type to "SoccerBall" and "BasketBall" with their own properties.
abstract class Ball {
Float radius;
}

class SoccerBall extends Ball {
Boolean boringToPlay;
}

class BasketBall extends Ball {
Boolean boringToWatch;
}
Everything looks fine, so we build our entire system based on the "Ball" type including manufacturing and billing. Everything looks fine - that is - until the company decides to start making rugby balls. So we extend the "Ball" model with "RugbyBall" - now what does the inherited property "radius" mean? At best we retrofit a meaning, at worst we ignore it. Whatever you do - your manager may still chastise you for your short-sightedness. Just let her know that you fell victim to a shortcoming of the logical positivism of which static typed programming is too similar - it is not your fault.

If you do attempt to re-define what "radius" means we need to retrofit the term (this is a common phenom in linguistics. For example, consider the word "oven" - when "microwave ovens" became popular a new term was required to differentiate the two: "conventional oven"). Static-termed languages are not equipped to deal with this change so we create substitute tricks like Aspects or Dependency Injection. But whatever we do - we tend to require a lot more typing to fix the fundamental flaw: such languages are ill-equipped at dealing with reality except in the narrowest sense, and can only grow via retrospect. So-called dynamic or "duck type" languages minimize such problems, since they make no assumptions on what terms (types) mean, only how they are used. You change where you need to, and elsewhere leave well enough alone. Our temporal frailties aside, the fact that the future can bring about unexpected changes have birthed one of the most frightening words in the developer's lexicon: "refactoring". So much for the idea that terms are static - yet delusional, we lumber on.

4. People want to work around it

I consider this the best evidence against (required) static typing. Theories are good, but like the old quote goes, "in theory, theory and practice are the same. In practice, they are not."

People want to work around static type systems. This is evinced by the rise of frameworks such as Spring in Java (configuration and run-time object override) or Reflection in C# (run-time view and replacement). As time goes on these languages keep adding more and more features to loosen the static typing (Java did not originally have Reflection - now they are considering adding named arguments for easier integration to dynamically typed scripting languages). I've read James Gosling claim that "safety is freedom" since you always know what type you are getting back - but is that really the case?

Orwellian-sounding phrases aside ("safety is freedom", "war is peace", "static is dynamic"), many powerful modern Java frameworks are built on some sort of Inversion of Control principle (like Eclipse or Maven) - which completely removes compile-time safety since types are not resolved until run-time - and work by voodoo such as runtime reflection, bytecode manipulation, and killing chickens. (Now, don't come to me and say: you're confusing the compiler and the type-checker. True, the JVM verifies type safety at runtime, but by then it's too late... you may as well have scripted your code.)

My single question to these frameworks is: why all the hassle? If static typing is so great, why do these frameworks work so hard trying to circumvent it? Perhaps it is a cultural artifact of the C++ and Self days, and a lingering confusion of class versus prototype-based programming. Is it an idea that John Q. Programmer holds, that class-equals-static and prototype-equals-dynamic? Do fans of class-based languages think they need to support static typing to support the concept of classes? I wish I knew - but the love-hate relationship between a programmer and their favorite language's type system astounds me.

5. Valid logic is rejectable

class C {
Integer getDefault() {
return new Integer(0);
}

int func(Float x) {
if( x == null ) {
x = getDefault();
}
return x.intValue();
}
}
The above program will not compile in Java, despite the fact that the above program would not fail at runtime (ignoring JVM checks), since both Float and Integer inherit intValue from Number. But the type system requires you to rewrite the above perfectly logical code. This time - this one time - I want Float and Integer to be compatible. But no, the Mighty Type System has spoken! This is somewhat related to the first annoyance - but is not so much about the extra code required to rewrite the above into something acceptable by the type system, but the fact that it needs rewritten at all.

Here is a rewrite of the above function func to agree with the Java type system.
  int func(Float x) {
if( x == null ) {
x = new Float( getDefault().floatValue() );
}
return x.intValue();
}
It adds no real descriptive value as to what the program does - its extra verbosity makes the type system happy, sure, but does it make the code any more functional, more readable, or less error prone? The answer to all three questions is "no". Are cases like the above worth throwing away a whole type system - just for a few coding shortcuts? I claim yes, it is. At the very least drop such a rigid static type system... dare I say a static static type system? No, I suppose not. Coming up with such bad puns is unbecoming.

So that's my list. Did it change your mind? Unlikely - indoctrination is hard to unravel, hence the difficulty with Zen. Don't take my word for it, try creating a large-scale project without a statically typed language. Am I assuming you haven't? Yes. So few people get the opportunity. Try it, get back to me. Please, no stories older than 5 years ago: "Eric, we tried using Perl 15 years ago and it was a disaster!" Try again with modern techniques. Perl has grown - shouldn't we all?

34 comments:

Tim said...

So you've softened your stance on Objectivism since I first read this post (skimmed, really — thus the re-read...) Kind of disappointing, but then again people tend to perceive me as severe and judgmental, I think. Compassion, moderation, and humility... NO, THANKS. Haha.

On topic, I don't know, I think I prefer static typing on the whole. You call it verbosity, I call it explication vs. implication. My boss is a terrible coder, but I would rather re-work his poorly written VB.NET than his poorly written, IE-specific javascript ANY DAY OF THE WEEK.

And, hint: I cannot fire my boss. Sure, I could quit and find a higher paying job closer to my apartment. But they probably wouldn't let me W.F.P. (Work From Porch — It's the "new black" in working from home...)

Eric said...

I can see your point - I guess. I personally prefer to fix a bad coder's script-jumble than a bad coder's framework (which tend to spring up like weeds in the space where static typing and bad coders cross). I just had to signal that there is a downside to static-typing, despite what the fanboys might claim, and a lot of it is systemic.

Although the language has softened - believe me - my stance of Objectivism has not :) - it was simply brought to my attention that I should refrain from my copious usage of F-bombs. I'm starting to rethink that fucking shit.

Isaac said...

Yeah oddly enough depending on who you ask I would be considered an Objectivist (I'm not a big fan of labels) but I don't disagree with Eric all that much. While most Objectivists spout "A is A" most don't seem to have though about the "is" part. The A is A is more about an external objective reality than how we use such a reality. The use of the object is what this topic is about and I see no conflicts between the two.

Isaac said...

One might characterize me an anti-labelist I guess.

Eric said...

Cool. I will then label you an anti-labelist :)

Isaac said...

Is that a static label?

Anonymous said...

why you use ruby as example of dynamic language ? javascript is much better that ruby, you can do the same and you dont have to write code that looks like sql(i hate the "end" word, how is that faster that }?)

i think you should look more into javascript. Now you can write big apps with it using Java6, plus since you use javascript on client why not also use it on server?

el diego said...

How come Smalltalk is never mentioned when praising dynamic languages? I thought I had found heaven when discovering Ruby. I guess many people like me have never been exposed to Smalltalk in education, but rather learned object orientation through Simula -> C++ and derivatives thereof (including Java). Languages like Python and Ruby become a liberating breath of fresh air, but I recommend anyone to at least dabble a little with Smalltalk and find true generality. Combined with modern discoveries such as Traits, Smalltalk is a VERY powerful and general language.

Anonymous said...

how come that everyone that hates static typing has only used it in Java. It works great in Scala and Haskell. And with an IDE, the verbosity of Java is created using only a small amount of key presses. Dynamic typing vs static typing is nothing more than a personal preference.

Anonymous said...

I notice that you like lists, so here's one of mine:

1. It's nonsense to claim that extra typing slows down development. If additional type declarations reduce the time required for debugging and allow for faster refactoring, then they can speed up development (note that I'm not claiming this is the case, just highlighting the lack of logic in the "extra typing -> slower development" argument)

2. I'm not convinced that you understand what "static typing" means. Try s/static/strong/g.

3. The logic of your code in item 5 is actually:

class C {
Integer getDefault() {
return new Integer(0);
}

int func(Float x) {
if( x == null ) {
return getDefault();
} else {
return x.intValue();
}
}
}

4. Intellectual masturbation might not make you go blind, but it can blur your vision.

Paddy3118 said...

To Anonymous,
On your point 2, I'd suspect that the O.P. is in fact talking about Static versus Dynamic typing, not strong versus weak.

In general:
Being a Python fan, I know where he is coming from. I'd like to think of run-time versus compile time type checking, as being a continuum where too many languages are set in the static camp and have clumsy methods to do bolted-on dynamic type checking; and there are a few clumsy methods for adding static type checking schemes to dynamic languages to aid in compiling them to machine code.

I'd like to be able to write normal Python that works for the Interpreter, but have a Python compiler make assumptions like names are always going to hold items of only one type, lists are homogenous, etc; the ncompile sections of my program I decide into machine code. The PyPi project are some way down that route.

Haskell it seems allows you to write the minimum type annotations then inferring the rest, to get your program to compile. The emphasis is wrong for me - The primary target should be an interpreter and run-time type checking, with compilation+static type inference and checking only on request.

The default should be the extra *programmer* productivity you get from a dynamic language with a good shell, rather than run time speed, which is an optimization and so should be treated as such.

Oh, I can't resist:
Another "reason that static typing sucks", They don't have doctest.

- Paddy

Ricky Clarkson said...

"Static typing is a pedantic construct, bred from experiments of the first Object Oriented languages"

Static typing predates OOP.

"I maintain that a real type-safe system would have no need for ClassCastException".

Such type systems exist, so I can only assume your blog is about Java's type system, not static typing.

"But I feel the trade-offs between the dangers of dynamically-typed languages versus the constraints and verbosity of statically-typed ones is an easy choice to make"

Er, that's Java again. Haskell is often less verbose than Ruby/Python/Perl.

"1. Static typing requires extra typing".

That just isn't true, but I think the important thing is that Java code is bigger, not how many keypresses it takes. You could automate the keypresses, but that wouldn't improve the resulting code.

"Have you ever run into a ClassCastException in Java code?"

Very rarely since Java 5. Less than one every 6 months.

"Moreover, how common are type errors - I mean, really? I so rarely come across them at my job"

Arguably, all errors are type errors, it's just that your type system doesn't let you express your code well enough that the typing system can catch the error. E.g., a/b can only succeed if b is not 0, so implicitly b must be of the type "not 0". Better type systems/languages can notice that and tell you about it.

"Real things are not statically typed"

Programs are not made of real things - they only model real things.

"As long as my objects work for all criteria of which I require, it hardly matters what they are actually made of"

Haskell's typeclasses go some way to addressing that - instead of coding to an implementation type you code to the typeclasses, similarly to Java's interfaces but with less code.

"3. Static typing requires you to know the future"

This section goes into the problems of inheritance, and I'm not sure why. Static typing is orthogonal to inheritance. I don't even use subclassing in Java.

Your method func() can be fixed by making its parameter of type Number. The fault is that the type system forces you to specify the type - in this case you specified the wrong one (and also didn't notice that you had - you blamed the type system instead).

For more background on these issues, see a recent blog post of mine:

Stop Sitting on the Type Fence.

Eric said...

I'll read the above later, but want to post this from D-Zone - lest my experience is suspect again (which it shouldn't - I would hope the article would speak for itself):

A little about my resume:
C++ developer working on high dimensional structures (SR-Trees, SP-GiST) for multimedia database indexing (think thousand dimensional searches).
2 year Maven contributor - involved after spending almost a decade coding/architecting large-scale Java systems (factories, then hospital), before moving onto Java build management.
Committer to Terracotta (Java clustering) for code management and Plexus (Codehaus IoC container - predates Spring).
Currently a full-time Ruby (not Rails) developer for a keyword search statistics and placement company - in short: lots of processing - more than most Java projects.
Also used: C#, ECMAScript, PHP, Perl, and more unrelated functional languages

Since "preconceived" implies "ill-informed" what more can I do to learn about the wonderful world of static-typing? Should I have used more maths - thrown in some lambdas?

Eric said...

Anonymous 1: I love Javascript - I actually started the post praising it (ECMAScript). It's not the JVM I dislike... I'm a huge fan of JRuby.

el diego: Smalltalk is awesome - I've just not had the pleasure of working with it professionally. Yet, a friend of mine was, and he read over the post pre-publication. I assumed he'd yell at any red-flags.

anonymous 3: "reduce the time required for debugging and allow for faster refactoring" - this is a post I've been thinking about. The idea that those are necessarily good things... the value of that over fast development decreases significantly when you consider that (approx. - need to find the study) 85% of all software projects never reach production... think about it.

Also, I'm well aware of the difference... are you?

Nice refactoring - works if you use Java 5. I guess I need a new example.

You're trying to clean up my mental masturbation? What would that make you? :)

Paddy3118: I love Python... I forgot to mention that one. Good story: Jimbojw and I used to argue about the merits of Python, for something like two years. He hated because - get this - it is whitespace-delimited (which I like). Guess what? He's a Python developer now. Eat it, Jim!!

Ricky Clarkson: I did read your post, I actually like your blog very much.

There were a couple reasons I stuck with Java and Ruby:
1) I know them well - that's not to mean I don't know others, just that they are my areas of expertise.
2) They are (arguably) the most popular languages that display my points.
3) I didn't want to keep jumping languages - lest confusion abound.

Eric said...

Good post, he makes a good point: One Reason Static Typing Doesn't Suck

Andrew said...

Interesting article. However, the link between philosophy/epistemology doesn't ring true with my experiences.

Point (1) is a given, although type inference (a la Haskell solves a lot of this).

Point (2) is definitely true. Types are unreal, but they are still useful in the way that Platonic classification is useful. Not having static types doesn't make the need for categorisation (particularly as a vehicle for understanding) to go away.

I model using this type of classification, which is classic OO simulationist modeling. Is it perfect? Definitely not, but it's decent enough for most problems.

(c.f. the critique of OO modeling in "Generative Programming: Methods, Tools, and Applications" where they look at the definition of a "table" i.e. with 4 legs, or is that a one legged table... :-)

Point (4) -- people do work around it, but it gives a base. I'm longing to find other classification systems that are outside of static types. Surely it's not too much to ask that people describe the logic behind the classification systems used in some advanced dynamically typed programs?

Point (5) -- an odd example. Number is a valid subclass that can deal with this example. Replacing Float x with Number x will work. In a statically typed language, the type of a reference is making a statement about its capabilities. Clearly Integer is not as capable as Float. In a dynamically typed language, although the assignment works, if someone a bit further down expects the x variable to respond to floatValue() they will be sorely disappointed. This is the tradeoff.

Andrew

Andrew said...

Just a quibble about your characterisation of IoC -- these systems in no way remove static typing. They just push the concrete classes used into a later phase. The capabilities of objects are still codified completely using interfaces...

The problem that IoC solves is not static typing -- it is hard coded dependencies on concrete classes. Makes unit testing and reuse easier. This could also be used with a dynamically typed language for the same benefits.

Andrew

Andrew said...

Also, as background to my comments, I have programmed commercially in Smalltalk and have also created large programs in Python...

And although Smalltalk does give the freedom of dynamic typing, it is not terribly unusual to get unknown selector errors which result from people mistaking the capabilities of objects. Can be troublesome on large codebases.

Andrew
p.s. why does everyone complain these days that those who might have different ideas are indoctrinated. This is special pleading.

Stephan Leclercq said...

Oooh I positively love your examples!

You build a billing system around a ball? Then wonder where you got it wrong? I would build a billing system around a bill, but hey, what's in a name. Obviously, your ball example also mixes the actual round and bouncing object with the televised game that is played with it. But hey, that's only an example. Yes, have you seen that: every time we're talking about the silliness of static typing, the example used to make the point is completely ill-typed...

And of course, you are mixing two unrelated things. Types - defining usage, identified during analysis and being more or less represented by interfaces in Java - have nothing to do with Classes, identified during design and defining implementation, so checking a type by class matching is of course bound to fail.

What really sucks is not static typing. It is the fact that many of the statically typed languages lack a proper way of binding classes and types.

Now, if you want to prove that static typing sucks, show me a real example with sound analysis and design (ie properly typed :-) where the type limits your expressiveness. Then you'll convert me to the other side.

Eric said...

Stephan: Sure I understand the difference between type definition via classes and actual types. Forgive me for assuming that those reading the article would know that distinction as well.

Since my example was Java, I didn't feel the need specify that a type was "class+classloader", because in practice you rarely have different class definitions of similar names on different classloaders (versions, especially model classes) - so for all intents and purposes, yes, class is the type. Again, forgive me for over-estimating the knowledge of my readers.

The example is (simplified, but) sound for outlining the point - which you expanded nicely. Your response "your ball example also mixes the actual round and bouncing object with the televised game that is played with it" is precisely the problem. If I am attempting to model my business with my system I have to know - in advance - how the objects will be used. By your logic just create different types - well, that's exactly my point. I don't know how my objects will be used in the future - which is why I dislike the idea of static typing... it requires me to know.

Stephan Leclercq said...

Eric, actually no you don't need to know the future. Your billing application will use billable objects, so there is no reason not to declare the variable holding them as BillableObjects (defined as an interface.)

Now if you also have Balls and Platypuses objects in your application and want them to be considered billable objects, make them implement the interface BillableObject and you are done.

Now the real problem here is that in Java there is no easy way to declare that Ball implements BillableObject without actually changing the source code in Ball.java. There should be a way to declare "oh by the way, as far as my application is concerned, Ball implements BillableObject" in some other source file. Or better yet, the compiler can (statically !!) detect that Ball implements all needed methods of BillableObject, and thus a Ball can be assigned to a variable of type BillableObject, and maybe issue a compilation hint.

You are blaming static typing for shortcomings in current specifications of statically typed languages.

witkamp said...

Hey Eric,
Which of your objections to static type checking still holds water against "Concepts" aka "Haskell Type classes".
The current OOP model is dead. But OOP != static type checking. If the first think that you think of with static type checking is Java. Well I am sorry.
OCaml and Haskell are completely statically type checked and I have never heard any OCaml or Haskell program wish for duck typing.

I hate the current OOP model as much as the next guy but going to a complete dynamic model like that of python or ruby can get you very stuck.

I know the dynamic community loves to attack static type checking but what they really don't like is typing a lot of code in Java.

I am just saying that there are alternatives and they do type check!

Eric said...

Oh crap, witkamp, I was hoping someone like you wouldn't point that out! Certainly the post was targeted toward C++-style static typed OOPLs... the languages most are familiar with - and not you, who know more about PL than mortals should.

I won't debate Haskel... I only wish I were cool enough to get a job programming it - never had the pleasure of dealing with refactoring a typed functional language project.

But OCaml? I hardly see how it is exempt from the problems I've outlined (except for lots of code). From what I hear, dealing w/ the type system is one if its annoyances. If it does indeed bypass these conventional statically typed OOPL problems, perhaps it's due more to its functional underpinnings.

In any case, as usual Big T, you're not wrong. However, as evinced by most of these comments, I can hardly rescind my statements, eh? It is sad that the current object-oriented static model is so popular, but if anything, the likes of Java and .NET are only growing in popularity.

Take care;

Anonymous said...

The only argument I see in any of this is against typing a few extra characters.

Personally, I'd like to open a discussion on how difficult is it, really, to type, say, 20% more characters.

On a codebase that has a man-year of work in it, I could general re-key the entire thing in a man-day or two. Typing stuff in is not what is slowing anyone down.

Smaller code does tend to make things more readable to a certian point, but I find that whenever code has been too long it has been because of poor design and a lack of factoring, not the language. An extra cast, if anything, reminds you what variable is there and can make the code more readable.

The advantages in early error detection, however, are measurable and significant.

So, as a thought-experiement, can you assume that there is no problem typing casts or having slightly longer code and tell me what is wrong with static typing?

netytan said...

I stopped reading after the first paragraph. Static typing didn't come from experiments with early object-oriented languages... so disappointing.

Eric said...

Oh Jesus, another college student. Listen Junior, Simula started OO in academic circles, and Smalltalk (non static) existed (within Xerox), but OO didn't become ubiquitous until C+classes, which later became C++. No SERIOUS work on OO existed before C++, besides a lab here and a paper there. This unfortunately poisoned the minds of many programmers to think OO NEEDED static typing.

And I'm going to punch the next person who mentions Haskell in the nuts (or ovaries, if called for). When it becomes as used as Java/C++/C#, I'll drop my case.

netytan said...

Ok, I bit the bullet and decided to read the article anyway.

I love dynamic languages, but you sir, are an absolute ignoramus.

netytan said...

Eric:

Programmers were writing OO programs for years before the term was coined; years before Simula; years before Smalltalk. It's an obvious way to structure programs.

The AI community for example were using objects well before both of these, under the name of agents. These were usually dynamically typed, because the languages used in this domain are usually dynamically typed.


The fact is that OO was developed in a lot of different places under a lot of different names at around the same time.


OO doesn't inherently have anything to do with static or dynamic typing!


What's more, the theory behind OO has been around since before computer science!

Anonymous said...

I tried to continue reading even after you referenced the Vienna Circle (in an article about typing systems!), but after you misspelled the name of the Tractatus, it became to painful.

Don't try to look smart. It becomes embarrassing oh-so-quickly.

Anonymous said...

Hi you are good!I'am not good, though not as good as you. You have such a great potential. Keep it up! Busby Seo Challenge

Itay Maman said...

Two more points that the static people tend to forget:

1) Null values. Even the crown jewel of static typing, the promise that the method will be there, is not always true: x.f() will compile but may fail at runtime if x == null

2) There are all sorts of situations where the object at hand cannot support the method that you invoke: Many iterators throw an 'unsupported' exception when their remove() method is called; LinkedList.removeFirst() will throw if the list is empty; and so on...

Anonymous said...

I don't think that you've got it right blaming logical positivism in the Ball to RugbyBall example - LP was a theory of meaning - that the meaning of sentences was fully a function of their verification - and someone can reject all that and still keep a world view that is basically foundationalist and hierarchical. That kind of concept of reality doesn't seem (to me) to depend on a single theory of meaning, such as LP, and it sounds like it's more to the point of what you are criticizing.

Very interesting article, thanks

George said...

what about the ability to reload code at run time you really cant do that in a typed language. also in typed languages you can have problems with fixnum/bignum overflow because of over specified types.

for dynamic problems no types are better

for static problems types are better.

ps. types are a compile time thing only.

Criminal Background Check said...

Thanks for a nice and informative site. Somehow I was drawn to reading the post and I enjoyed a lot. Have a nice day!