“Duck typing” etymology? [closed] - duck-typing

Is there a story behind the name ''duck typing'', I've heard ''if it looks like a duck, and sounds like a duck, let's call it a duck'' (or something like that), but why a duck? Why not ``if it looks like a _ and sounds like a _, let's call it a _''.
It sounds like a Flying Circus sketch, but I don't remember it. Is there a story behind the name?

Duck typing is a phrase borrowed from the much older "walk like a duck". The latter has been around far longer than the programming idea it describes. See answerbag.com

Alex is involved... ;)

This is not really a programming question, but my guess: Ducks walk funny and they quack. This is amusing enough to turn it into a figure of speech. :-)

Quoting Wikipedia's article on Duck Typing:
The name of the concept refers to the duck test, attributed to James
Whitcomb Riley, which may be phrased as follows: "When I see a
bird that walks like a duck and swims like a duck and quacks like a
duck, I call that bird a duck."
...and from the same page...
Alex Martelli made an early (2000) use of the term in a message
to the comp.lang.python newsgroup. He also highlighted
misunderstanding of the literal duck test, which may indicate that the
term was already in use:
"In other words, don't check whether it IS-a duck: check whether it
QUACKS-like-a duck, WALKS-like-a duck, etc, etc, depending on exactly
what subset of duck-like behaviour you need to play your
language-games with."

No, the analogy is that if a variable looks like an integer (for example), and acts as an integer, it must be an integer (type).
Duck typing means 'no explicit predeclaraction of type'.


Is there a human readable programming language? [closed]

