Java is a statically typed language which couldn't care less for type safety

TwelveBaud

The reflection mechanism. You probably don't want to think about it very much…

Reflection works well if you control the consumer, but isn't needed if you control the producer, and (without something like Reflection Emit, which there are third party libraries for in Java but they're kinda grody) isn't helpful if you're just "plumbing".@powerlord said:

Adding arbitrary data to an item can have its own special problems:
You've been adding library B specific things to application A objects for a while. You upgrade application A and suddenly start having issues with the data you were stuffing from Library B. What happened?
Well, turns out that Application A now has variables with the same name as the ones you were stuffing into it from Library B and one of them is clobbering the data from the other.

Yes, this is definitely a concern, but it's (usually) relatively easy to fix. Even if Library C expects App A objects with Lib B extensions with specific now-claimed-by-App-A names, you can move those data around inside the object to have the expected names. You have the power.@powerlord said:

Duck Typing ends up with all sorts of fun things. For instance:
In JavaScript, what does 9 + 8 + "7" equal? Personally, I don't know without testing. From the look of it, I'd think "177", but JS may decide that "7" is a number and make that 24 instead... or decide that all 3 are strings and have it be "987". Incidentally, after testing, "177" is the answer according to JSBin.
...but then 0 == "0" is true. If you don't want it to be true, you have to use === instead.

That can be a problem, but most affected languages aren't as braindead as PHP. Just because the answer requires some thought doesn't mean there's no good answer.@powerlord said:

Proxy objects are a convenience not a necessity. For that matter, dealing with SOAP requests (the most likely one you're using if you're creating a proxy object), with PHP's SoapClient, you may still end up creating a class for them in order to match the appropriate XSD complextype...

I don't disagree. But proxies are an extreme convenience, not just in SOAP, but also REST, state-tracking ORMs, cross-app-domain marshalling, .NET remoting, SignalR remoting, fucking god damn COM and OLE...

For that last pair, having dynamic proxies can be almost a necessity if you're working with a brain-dead object that QI's for IUnknown and IDispatch ("you tell me what methods you wanna call and I'll call them!") only. You can't use a tool to generate a static proxy (how will it instrument?) and writing one by hand involves a lot of copy-pasta.

@xaade said:

@Jaime said:
work required to implement strong typing
Something an app developer never does.

Sometimes I have to, when tools aren't available or screw up. It's not fun.

ben_lubar

It's because + is left-associative. The parser doesn't know what type a variable is before it decides where to put everything in an AST.

Buddy

@Jaime said:

I'm on the same side you are.

Well, you're not on the same side that I'm on, which is that working with dynamic types actually takes more effort than programming with static typing, because modern programming environments can offer far more in the way of contextually appropriate information or actions when they know what the context actually is.

Specifically, I am claiming that people who switch to dynamic typing because they don't want to deal with the tedious extra work of strong typing everything are ‘bad programmers’, because the ‘good programmer’ way to deal with something that can easily be automated is to automate it, not to just say fuck it and open up a whole new can of worms that you can't even predict but supposedly you'll be able to deal with it when it comes up.

@TwelveBaud said:

a brain-dead object that QI's for IUnknown and IDispatch ("you tell me what methods you wanna call and I'll call them!") only.

In the previous paragraph, I was careful to talk about static- and dynamically-typed objects, not static and dynamic languages. Dynamic objects, like the above, are not only a pain to work with, but they infect the rest of your code base with their bullshit, as you so eloquently explained.

dkf

My take is that while you're fine having strong types inside the implementation of components, when it comes to integration they're often a bit of a pain. Why? Because you spend most of your time writing goop that converts from one component's strong types to another component's strong types. After all, the components in question are often independently written, so why would they share types other than the most trivial ones? And the bigger the integration task, the more you have to write this crap.

You can always declare that all components must use a single common type syst… :D Sorry, can't keep a straight face and say that. It just won't ever work in reality, where the component authors either tell you to fuck off when you propose it, or declare that it's a great idea and they're already using the common type system and you should just switch to using theirs.

RaceProUK

@dkf said:

My take is that while you're fine having strong types inside the implementation of components, when it comes to integration they're often a bit of a pain. Why? Because you spend most of your time writing goop that converts from one component's strong types to another component's strong types. After all, the components in question are often independently written, so why would they share types other than the most trivial ones? And the bigger the integration task, the more you have to write this crap.

