News for hackers. Stuff that matters.
Re:The Code Documentation Fallacy by bookface on Thursday October 17, 2013 @01:20PM (#6566730)
Agreed completely about how awful dynamic languages can be in this respect. I've found what helps a lot is consistent naming of parameters. For example, numberOfWidgets (an integer) versus widgets (a collection) or file (a file handle) versus path (a string).
Re:The Code Documentation Fallacy by mercurial on Thursday October 17, 2013 @02:22PM (#6567186)
Sure, consistent naming helps a lot (though I'm partial to short-yet-readable alternative like widgetCounts). Sadly, sometimes ambiguity is unavoidable. And other times, you're just dealing with bad code.

But consistent naming does not help with the "optionality" of parameters.

Re:The Code Documentation Fallacy by acjohnson55 on Friday October 18, 2013 @01:08AM (#6569870)
In that sense, dynamic languages often have a jump on their functional counterparts. Relying on the type annotations for all documentation is probably the other side of the coin. I understand that generic combinators sometimes need sufficiently general argument names, but even then, there's often some semantic meaning that can be attached with a self-documenting variable name. Enough with the 1- and 2-letter variable names!