I mean, is there a coded language with human style coding?
For example:
Create an object called MyVar and initialize it to 10;
Take MyVar and call MyMethod() with parameters. . .
I know it's not so useful, but it can be interesting to create such a grammar.
COBOL is a lot like that.
Another sample from Wikipedia:
Oddly enough though, despite its design to be readable as English, most programmers completely undermined this with bizarre naming conventions:
How about LOLCODE?
Simplicity itself!
Inform 7
Inform 7 is perhaps the language I feel is most appropriately designed in a human language fashion. It is quite application specific for writing adventure games.
It is based on rule-based semantics, where you write a lot of rules describing the relationship between objects and their location. For instance, the section below is an Inform 7 program:
"Hello Deductible" by "I.F. Author"
The story headline is "An Interactive Example".
The Living Room is a room. "A comfortably furnished living room."
The Kitchen is north of the Living Room.
The Front Door is south of the Living Room.
The Front Door is a door. The Front Door is closed and locked.
The insurance salesman is a man in the Living Room. The description is "An insurance salesman in a tacky polyester suit. He seems eager to speak to you." Understand "man" as the insurance salesman.
A briefcase is carried by the insurance salesman. The description is "A slightly worn, black briefcase." Understand "case" as the briefcase.
The insurance paperwork is in the briefcase. The description is "Page after page of small legalese." Understand "papers" or "documents" or "forms" as the paperwork.
Instead of listening to the insurance salesman:
say "The salesman bores you with a discussion of life insurance policies. From his briefcase he pulls some paperwork which he hands to you.";
move the insurance paperwork to the player.
Example cited from Wikipedia
AppleScript is pretty close to that, though that is obviously platform dependent.
Here's a script for opening iTunes and playing a playlist
tell application "iTunes"
play playlist "Party Shuffle"
end tell
Source: AppleScript Examples
Projects promoting programming in
"natural language" are intrinsically
doomed to fail.
-- Edsger W.Dijkstra, How do we tell truths that might hurt?
This was "the next big thing" around about the early 1980s and I spent much of my first couple of years as a a coder working in "NATURAL", which was the supposedly the best of the new crop of 4GLs (fourth generation languages) which were designed to make data access (in this case to an ADABAS database) human readable.
Of course it did absolutely nothing of the type. All we ended up with was verbose badly structured code. Both of these products are still around, but you've never heard of them, which sort of proves the what a dead end it was.
Actually at that period there appeared to be a general desire to move beyond 'programming' into some sort of 2001 inspired AI heaven. Oracle were really keen on code generation and I remember with some interest a product called 'the last one' that was being marketed to managers as a product that would automatically generate any program you wanted and make all your programming staff redundant. Seems not to have lived up to expectations ;-)
It's worth remembering to that SQL was originally marketed in some quarters as a way to allow management to directly query their data. I was even sent on a course to learn basic SQL (in a large national transport organization that ran on rails - the steel variety) where junior management types were included because they had plans to put basic query tools in their hands. What a disaster that was.
Maybe it might be different in 50 years, but at the current stage of play coding demands a certain clarity of thought and implementation which is best mediated through a dedicated syntax designed for those ends, not any approximation to a natural language which is unclear and ambiguous. The nearest approximation is possibly physics where the essence of the subject is in the mathematics used (think a programming language for physics) not verbose wordage.
I was forgetting, apart from COBOL there was also PL/1, sometime credited with allowing NASA to put a man on the moon it was just as verbose as COBOL and tried even harder to be 'Manager-readable'. Which is why no-one has really heard of it now either :-)
Chef! Anyone can read recipes right? Behold hello world!
72 g haricot beans
101 eggs
108 g lard
111 cups oil
32 zucchinis
119 ml water
114 g red salmon
100 g dijon mustard
33 potatoes
Put potatoes into the mixing bowl. Put dijon mustard into the mixing bowl.
Put lard into the mixing bowl. Put red salmon into the mixing bowl. Put oil into the mixing bowl.
Put water into the mixing bowl. Put zucchinis into the mixing bowl. Put oil into the mixing bowl.
Put lard into the mixing bowl. Put lard into the mixing bowl. Put eggs into the mixing bowl.
Put haricot beans into the mixing bowl. Liquefy contents of the mixing bowl.
Pour contents of the mixing bowl into the baking dish.
Sorry if it's not a serious answer, but this is way awesome. :-)
All languages are 'human readable'. :) How else would someone be able to create it? That being said, languages that support DSLs can be incredibly intuitive such as Boo.
Having a programming language read like a (verbose) normal language, would be like requiring people to converse all the time in legalese. All the extra verbiage just gets in the way.
An ideal programming language should have syntax that is as transparent as possible and let the concepts behind the program stand out. Obviously there is a trade off between having a quick learning curve and having minimal but obscure syntax (think Perl, or even K).
By creating a set of rules, it is possible to do logic programming in Prolog like this. You can build a grammar (or download one) for a particular domain, create a knowledge base and then query it. After defining your grammar you could do something like:
bob is a parent of tim.
mary is a parent of bob.
?- X is a grandparent of tim.
X = mary
?- jim is a parent of bob.
I see the Shakespeare programming language have yet to be mentioned.
These programs are coded to look like shakespear plays, the individial characters in the play being variables that can hold numbers and the various phrases in the play manipulate the characters and the number they hold. For instance, "Speak your mind" orders a character to output his value.
tell application "Finder"
set the percent_free to ¬
(((the free space of the startup disk) / (the capacity of the startup disk)) * 100) div 1
end tell
if the percent_free is less than 10 then
tell application (path to frontmost application as text)
display dialog "The startup disk has only " & the percent_free & ¬
" percent of its capacity available." & return & return & ¬
"Should this script continue?" with icon 1
end tell
end if
I can read C. That means it's human-readable(because I'm a human). It's just too terse for the average person. The general concept of programming languages is to maximize the information about how the computer should operate in a given line.
This is why Ruby is so popular; it maximizes the functionality in minimal text. English(or any other other natural language) is a pretty imprecise, low-information/character language.
In sum, it is: (i)done before and (ii)a known weaker idea.
This is actually a hot topic.
For starters - What is Human readable?
A Chinese-reader cannot read Russian and vice versa.
It you narrow your domain for example to Chinese pharmacists writing a perscription you could design a language around that. And that would be human readable.
Such as language would fall under a the umbrella of Domain Specific Languages.
SELECT name, address FROM customers WHERE region = 'Europe'
Yes. It's called COBOL, and people generally detest it.
Inform 7 is the most successful such system I've seen. It has two advantages over the cruder systems listed in other answers here: it's for a domain particularly appropriate for natural language (interactive fiction), and it does a fancier analysis of the input code based on more computational-linguistics lore, not just a conventional programming-language grammar that happens to use English words instead of braces, etc.
Perl, some people claim.
print "hello!" and open my $File, '<', $path or die "Couldn't open the file after saying hello!";
Do a google search for "natural language programming" and you'll find lots of information (including why this is a bad idea).
Clarity of Expression is important.
But Clarity of Thought is far, far more important.
HyperTalk and its descendant AppleScript were designed to be similar to the English language.
VB is as close as I can think of one:
If MyLife.Sucks Then MyLife.End Else MyLife.Continue
Sure, Erlang.
by_length(Lists) ->
F = fun(A,B) when is_list(A), is_list(B) ->
length(A) < length(B)
qsort(Lists, F).
qsort([], _)-> [];
qsort([Pivot|Rest], Smaller) ->
qsort([ X || X <- Rest, Smaller(X,Pivot)], Smaller)
++ [Pivot] ++
qsort([ Y ||Y <- Rest, not(Smaller(Y, Pivot))], Smaller).
I'm a human, it's a programming language, and I can read it. I don't know what any of it means, but I see a lot of English words in there, I think.
(Tongue firmly in cheek.)
DSLs can be very natural-looking. See this example created with MGrammar:
test "Searching google for watin"
goto "http://www.google.se"
type "watin" into "q"
click "btnG"
assert that text "WatiN Home" exists
assert that element "res" exists
COBOL was intended to be read by managers, and has "noise words" to make it more readable.
The funny thing is, it reads a bit like a verbose DSL.
Being more human-readable than most was one of the early selling points of Ada. I find it a silly argument these days, as any sufficently complex task in any language is going to require a competent practicioner to understand. However, it does beat the bejeezus out of C-syntax languages. Its dominant coding styles can enhance this effect too. For example, comparing loops in an if statement:
if Time_To_Loop then
for i in Some_Array loop
Some_Array(i) := i;
end loop;
end if;
if (timeToLoop != 0) {
for (int i=0;i<SOME_ARRAY_LENGTH;i++) {
someArray[i] = i;
The C code would look even worse if I used Hungarian notation like Microsoft, but I'm trying to be nice. :-)
Interesting question. Your question can be read as "Is there any programming language that is easily readable by humans?", OR ELSE as "Is there a human language that can be used for programming?". All the answers here have focused on the former, so let me try answering the latter.
Have you heard of Sanskrit? It is an ancient Indian language on which modern Indian languages like Hindi are based.
I've been hearing for years that it is precise and complete enough to be used, as it is, as a high-level language on a computer. Ofcourse, you need a compiler to convert Sanskrit instructions to machine language. I know the script & yes, it is precise (entirely phonetic so you never have to ask "how do you spell that"), but I don't know the grammer well enough.
This is completeley anecdotal, so I don't vouch for the accuracy of this. Just wanted to share what I know regarding this. :-)
I agree with the general consensus here. "Human readable" general purpose programming languages are mostly a bad idea, but human readable Domain Specific Languages are very worthwhile.
REBOL has a great system for creating DSLs.
It only has one statement: "you - write me a program to do x"
It's valid for all values of X and has the advantage that x doesn't have to be defined and can be changed after the program is written.
A commercial dialect is available called intern: development cost is lower but it isn't guaranteed to work
Cobol was kind of like that.

“ID” or “Id” on User Interface

The QA manager where I work just informed me there is a bug in my desktop app due to the sign-on prompt being "Operator Id" when it should be "Operator ID". Her argument being that "Id" refers to the ego portion of Freud's "psychic apparatus" and is not semantically correct.
Now being an anal engineer (AE) I of course had to go and lookup Id vs ID and from my cursory investigations (google) it seems ID is just as commonly used for Freud's ego as Id is.
So my reasoning would be that Id is a shortened version of "Identifier" and is more correct or at least more commonly used than ID which would typically indicate a two word abbreviation.
I could just change the UI but then I wouldn't be holding up my profession as an AE so I was wondering if there any best practices or references for this sort of thing that I could use to support my argument? Keeping in mind that this question relates to the user interface and not the source code where abbreviations and casing are a whole different branch of philosophy.
According to Merriam-Webster, the abbreviation is "ID". If it were a correct abbreviation, it would have to be "Id." with the period.
Personally, I use "Id". The compiler doesn't care but my eyes do. Compare:
GetIDByWhatever <-- looks terrible
GetIdByWhatever <-- oh so pretty!
Aesthetics is more important than grammar when it comes to code, always. (Update: 4 years later, I don't stand by this statement anymore)
The 'D' doesn't stand for anything, so I've always considered it an abbreviation, not an acronym - and therefore I too use 'Id', not 'ID'.
I don't know about your qa's reasoning - words can have more than one meaning - this is not unusual in English :)
But it looks like the common usage is actually 'ID' (right or wrong :P), which is probably the format your users would expect.
It's interesting that so many feel "Id" should be the way to go.
I feel "ID" is appropriate because it hints at how we pronounce it -- I.D. Also, when I read "Id" in a running sentence, I sometimes have to come back and read it again just to ensure it's not a typo for "is" or "it".
The QA manager's line of reasoning is silly. Lots of English words have multiple meanings. "Lead", "lead", "lead" (metal, be at the front of, or a connector).
I would just try to be consistent with the capitalization used elsewhere in the app.
As an UAUA (ultra-anal usability analyst), please use ID instead of Id.
Visually, it's more recognizable in English. Grammatically, "Id" is a word (rhymes with "squid") and the Freudian definition has been given above. We're never verbally asked to show "id", but "ID." I.D. is fine but passe, as the periods imply multiple words.
Just use ID, okay?
So, as a technical writer, this is an issue that comes up for me quite regularly when reviewing other people's work, whether it be programmers, BAs or other writers. Typically, id refers to ego as others have said before me and the accepted abbreviation for identification is ID, just because plenty of people don't know or understand the rule doesn't mean that they are correct (sorry to be blunt), mind you the rules for punctuation and spelling to a large degree are almost as changeable as fashion!
However, what no-one seems to have asked is, does your company have a standard? At the end of the day if your company has a style guide and they have covered this topic in that guide, you should follow the guide. If it is not covered, then may I suggest that you raise the issue with the person that maintains the guide and include any stakeholders in the conversation. Consistency is key here. If the company you work for doesn't have a style guide, then perhaps it is time to start one!
Hope this helps...
How would you say it if you were reading out loud? I'd pronounce the two letters. ID is correct, analogous with similar abbreviations such as TV. (No dots, please, as the letters don't stand for anything.)
When I'm dealing with abbreviations like this, I like to format them in small block capitals, but that's just a personal taste. Capitals, anyway.
(But I probably would continue to use Id in the code itself.)
User interface and code are very different beasts...
"ID" is the correct answer for a user interface.
In code, consistency is your friend. Whether you like it or not, go with what is already there elsewhere in the code. If it's not there, then read up and make a decision, or get with the team and work out a way to go that everyone can agree to. Consistency makes life so much easier.
There is a little OcD in all of us!
Anyway, the google style guide says this:
"ID: Not Id or id, except in string literals or enums. In some contexts, best to spell out as identifier or identification."
I'm going with that.
Microsoft is more vague, from what I could find.
as a short version of Identifier, I would use Id. Also ID it's freaky when you have functions like
Multiple capitals in domain terms are quite problematic with CamelCase, as they can produce ambiguities and therefore dishomogeneity in your interfaces and namings
I think its depend on the way we spell. We don't spell "it", but "ai-di". Id-ID is spell by two sounds, so people make the D in cap to avoid thinking id is a "word". Its more like a character symbol. I like the "ID" more, just because it's nicer.
I prefer Id because when used with other 2-letter text, it doesn't become a single all-caps word
Photovoltaics systems ... PVID (one word or 2?) PvId (much more clear).
ID = Idaho! Id = Freud! Let the OCD begin!

What is the meaning of “I cosay”?

Search the web for the phrase "I cosay". I run across this phrase being used from time to time by individuals in tech forums, but for the life of me, I cannot figure out what it means or how it makes sense in the context of the conversations where it is used.
Am I just way behind the times? New slang?
As far as I can tell from the contexts Google pulls up, it is a very poorly machine-translated form of "codigo". "digo" or some variant is "I say", so it forms it as "I cosay" when it really shouldn't be translated at all. Roughly translated it should probably be "code" or "encoding".
It's pig latin for Psycho.
Without context, I'll have to say a cosay is the counter-say in the same vein that cosine is a counter to sine.
from the context of usage it looks like slang for agreement - you say X and I cosay X - possibly invented by non-native english speakers - but that does not cover all of the contexts of usage...
In french from Quebec (not France) it means : "I do not understand what you are talking about, can you repeat?" but it's a very low level of language... nothing official and shouldn't be used ... often kid use that type of expression...

How does Alexa's conversation flow work?

I want to write a quiz/interview game where the flow is like this:
"Alexa, start Movie Trivia."
Welcome to Movie Trivia. Do you need to hear the rules?
What category would you like to play? Comedy, drama, or animation?
Question 1. In what year was Star Wars released? A, 1970. B, 1977. C, 1980.
Correct. Your score is 1. Question 2...
I managed to write spaghetti code to accomplish this, with lots of if session.attributes.category, if session.attributes.needsRules, etc stuff, 3 pages of nested if-elsing.
I'm using Node and the official Alexa SDK, so I read its documentation cover to cover, but it's quite confusing and broken in places (examples that haven't worked since June, instructions for old UIs and so on). My question is: what kind of flow is 'correct'/traditional for something like this?
In the code I was writing, I used elicitSlot a lot, which is nice because it lets me listen solely for the things I expect to hear (eg answerType "A", "B", "C"). But elicitSlot leads to you re-triggering the same intent. So would it be a matter of having each intent check if a slot is filled, and if not, speak a question and elicit that slot, and if so, set a session attribute and then forward to a different intent?
That seems sloppy. Maybe the solution is to define an askingRulesState, askingCategoryState, askingQuestionState, etc, each with only a single handler. But states with only a single handler seems... wrong?
If I'm going to ask the user a question like "What category would you like to play?", does that mean I need to create a SetCategoryIntent? And if so, how would I prevent the user from triggering that intent except when I want them to?
I realise this is a bit of a big vague question but it's really difficult for me to boil it down to something smaller and clearer, since my issue is that the flow in general is really disorienting to me. I'd appreciate even the smallest tip!
You might have a look here, this will handle a lot of the if else's and elicit slots you wrote. For the questions and such you wil indeed probably have to make a state so you can check if you are in question asking state or just in the set-up state. This will help your skill deter men what it has to do. (don't forget to ALWAYS put this state back in because Alexa is tricky if you do not do this sometimes. You can find more info over here. This also looks like a pretty good example of what you are trying to make.
Hope this helps you forward a bit.

What question(s) does an object's behavior answer?

Reading a book I have found the following statement:
(Object) Behaviors answer either of two questions: What does this object do (for me)? or What can I do to this object? In the case of an orange, it doesn’t do a whole lot, but we can do things to it. One behavior is that it can be eaten.
In my understanding of object behaviour the statement above is correct regarding the first question and is incorrect in case of the second. However, I often see classes with methods like Orange::eat(), and this makes me uncertain about my design skills. So I would like to ask is it a design mistake to give oranges a behaviour eat? (oranges and eat are used just for example)
I think there's nothing wrong with your way of thinking about objects and their responsibilities. Orange::eat() would make sense if oranges had mouths. Otherwise, it's an Animal who is doing the eating.
The thing of the matter is, SVO (Subject-Verb-Object) sentences aren't always the best way to describe something, but OOP seems to be heavily biased towards that kind of statement so we frequently run into strange, unnatural and abstract sentence constructions in code.
Lets take classic Employee sample. "What can I do for this object" means:
void SetSalary(int value);
Eating an orange is not orange method, it is Person method:
void Eat(Orange& orange);
An orange can do things, for example, give rize to new orange trees. You are right, oranges can't eat anything, so it would make sense to have whatever is eating the orange have the eat method.
With this obvious example the answer is easy but it gets more complex in real life scenarios, you could take a look at Agile Principles, Patterns, and Practices in C# by Robert Martin. To go though a few scenarios and understand who gets to do what etc.