Hacker News Reader

Comment by mey | Hacker News Reader

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.

View on HN

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.

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.

I've been playing prototyping a completely unrelated project using graph databases, but that really gets me thinking... drop me an e-mail if you'd be interested on collaborating on something like this.

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

You mean like in LISP?

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.

Yes, like any modern high-level language it would use some concepts "borrowed" from LISP. Credit where credit due...

On the other hand I don't want to go completely bananas with the 'structureless' LISP. In my opinion at least it would aid comprehension to be mirror modern high-level languages. But you'll be able to choose Ruby or Python syntax-mode at will (or maybe even LISP-mode :-).

This is only true because our tools for reading and exploring source code suck. I mean, we still work at the "unit level" of code (i.e. files and functions, classes, what have you). If our development environments let us viscerally experience the relationships of these units (a systemic perspective) we'd be in much better shape.

I disagree. The dream of getting a higher level picture of code is pervasive. E.g. UML was born to do exactly that. However, our modules usually do not compose cleanly, so you cannot visualize them as connected black boxes.

One common followup argument is that functional programming is great for this, because pure functions can be treated as black boxes. Sorry, but the problem is on the algorithmic/business logic level, which cannot be solved by the choice of programming language/paradigm.

Example: Remove data from one database and put it into another one, transactionally. At any point in time any other process must see the data in exactly one of the two databases. You can not merge the databases into one.

The problem with your example is requirements are not that strict. You don't need to move data from DB1 -> DB2 within a single clock cycle. And if you did some systems would think they saw the same data in both systems due to latency and caching etc. Thus the compromise of using a hidden intermediary (or blocking DB access) is not only reasonable but necessarily.

For stuff like this the absolute worst case is you update one or more legacy systems. But, that's just part of the cost / benefit / risk analysis.

UML? I said 'viscerally experience' not 'be forced to gouge your eyes out'.

I joke of course. But wouldn't you find it weird if two hundred years from now we were still writing and reading code like we are today? If that were the case, I'd say we had done a shit job of developing development.

The only problem of monkey patching is that other modules might be affected. If module A monkey-patches module B, then module C might break. If we had a mechanism, which guarantees that C does not notice A's monkey-patching, it would be a super-useful decomposition method.

I disagree, as long as they have a consistent system of naming, you can find everything you need. Most of my problem comes from not being able to figure out how to moneypatch it instead of doing it the lazy and brute force way.

Reply on news.ycombinator.com