And this is why a decent OO framework has interfaces. That way, I don't care if your Frob is convertible to a Baz or whatever; if they both implement IEnumerable, then I can LINQ them and get my shit done

dkf

@RaceProUK said:

And this is why a decent OO framework has interfaces. That way, I don't care if your Frob is convertible to a Baz or whatever; if they both implement IEnumerable, then I can LINQ them and get my shit done

That just gets you one step down. You've still got to reassemble things into a List<Squergle> for so that you can pass it into another library. (List is part of the baseline of fundamental and structural types.)

boomzilla

@EvanED said:

duck typing

@EvanED said:

dynamic typing

@EvanED said:

weak typing

I really hate talking about typing. I always have to think through the differences, and which ones are opposites vs orthogonal. It's important stuff, but kind of tedious when you start comparing stuff like that.

RaceProUK

And it's not helped by 'strong v. weak' being more of a continuum than two distinct features. And then there's static-type languages that support dynamic types.

Basically, I don't worry about this v. that; I use the language I have/want to, and just get on with what matters: writing code.

accalia

@boomzilla said:

I really hate talking about typing.

thank you! i know i'm a bad typist! it's good to have someone who doesn't rub it in my..... oh we';re talking about a different kind of typing?

oooooh.....

/me backs away slowly

carry on then.... without me

/flee

RaceProUK

@accalia said:

thank you! i know i'm a bad typist! it's good to have someone who doesn't rub it in

Hey! I don't do that much!

tarunik

@powerlord said:

Duck Typing ends up with all sorts of fun things. For instance:

In JavaScript, what does 9 + 8 + "7" equal? Personally, I don't know without testing. From the look of it, I'd think "177", but JS may decide that "7" is a number and make that 24 instead... or decide that all 3 are strings and have it be "987". Incidentally, after testing, "177" is the answer according to JSBin.

...but then 0 == "0" is true. If you don't want it to be true, you have to use === instead.

That is not duck typing, that is sloppy typing, and it is BAD! See Python for how to do it right...

xaade

@Jaime said:

Naming isn't typing.

Also, trying to understand the advantages of dynamic languages using trivial examples will only leave you without answers.

It's the best you can get. And my point is that you'll have to do at least this much ANYWAY. So the argument that you reduce typing work is very small.

Let's see, you will declare the structure of the data, and give that structure a name.
You can add methods to that object, by giving it variables that point to methods.
You have to name it.

That's all the very same work you'll do with static typing.

Sure you can dynamically add things to the instance at run time, but so can a static language if you include an object array.

Basically, all you have is one type of object, a type that hosts an array of objects. But you'll still define it. You can't operate on it without defining what it has.

So, I fail to see how any work is saved.

@Ragnax said:

most of the type recognizability and stability of a static language still attached

How so, by including metadata with the instance of the object? Maybe you give a variable that holds a name?
All you've done is define the object further, adding in what static classes already have.

Essentially you're performing the work you're supposedly saved yourself from having to do. Making the only argument for dynamic typing pointless, because you can accomplish dynamic typing in the same way in a static typed language.

Either manually

class dynamic { Dictionary<String,Object> members; }

Or by assigning to a dynamic.

dkf

@xaade said:

you can accomplish dynamic typing in the same way in a static typed language.

Nope. You can't do things like adding types to an object after creating it. I'm told that that's useful for modelling certain kinds of problem in things like agent-based systems, where agents can totally alter their behaviour patterns in response to environmental changes. (You can do things with delegates that sort of simulate this sort of thing, but it's awfully messy and complex.)

xaade

Expando Object

dkf

@xaade said:

Expando Object

Then you're not working with the type system any more. ;)

xaade

That's my argument.

Add enough meta-data to dynamic objects, and you're doing static typing work, nullifying the argument that dynamic typing saves you any work.

At which point, you'd be better off just using a statically typed system.

Now if the goal is objects that you can add to at runtime, then dynamically typing is a better option. (something that Expando object gives you).

My justification for which language is based on the task, not any speculative work saved, especially when the "responsible" way of using dynamically typed languages is to artificially create pseudo statically typed objects.