Quite often, actually. Or do you not need access to the same content from work and home? Or at a friend's or relative's place? Or on your spouse's laptop because you don't want to grab yours?
And that's assuming what I'm doing is so sensitive that I feel the need to be that paranoid. And given that rule doesn't apply to email (yes, that's right, email... it already travels via SMTP in cleartext, so if you're that paranoid, you should be encrypting anyway), anything I do with google docs, bookmarks, and so forth, most of the time, it's just not a big deal.
The only reason webmail is popular is that people do not like taking the time to configure an email program to connect to their POP3/IMAP server.
Really? Funny. The reason *I* use webmail is because it's available any place where there's Internet access. That's also, as it happens, the same reason I use a service for storing bookmarks (del.icio.us), personal information/notes/etc (a private wiki), some small docs/spreadsheets (Google apps), and so forth.
The idea behind a network, any network, is to enable collaboration.
That's just ridiculous. Or have you never heard of a mainframe?
The idea behind a network, any network, is to ship information from point A to point B. That could be data from person A to person B over some sort of collaborative software suite. OR, it could be an application from server A to thin client B, so that B doesn't have to have all those apps installed locally, thus resulting in lower deployment and upgrade costs, cheaper hardware, and so forth.
In short: the Internet does not, in fact, conform to your limited personal view of it. Get over it.
If a language provides a small and mutually orthogonal set of powerful constructs which fit well together, people tend not to have to invent their own meta-programming systems to get things done.
And yet the power of Lisp, Haskell, and Smalltalk, three incredibly elegant languages, is in the ability of the developer to build their own "meta-programming systems". Lisp has it's incredibly powerful macro system, allowing for things like the CLOS. Haskell has it's system of monads which allows things like Monadic parsers and so forth, allowing for incredibly powerful embedded sub-languages for accomplishing tasks. And Smalltalk doesn't even have an 'if' or 'while' statement, instead encouraging flow control and other constructs to be built into the class library. Meanwhile, all three languages allow one to mix programming models freely (Lisp and Smalltalk both support OOP, functional, and procedural development, while Haskell has superb support for pure, lazy, functional development while allowing one to "package up" procedural code in safe little lockboxes where it's needed).
So, just looking at that list, I wonder if it's maybe *you* that has the problem, rather than Javascript? I mean, Javascript is really just Self for the web, and Self is just Smalltalk without classes, so if you've got a problem with Javascript, then I can think of very few languages that would satisfy your (incredibly unreasonable, overly picky/anal/restrictive) requirements.
Frankly, I think Javascript's biggest problem is that, unlike Lisp, Haskell, Smalltalk, Ruby, Perl, or Python, JS doesn't have a strong core community that can help provide guidance and dictate standards for development. While all those languages provide a wide array of tools for getting any particular job done (with Perl at the most extreme end), all have communities whose output includes a standardized set of libraries, tools, and documentation, along with coding guidelines and traditions that can help guide new members of the community. And I strongly suspect Javascript lacks such a community because the growth in popularity of the language has been haphazard, and out of necessity, rather than because a core group was driving it's adoption. And I don't see that changing any time soon, unfortunately.
You seem actively bitter about the possibility of forks while explicitly choosing a license that not only allows them, but makes it so simple that it basically encourages them.
Actually, I think it goes deeper than that.
Most people don't *want* to fork projects. Your average contributor is a career developer who's probably being paid to do something else entirely, and only contributed to the project because they needed some functionality to get their job done. Alternatively, they're hobbyists, in which case taking on the responsibility of maintaining a fork isn't something most people are interested in.
Instead, the reason forks happen is because the maintainer is, for some reason, hostile to the wishes of some not-insubstantial portion of their user base. In this particular case, it appears the OP is actively *annoyed* by people requesting features. Well, big surprise that, in such a situation, people are likely to fork your codebase: given the option between maintaining your own fork or dealing with a hostile maintainer, forking is obviously the best solution. And so the OP, rather than, say, being less hostile to and more cooperative with his user base, chose to simply take his ball and go home.
Fundamentally, it's an attitude problem: some people see software development, and OSS in general, as a collaborative process, and enjoy working with others, accepting contributions, etc. Others, however, see users and potential contributors as a nuisance and something to avoid. Big surprise if the latter group choose to obviate OSS in favour of a closed development model.
I used to open-source everything I do. No more. My current project is closed-source (but free) application. While there are quite a few users, very few butt in with "extensions" that they feel absolutely must be there.
Great, so in a case like this, where a user created valuable new functionality, you wouldn't benefit. Instead, you'd be stuck doing the work, or refusing to do so, in which case you'd lose a customer who'd be forced to move to a different product, instead.
Basically, rather than ignoring useful patches, you now have to ignore users requesting useful features, who then just move on when you say 'no'. Yeah... that's much better.
No forking either - you don't get to take the results of my work, add a few things and distribute, creating confusion and incompatibility, which lead users to other products all together and hurt me (I don't care about the other guy).
How is that a product of being OSS? The issue, here, is very simple: a maintainer that's either non-responsive or MIA. If the maintainer were responsive, the changes would be added to the existing product, and everyone would be happy: the originator wouldn't have to maintain a separate tree, the maintainer wouldn't have to write the code themselves, and the other users would benefit.
In fact, in this particular case, closing the source only does one thing: fucks the customer, as they're now forced to find something else, since they can't just take the code and alter it as they see fit.
Now with a closed-source application, no such thing and quite a bit of feedback begins with "thank you for the great product"
I'm sorry, but I have to call "bullshit", here. Whether or not you get feature requests has absolutely *nothing* to do with the license the source code is under. Either way, you have users with ideas about how the product should work. The only difference is that, in the case of closed source, the user can't just contribute code back to you. Instead, they have to wait for you to decide their idea is worth implementing (and then live with whatever implementation you come up with). That sounds like a lose-lose proposition to me.
Since "duck typing" is not a well-defined term, I guess we'll have to just agree to disagree.
Well, Wikipedia seems to think it's reasonably well defined. Here's what the consensus says (obviously I'm going to abbreviate, here, but you can see it for yourself):
In duck typing, one is concerned with just those aspects of an object that are used, rather than with the type of the object itself. For example, in a non-duck-typed language, one can create a function that takes an object of type Duck and calls that object's walk and quack methods. In a duck-typed language, the equivalent function would take an object of any type and call that object's walk and quack methods. If the object does not have the methods that are called then the function signals a run-time error. It is this action of any object having the correct walk and quack methods being accepted by the function that evokes the quotation and hence the name of this form of typing.
Obviously, what's described above can't possibly work in a statically typed language, inferred or otherwise, as the types of the parameters for the function are well known and enforced at compile time. In fact, the definition goes on to say:
Duck typing is aided by habitually not testing for the type of arguments in method and function bodies
And:
Users of statically typed languages new to dynamically typed languages are usually tempted to add such static (before run-time) type checks, defeating the benefits and flexibility of duck typing, and constraining the language's dynamism.
Given that, I really don't see how Haskell, OCaml, or C++ (templated or otherwise) can possibly be considered "duck typed".
It's a curious listing, but I don't really understand why you wouldn't consider the listed languages to be duck-typed even under your, stricter definition (of dynamic typing + dispatch). Or am I missing something?
Yeah, guilty as charged. It's what I get for not taking a bit more time to assemble my list.:) I should've at least included ocaml and Haskell in that list, in order to illustrate how broad such a definition (that would include statically typed languages) would be. And C# was an even poorer choice... I assumed that they were only adding support for compile-time type inference, but apparently they'll also be adding the ability to weaken compile-time type checking while relying on the run-time to catch errors, so C# will, in fact, be getting what I think of as true "duck typing" features.
Since a cast to anything but the original pointer type (with a few exceptions, such as char* to get raw bytes) is U.B., such casting doesn't give you a mechanism to say "do X" on an object of an uncertain type, and have it done so long as "X" is somehow supported for the object (again, with a few edge cases, such as X being "copy all bytes constituting the object")
Sure it does. Glib and Gtk build an entire polymorphic object model based on the fact that you can a) store function pointers in a struct, and b) cast one arbitrary pointer to another. The result is that, so long as your structs are laid out properly, you can polymorphically dispatch methods on types.
So, I suppose it's more accurate to say that C along with some sort of appropriately built library allows C to operate in a duck-typed fashion. But I maintain that, at that point, the term is meaningless.
Still, if "f" in the example here doesn't use duck typing, then I don't know what the hell duck typing is supposed to be.
But, you said it yourself. It's not duck typing, it's compile-time type inference.
Duck typing, at least in my mind, is the idea that, in a given block of code, I, nor the compiler, care what the type of a given variable is. I just call a method on it, and it'll either work, because the object supports the method/message, or it won't. ie, it'll either quack like a duck or it won't.
But if you're doing static type inference, the compiler *knows* whether or not the thing is a duck, and will tell you if it isn't (and fail to compile). This is a very different thing. In this case, all the types exist, everywhere, but because of type inference, they just aren't annotated. But with "duck typing", the types are discovered at run time, and method dispatch occurs at that point (in a static language with type inference, the binding will happen at link time, since the compiler will know exactly which method to call).
So, no, I disagree, what you described is *not* duck typing. It looks similar, in that the developer doesn't have to worry about being explicit with types, but deep down they're very different things.
So, I guess the real question is: is duck typing a description of a mechanism (dynamic typing + dispatch), or is it just a generalized philosophy. If it's the latter, then any language that supports type inference, statically or dynamically, strong or weak, can lay claim to it. That includes Python, Ruby, Perl, Javascript, C# 4.0... heck, even regular ol' C with run-time type casting can claim to be "duck typed", as you can freely cast a void* to anything you want, and it might or might not work as you expect. 'course, at that point, the term has lost all meaning.
Well, many type errors are discovered at compile time. Unfortunately, static typing tends to have the side effect of requiring more complex code, and often has to be worked around.
Not at all. Take Haskell, for example. It is, without a doubt, the strongest typed language I've ever seen, and has a rather interesting type system. But thanks to type inference, it can figure out most of the details at compile time, which means that you rarely have to do type annotations (although developers typically do, as it aids in readability).
As an aside, C# will be including some level of type inference in version 4, which should make it's functional features far less onerous to use (anyone who's made heavy use of anonymous delegates knows what I'm talking about).
Dynamic dispatch is what for example virtual methods (or multimethods) do, where which version of the code gets called depends on the types of the arguments.
Uh, no. That's just multimethod dispatch. Dynamic dispatch is what makes polymorphism possible. Specifically, it's the binding of a method call to an object at runtime (for example, in C++, this is done with vtables). But, you are correct, in that I wasn't being precise enough (see below).
Duck typing is where instead of you telling the compiler what types of arguments are allowed, it either figures it out entirely on its own (ocaml, I think) or just checks at runtime instead (dynamic languages).
Yes yes, I know, I was being too simplistic (I realized this after I hit submit). Duck typing == dynamic dispatch *and* dynamic typing. Either way, "duck typing" is a stupid marketing term, nothing more.
And, BTW, duck typing is *not* the same as type inference, which is what you see in ocaml and Haskell.
First, 'duck typing' is actually a reasonably-standard term.
Only since Python and particularly Ruby fans started using it as a way to market a feature in their pet language (dynamic typing coupled with dynamic dispatch) that's been available in existing languages for *many* years. It's a marketing term, nothing more. It adds nothing to the actual discussion, other than to sound all neat and cutsey.
I would define it as "the operations your object supports are not defined a priori".
And I would define it as dynamic typing and binding. Nothing more. The language determines, at run time, how to bind a method call to an object. It's just that simple.
A language like Smalltalk or Python or Ruby doesn't have class definitions in the same way as Java and C++ do
Of course they do. Every single language you listed is strongly typed. The only difference is that Smalltalk, Python, and Ruby are dynamically typed, while Java and C++ are statically typed. That's it.
C++ templates are duck typing -- they're just compile-time duck typing.
"compile-time duck typing" is, by definition, a contradiction. Duck typing specifically necessitates binding at runtime. You have an instance of an object, and a method call directed at it, and the compiler doesn't bind that call until it actually occurs, at which point the runtime figures out how to dispatch the call.
Templates, on the other hand, are realized at compile time. The template arguments are applied to the type, and new code is generate which represents the realized template. That template is then compiled, and the method calls are type checked and linked at compile time. It's a fundamentally different operation.
But there is nowhere that interface is actually specified; it's implicit in the function.
And that's a *bad thing*. Because if the object doesn't support the method, the compile will generate the templated code, the code will fail to compile, and the compiler will emit an exceptionally cryptic error. This is the whole reason Concepts were invented: it allows the developer to be explicit about what the template expects from it's arguments, so that when the compile fails, the compiler can do a much better job explaining what, exactly, went wrong.
But again, the key is, all this is happening at compile time before the code ever runs. It's completely different from what you like to call "duck typing".
By contrast, you can have dynamic dispatch in a statically-typed language.
Correct. And as such, you're right, my original post wasn't accurate. What I should've said is that duck typing == dynamic dispatch + dynamic typing. Either way, it's hardly a new idea. And it's an idea that does *not* fit in a language that's meant to be strongly, statically typed (eg, C++).
Templates are what Python calls 'duck typing'. ("If it looks like a duck and quacks like a duck...")
First, what you young bucks like to call 'duck typing', as cutesy as that sounds, the computing science world calls 'dynamic dispatch'. And it's hardly a new concept (see Smalltalk for a classic example). But, hey, what's old is new and shiny again, right?
Second, dynamic dispatch specifically happens at runtime. Templates, on the other hand, are realized at compile time, as are any method calls made against a templated class. As such, the two concepts are entirely different, both from a conceptual and an implementation standpoint.
Meh, so's caffeine. Which is, as it happens, why it's sometimes prescribed when dealing with headaches, and why it's included in drugs like Motrin ('course, no one knows *why* vasoconstriction cures some headaches, but... *shrug*).
Honestly, as long as you don't already suffer from high blood pressure, vasoconstriction is likely not a big concern.
Actually, I'd wager the primary use of marketing is good ol' fashioned brand recognition. ie, I, Mr. Consumer, go to the store and need to find a brand of toilet paper. Fortunately for company X, I saw their commercial yesterday, and so recognizing the brand, I pick it, even if it isn't necessarily the best or cheapest.
I'll wait until the patent filings or grants are published, as the "citation" in that Wikipedia article is a claim on a blog entry. Not exactly air-tight.:)
Well, apparently I either have a stalker, or someone *really* doesn't want people to know that the ribbon can be collapsed, thus making it far less craptacular...
Not to mention the fact that the ribbon takes up so much more screen real estate than menus.
Then double-click on it to set it to autohide. Voila, all your ribbony goodness, taking up the same screen real-estate as a normal menu strip, but without all those annoying office toolbars.
I just got a new laptop at work, and it has Office 2007, replacing the 2003 that was on the old one. The only thing that makes it at all tolerable is that my new screen is 900 pixels high instead of 768, so most of the space that the ribbon's burning up is new pixels
So double-click on the damn ribbon. Voila, the ribbon autohides. Suddenly Word, et al, take up even *less* space than before (thanks to the absence of toolbars).
Uh, actually, I'm not sure it can. Unless they have a patent in the patent office that's issued or filed, they can't go and retroactively patent an invention. And if the patent was issued, we'd know (it'd be published), and if it was filed, it would've been published a year after filing (unless MS was willing to give up the opportunity to file the patent overseas).
2. Encourage rivals to charge also (it has been already flagged that newspapers are willing to work as a bloc on this issue).
I find this particularly interesting. Last I checked, if a large portion of an industry gets together and agrees on minimum pricing (in this case >0), that's called "collusion", and it's very much illegal.
So why are newspapers seemingly getting a free pass?
Slashdot Mirror
Most of us working in some sort of tech related job are working more than 40 hours per week
Huh, we are? Funny, 'cuz I'm not. Nor is anyone I know. Maybe the submitter just needs to get a less crappy job?
Quite often, actually. Or do you not need access to the same content from work and home? Or at a friend's or relative's place? Or on your spouse's laptop because you don't want to grab yours?
And that's assuming what I'm doing is so sensitive that I feel the need to be that paranoid. And given that rule doesn't apply to email (yes, that's right, email... it already travels via SMTP in cleartext, so if you're that paranoid, you should be encrypting anyway), anything I do with google docs, bookmarks, and so forth, most of the time, it's just not a big deal.
The only reason webmail is popular is that people do not like taking the time to configure an email program to connect to their POP3/IMAP server.
Really? Funny. The reason *I* use webmail is because it's available any place where there's Internet access. That's also, as it happens, the same reason I use a service for storing bookmarks (del.icio.us), personal information/notes/etc (a private wiki), some small docs/spreadsheets (Google apps), and so forth.
The idea behind a network, any network, is to enable collaboration.
That's just ridiculous. Or have you never heard of a mainframe?
The idea behind a network, any network, is to ship information from point A to point B. That could be data from person A to person B over some sort of collaborative software suite. OR, it could be an application from server A to thin client B, so that B doesn't have to have all those apps installed locally, thus resulting in lower deployment and upgrade costs, cheaper hardware, and so forth.
In short: the Internet does not, in fact, conform to your limited personal view of it. Get over it.
If a language provides a small and mutually orthogonal set of powerful constructs which fit well together, people tend not to have to invent their own meta-programming systems to get things done.
And yet the power of Lisp, Haskell, and Smalltalk, three incredibly elegant languages, is in the ability of the developer to build their own "meta-programming systems". Lisp has it's incredibly powerful macro system, allowing for things like the CLOS. Haskell has it's system of monads which allows things like Monadic parsers and so forth, allowing for incredibly powerful embedded sub-languages for accomplishing tasks. And Smalltalk doesn't even have an 'if' or 'while' statement, instead encouraging flow control and other constructs to be built into the class library. Meanwhile, all three languages allow one to mix programming models freely (Lisp and Smalltalk both support OOP, functional, and procedural development, while Haskell has superb support for pure, lazy, functional development while allowing one to "package up" procedural code in safe little lockboxes where it's needed).
So, just looking at that list, I wonder if it's maybe *you* that has the problem, rather than Javascript? I mean, Javascript is really just Self for the web, and Self is just Smalltalk without classes, so if you've got a problem with Javascript, then I can think of very few languages that would satisfy your (incredibly unreasonable, overly picky/anal/restrictive) requirements.
Frankly, I think Javascript's biggest problem is that, unlike Lisp, Haskell, Smalltalk, Ruby, Perl, or Python, JS doesn't have a strong core community that can help provide guidance and dictate standards for development. While all those languages provide a wide array of tools for getting any particular job done (with Perl at the most extreme end), all have communities whose output includes a standardized set of libraries, tools, and documentation, along with coding guidelines and traditions that can help guide new members of the community. And I strongly suspect Javascript lacks such a community because the growth in popularity of the language has been haphazard, and out of necessity, rather than because a core group was driving it's adoption. And I don't see that changing any time soon, unfortunately.
but why do we think "oh, it's the client-side. Let's go back to (essentially) Basic for programming."
If, by "Basic", you mean a prototype-based object oriented, functional programming language. :rollseyes:
Indeed. Last I checked, software didn't suffer from random bitrot (well, save for cosmic rays and failing disks). It either works, or it doesn't.
You seem actively bitter about the possibility of forks while explicitly choosing a license that not only allows them, but makes it so simple that it basically encourages them.
Actually, I think it goes deeper than that.
Most people don't *want* to fork projects. Your average contributor is a career developer who's probably being paid to do something else entirely, and only contributed to the project because they needed some functionality to get their job done. Alternatively, they're hobbyists, in which case taking on the responsibility of maintaining a fork isn't something most people are interested in.
Instead, the reason forks happen is because the maintainer is, for some reason, hostile to the wishes of some not-insubstantial portion of their user base. In this particular case, it appears the OP is actively *annoyed* by people requesting features. Well, big surprise that, in such a situation, people are likely to fork your codebase: given the option between maintaining your own fork or dealing with a hostile maintainer, forking is obviously the best solution. And so the OP, rather than, say, being less hostile to and more cooperative with his user base, chose to simply take his ball and go home.
Fundamentally, it's an attitude problem: some people see software development, and OSS in general, as a collaborative process, and enjoy working with others, accepting contributions, etc. Others, however, see users and potential contributors as a nuisance and something to avoid. Big surprise if the latter group choose to obviate OSS in favour of a closed development model.
I used to open-source everything I do. No more. My current project is closed-source (but free) application. While there are quite a few users, very few butt in with "extensions" that they feel absolutely must be there.
Great, so in a case like this, where a user created valuable new functionality, you wouldn't benefit. Instead, you'd be stuck doing the work, or refusing to do so, in which case you'd lose a customer who'd be forced to move to a different product, instead.
Basically, rather than ignoring useful patches, you now have to ignore users requesting useful features, who then just move on when you say 'no'. Yeah... that's much better.
No forking either - you don't get to take the results of my work, add a few things and distribute, creating confusion and incompatibility, which lead users to other products all together and hurt me (I don't care about the other guy).
How is that a product of being OSS? The issue, here, is very simple: a maintainer that's either non-responsive or MIA. If the maintainer were responsive, the changes would be added to the existing product, and everyone would be happy: the originator wouldn't have to maintain a separate tree, the maintainer wouldn't have to write the code themselves, and the other users would benefit.
In fact, in this particular case, closing the source only does one thing: fucks the customer, as they're now forced to find something else, since they can't just take the code and alter it as they see fit.
Now with a closed-source application, no such thing and quite a bit of feedback begins with "thank you for the great product"
I'm sorry, but I have to call "bullshit", here. Whether or not you get feature requests has absolutely *nothing* to do with the license the source code is under. Either way, you have users with ideas about how the product should work. The only difference is that, in the case of closed source, the user can't just contribute code back to you. Instead, they have to wait for you to decide their idea is worth implementing (and then live with whatever implementation you come up with). That sounds like a lose-lose proposition to me.
Since "duck typing" is not a well-defined term, I guess we'll have to just agree to disagree.
Well, Wikipedia seems to think it's reasonably well defined. Here's what the consensus says (obviously I'm going to abbreviate, here, but you can see it for yourself):
Obviously, what's described above can't possibly work in a statically typed language, inferred or otherwise, as the types of the parameters for the function are well known and enforced at compile time. In fact, the definition goes on to say:
And:
Given that, I really don't see how Haskell, OCaml, or C++ (templated or otherwise) can possibly be considered "duck typed".
It's a curious listing, but I don't really understand why you wouldn't consider the listed languages to be duck-typed even under your, stricter definition (of dynamic typing + dispatch). Or am I missing something?
Yeah, guilty as charged. It's what I get for not taking a bit more time to assemble my list. :) I should've at least included ocaml and Haskell in that list, in order to illustrate how broad such a definition (that would include statically typed languages) would be. And C# was an even poorer choice... I assumed that they were only adding support for compile-time type inference, but apparently they'll also be adding the ability to weaken compile-time type checking while relying on the run-time to catch errors, so C# will, in fact, be getting what I think of as true "duck typing" features.
Since a cast to anything but the original pointer type (with a few exceptions, such as char* to get raw bytes) is U.B., such casting doesn't give you a mechanism to say "do X" on an object of an uncertain type, and have it done so long as "X" is somehow supported for the object (again, with a few edge cases, such as X being "copy all bytes constituting the object")
Sure it does. Glib and Gtk build an entire polymorphic object model based on the fact that you can a) store function pointers in a struct, and b) cast one arbitrary pointer to another. The result is that, so long as your structs are laid out properly, you can polymorphically dispatch methods on types.
So, I suppose it's more accurate to say that C along with some sort of appropriately built library allows C to operate in a duck-typed fashion. But I maintain that, at that point, the term is meaningless.
Still, if "f" in the example here doesn't use duck typing, then I don't know what the hell duck typing is supposed to be.
But, you said it yourself. It's not duck typing, it's compile-time type inference.
Duck typing, at least in my mind, is the idea that, in a given block of code, I, nor the compiler, care what the type of a given variable is. I just call a method on it, and it'll either work, because the object supports the method/message, or it won't. ie, it'll either quack like a duck or it won't.
But if you're doing static type inference, the compiler *knows* whether or not the thing is a duck, and will tell you if it isn't (and fail to compile). This is a very different thing. In this case, all the types exist, everywhere, but because of type inference, they just aren't annotated. But with "duck typing", the types are discovered at run time, and method dispatch occurs at that point (in a static language with type inference, the binding will happen at link time, since the compiler will know exactly which method to call).
So, no, I disagree, what you described is *not* duck typing. It looks similar, in that the developer doesn't have to worry about being explicit with types, but deep down they're very different things.
So, I guess the real question is: is duck typing a description of a mechanism (dynamic typing + dispatch), or is it just a generalized philosophy. If it's the latter, then any language that supports type inference, statically or dynamically, strong or weak, can lay claim to it. That includes Python, Ruby, Perl, Javascript, C# 4.0... heck, even regular ol' C with run-time type casting can claim to be "duck typed", as you can freely cast a void* to anything you want, and it might or might not work as you expect. 'course, at that point, the term has lost all meaning.
Well, many type errors are discovered at compile time. Unfortunately, static typing tends to have the side effect of requiring more complex code, and often has to be worked around.
Not at all. Take Haskell, for example. It is, without a doubt, the strongest typed language I've ever seen, and has a rather interesting type system. But thanks to type inference, it can figure out most of the details at compile time, which means that you rarely have to do type annotations (although developers typically do, as it aids in readability).
As an aside, C# will be including some level of type inference in version 4, which should make it's functional features far less onerous to use (anyone who's made heavy use of anonymous delegates knows what I'm talking about).
Dynamic dispatch is what for example virtual methods (or multimethods) do, where which version of the code gets called depends on the types of the arguments.
Uh, no. That's just multimethod dispatch. Dynamic dispatch is what makes polymorphism possible. Specifically, it's the binding of a method call to an object at runtime (for example, in C++, this is done with vtables). But, you are correct, in that I wasn't being precise enough (see below).
Duck typing is where instead of you telling the compiler what types of arguments are allowed, it either figures it out entirely on its own (ocaml, I think) or just checks at runtime instead (dynamic languages).
Yes yes, I know, I was being too simplistic (I realized this after I hit submit). Duck typing == dynamic dispatch *and* dynamic typing. Either way, "duck typing" is a stupid marketing term, nothing more.
And, BTW, duck typing is *not* the same as type inference, which is what you see in ocaml and Haskell.
First, 'duck typing' is actually a reasonably-standard term.
Only since Python and particularly Ruby fans started using it as a way to market a feature in their pet language (dynamic typing coupled with dynamic dispatch) that's been available in existing languages for *many* years. It's a marketing term, nothing more. It adds nothing to the actual discussion, other than to sound all neat and cutsey.
I would define it as "the operations your object supports are not defined a priori".
And I would define it as dynamic typing and binding. Nothing more. The language determines, at run time, how to bind a method call to an object. It's just that simple.
A language like Smalltalk or Python or Ruby doesn't have class definitions in the same way as Java and C++ do
Of course they do. Every single language you listed is strongly typed. The only difference is that Smalltalk, Python, and Ruby are dynamically typed, while Java and C++ are statically typed. That's it.
C++ templates are duck typing -- they're just compile-time duck typing.
"compile-time duck typing" is, by definition, a contradiction. Duck typing specifically necessitates binding at runtime. You have an instance of an object, and a method call directed at it, and the compiler doesn't bind that call until it actually occurs, at which point the runtime figures out how to dispatch the call.
Templates, on the other hand, are realized at compile time. The template arguments are applied to the type, and new code is generate which represents the realized template. That template is then compiled, and the method calls are type checked and linked at compile time. It's a fundamentally different operation.
But there is nowhere that interface is actually specified; it's implicit in the function.
And that's a *bad thing*. Because if the object doesn't support the method, the compile will generate the templated code, the code will fail to compile, and the compiler will emit an exceptionally cryptic error. This is the whole reason Concepts were invented: it allows the developer to be explicit about what the template expects from it's arguments, so that when the compile fails, the compiler can do a much better job explaining what, exactly, went wrong.
But again, the key is, all this is happening at compile time before the code ever runs. It's completely different from what you like to call "duck typing".
By contrast, you can have dynamic dispatch in a statically-typed language.
Correct. And as such, you're right, my original post wasn't accurate. What I should've said is that duck typing == dynamic dispatch + dynamic typing. Either way, it's hardly a new idea. And it's an idea that does *not* fit in a language that's meant to be strongly, statically typed (eg, C++).
Templates are what Python calls 'duck typing'. ("If it looks like a duck and quacks like a duck...")
First, what you young bucks like to call 'duck typing', as cutesy as that sounds, the computing science world calls 'dynamic dispatch'. And it's hardly a new concept (see Smalltalk for a classic example). But, hey, what's old is new and shiny again, right?
Second, dynamic dispatch specifically happens at runtime. Templates, on the other hand, are realized at compile time, as are any method calls made against a templated class. As such, the two concepts are entirely different, both from a conceptual and an implementation standpoint.
Meh, so's caffeine. Which is, as it happens, why it's sometimes prescribed when dealing with headaches, and why it's included in drugs like Motrin ('course, no one knows *why* vasoconstriction cures some headaches, but... *shrug*).
Honestly, as long as you don't already suffer from high blood pressure, vasoconstriction is likely not a big concern.
Actually, I'd wager the primary use of marketing is good ol' fashioned brand recognition. ie, I, Mr. Consumer, go to the store and need to find a brand of toilet paper. Fortunately for company X, I saw their commercial yesterday, and so recognizing the brand, I pick it, even if it isn't necessarily the best or cheapest.
At least, that's the idea.
Meh, just click the 'Print' link, wherever it may be, and you're golden (the first thing I do when I hit a page like that is type '/print').
But, to be fair, the claims come from Chris Bryant, who's apparently part of the licensing program, so it's more than just baseless rumour...
Interesting, I guess we'll see how this pans out.
I'll wait until the patent filings or grants are published, as the "citation" in that Wikipedia article is a claim on a blog entry. Not exactly air-tight. :)
Well, apparently I either have a stalker, or someone *really* doesn't want people to know that the ribbon can be collapsed, thus making it far less craptacular...
Not to mention the fact that the ribbon takes up so much more screen real estate than menus.
Then double-click on it to set it to autohide. Voila, all your ribbony goodness, taking up the same screen real-estate as a normal menu strip, but without all those annoying office toolbars.
I just got a new laptop at work, and it has Office 2007, replacing the 2003 that was on the old one. The only thing that makes it at all tolerable is that my new screen is 900 pixels high instead of 768, so most of the space that the ribbon's burning up is new pixels
So double-click on the damn ribbon. Voila, the ribbon autohides. Suddenly Word, et al, take up even *less* space than before (thanks to the absence of toolbars).
Not yet, but that could change anytime.
Uh, actually, I'm not sure it can. Unless they have a patent in the patent office that's issued or filed, they can't go and retroactively patent an invention. And if the patent was issued, we'd know (it'd be published), and if it was filed, it would've been published a year after filing (unless MS was willing to give up the opportunity to file the patent overseas).
2. Encourage rivals to charge also (it has been already flagged that newspapers are willing to work as a bloc on this issue).
I find this particularly interesting. Last I checked, if a large portion of an industry gets together and agrees on minimum pricing (in this case >0), that's called "collusion", and it's very much illegal.
So why are newspapers seemingly getting a free pass?