
Williams: Master of the "Come From" - ColinWright
https://github.com/raganwald/homoiconic/blob/master/2011/11/COMEFROM.md
======
dasil003
This is an illuminating example of how different assumptions lead to different
definitions of what makes good code. I'm convinced that this is one reason why
there is this belief that 80% of programmers are incompetent. It's not there
aren't truly incompetent devs out there, but it's also easy to assume someone
is incompetent just because they were working from different constraints and
experiences than you, and the way they did things just isn't immediately
apparent.

~~~
ericb
Having recently lead a round of interviewing, I wish that I could be convinced
that your kinder interpretation was true.

But under moderate questioning, most interviewees don't hold up well.

~~~
CGamesPlay
Interviewing is an inherently flawed way of determining skill. This manifests
itself in numerous ways; one of which is our inability to properly extrapolate
information from an interview: if a good programmer needs to search online for
information to solve a problem about once each 8-hour day, then during the
interview, the good programmer may ask for help once. But if they do that,
then the interviewer sees that they need to ask for help once every hour.
Alternatively, if they don't ask for help, the interviewer might be led to
believe that they don't use tools afforded to them. Because one cannot ask for
help 1/8th of a time, the interviewer has a negative impression of the
candidate regardless of the choice the interviewee makes. This sort of lose-
lose for the interviewer due to extrapolation can happen for many different
facets: anything that is necessary, but only in moderation.

Interviews are a very flawed system for identifying skill.

~~~
mikeash
An interview where the interviewer favors people who look at documentation
_less often_ is already deeply flawed. In my experience, the best programmers
spend the most time reading documentation, and the worst programmers are the
ones who never read docs and never ask questions.

I would never want to hire or work with someone who read docs only once a day.

~~~
CGamesPlay
Yes, totally. Once per day is a ridiculous figure. Let's say "less than one
time per interview-difficulty problem", and the numbers still hold.

~~~
mikeash
Do I understand you correctly that you're now saying that multiple times per
day is acceptable, but d/i times per day, where d is the length of the day and
i is the length of the interview, is unacceptable?

This is still nuts. There is literally _no_ amount of documentation checking
that is too much, as long as the guy produces results.

------
mey
I hate this coding style. It combines expert system knowledge with spooky
action at a distance, which means in anyone else's hands it will break and
delay development. Horizontal changes that aren't readily indicated in the
code paths that are effected are confusing. (One of the many reasons monkey
patching can be considered an anti-pattern)

I guess the longer I've worked with other developers, I prefer readability
first, test-ability second.

~~~
grncdr
I love this coding style, but I think you have a valid point. Python
decorators are a nice compromise in that they allow you to have cleanly
factored 'around' advice (which is strictly more powerful then 'before' and
'after') with the implementation defined elsewhere, but still requiring a
visible marker at the location the advice is used.

What would be ideal is a system that allowed you to define advice by monkey-
patching but indicated what advice was applied to a method at the site of it's
definition. As mentioned in this comment
<http://news.ycombinator.com/item?id=3246215>, I think we are bumping into a
limitation of what can be easily managed in "unstructured" (I would say
"dead") text files.

~~~
wladimir
_I think we are bumping into a limitation of what can be easily managed in
"unstructured" (I would say "dead") text files_

Yes, I think so too. There are many kinds of relations between entities that
we cannot specify just because "dead" text files make them hard to express.
Also, it makes that language "wars" focus on shallow concerns such as syntax,
instead of semantics.

It would be great to be able to put constraints and relations at the abstract
syntax tree level, or abstract semantic graph level (cross references and such
that are automatically updated if entities are moved/renamed).

IDEs sort-of work around this by parsing the code and trying to bolt on
features, by handing the "dead" text files intelligently. But all this work is
lost as soon as you close the editor, so it does not allow the programmer to
retain changes at this level.

But I'd love to work on a project that examines different, new ways to
represent source code. Which could aid static/dynamic code validation,
documentation, code comprehension, refactoring, cross-cutting concerns, and
would allow for rendering the source code in any style and syntax that the
developer wants.

Of course, this also would present challenges in the area of scm systems,
because those are really focused on 'dead' text files. One idea I've had is to
represent code as a graph, for example, in a graph database.

~~~
aidenn0
"It would be great to be able to put constraints and relations at the abstract
syntax tree level"

You mean like in LISP?

~~~
Semiapies
I think more having the modified AST feed back into the source code, or more
accurately, the human-readable view of the actual source code. Like the
comment example - imagine having the monkeypatch still in the comments module,
but when you open the WallPost class, you can see the "has_many :comments" and
a tag that takes you to the comments functionality.

Alternately, you can do the the reverse - someone writes the change in the
more traditional manner, but you can view - and edit - the change-set _as if
it were_ a module of monkey-patches isolating the relevant concerns. Or any
particular view of the program someone can think of that's useful.

I'd like to program like that.

ETA - Sorry for the accidental downvote; found a couple of your other comments
to upvote.

------
listrophy
Point this article to any hot-shot developer... if they don't come away with a
new smidgeon of self-doubt, slowly back away: he/she isn't worth working
alongside.

------
ilaksh
To me it looks like the increasing popularity of AOP and richer (or at least
more functional) syntax in languages like Ruby, the relative ubiquity of
property chaining and two-way data binding across different frameworks, is
moving towards a more semantic type of software specification where structures
and relationships are more important.

I think that's pretty obviously a good thing since it reduces the cyclomatic
complexity, coupling, amount of code, and increases reuse, although you can
obviously take it a little far when you are actually using a mostly imperative
paradigm.

I think this is one of the types of things that is going to (eventually
someday) finally wake people up to the limitations of unstructured (although
colorful) ASCII source editing.

~~~
buff-a
_I think this is one of the types of things that is going to (eventually
someday) finally wake people up to the limitations of unstructured (although
colorful) ASCII source editing._

This.

------
angelbob
This is cute. I had to Google to get the Williams / Jim Kelly thing from Enter
the Dragon.

An awesome article. Inspirational in the same way as Steve Yegge's Wizard
School bit (<http://steve-yegge.blogspot.com/2006/07/wizard-school.html>).

~~~
Harkins
The author is Reginald Braithwaite; the movie has a character named
Braithwaite who begins the plot. I wonder if this whole post is
autobiographical or if the Williams/Kelly is just an old joke and Braithwaite
is a coincidence.

------
headbiznatch
This nicely draws together several sub-currents of developer thought
pertaining to the "am I good at this?" current that all developers have. I
found myself bouncing back forth on some of the ideals, waiting to hear how it
all turned out for this developer... Basically the same feeling I get from a
good short story.

------
46Bit
Have to give the author (and Williams!) credit - that's a damned neat
developing style to my mind. As always, running into it when a client is
yelling down the phone would be painful, but it is interesting to consider.
Certainly it's a strange approach with virtues, unlike much of the beyond-
spaghetti you sometimes run into.

------
JonnieCache
The best thing in that article: this link
<http://en.wikipedia.org/wiki/COMEFROM>

Not that the rest of it wasn't great. I think I like this Williams guy. If I
could convince him to be a bit less dogmatic I reckon we'd get on.

------
sloafmaster
I wonder how much groveling he had to do to get his code to run...
<http://www.catb.org/~esr/intercal/stross.html>

