Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Dynamic Def – abusing Ruby's def statement

weblog.jamisbuck.org

Post reply on HN
Print view View original

81–87 of 87 posts

Re: The Dynamic Def – abusing Ruby's def statement

#81

Post by girvo »

TeMPOraL wrote: post #74
girvo wrote: post #73

Earlier quoted context omitted.

Right. Once you understand how to use run-time tooling, debugging dynamic languages becomes rather straightforward.

True. You have to learn to treat programs written in dynamic languages as living, mutable, interactive things instead of designs set in stone. However, when a simple syntax derails your reading, it is a thing of concern. Then again, you could make similar shenanigans in Common Lisp with `symbol-macrolet', but it's obscure feature that pretty much by definition will be used only by people who know when to use it :).

> However, when a simple syntax derails your reading, it is a thing of concern.

Definitely agreed! It's rare that I've come across a set of code that is _so_ over-abstracted or dynamic that reading the code doesn't usually shed light on the issue I'm after, and usually it's a "dense" language (Scala, Lisps, etc.) that manages to achieve that.

Re: The Dynamic Def – abusing Ruby's def statement

#82

Post by anamexis »

msbarnett wrote: post #69
blt wrote: post #36

Earlier quoted context omitted.

Ehh, there are good and bad uses. Yes, dot product should not be overloaded asterisk operator because elementwise multiplication of vectors is a thing, and also if you overload multiplication for matrices then dot product should be u-transpose-times-v for consistency. But what about vector addition? There's no ambiguity. Try writing any 3d graphics code without overloaded vector addition. It sucks. I generally disagr…

> Edit: I do think it's stupid to make the identity-equals operator overloadable. Identity-equals and value-equals are separate concepts. In C++ this isn't an issue because == is the value-equals operator. In Ruby, == is value-equals at well (identity-equality being such a rarely needed concept in Ruby that it wouldn't make sense to privilege it with its own operator). Identity equality in Ruby is provided by: a.obje…

For identity equality, there's also `Object#equal?`.

http://ruby-doc.org/core-2.2.3/Object.html#method-i-eql-3F

Re: The Dynamic Def – abusing Ruby's def statement

#83

Post by TeMPOraL »

girvo wrote: post #81
TeMPOraL wrote: post #74

Earlier quoted context omitted.

True. You have to learn to treat programs written in dynamic languages as living, mutable, interactive things instead of designs set in stone. However, when a simple syntax derails your reading, it is a thing of concern. Then again, you could make similar shenanigans in Common Lisp with `symbol-macrolet', but it's obscure feature that pretty much by definition will be used only by people who know when to use it :).

> However, when a simple syntax derails your reading, it is a thing of concern. Definitely agreed! It's rare that I've come across a set of code that is _so_ over-abstracted or dynamic that reading the code doesn't usually shed light on the issue I'm after, and usually it's a "dense" language (Scala, Lisps, etc.) that manages to achieve that.

Last time I was really, seriously confused about the code was when going through a Scala codebase written by a person deep in love with traits. My problem was less of the syntax or "denseness" and more of nonlocality - every conceptually "whole" algorithm was split into 10 or 20 files and 2 class hierarchies, each having their own hierarchy of traits.

It made some sense in the end, but it took me a lot of time to figure that one out - not because it was complicated, but didn't fit in my head. That the original author was uncooperative and didn't want to explain things too much didn't help either.

Re: The Dynamic Def – abusing Ruby's def statement

#84

Post by TeMPOraL »

derefr wrote: post #79
TeMPOraL wrote: post #72

Earlier quoted context omitted.

> People who say Erlang is a functional language are looking on the wrong level of abstraction. Processes are objects! People thinking those two are mutually exclusive are not getting the difference between the map and the territory :). I worked a bit with Erlang professionally. Erlang is both functional and object-oriented, if you think about Smalltalk-style OOP and not Java-style OOP (the constant confusion between…

> Yes, you could program treating everything like a web startup, but few simple assumptions like "this is inside my program so it responds fast and lives as long as the rest of the program does" can help tremendously improve the speed of coding and the speed of the program itself. I think the distinction between regular Smalltalk OOP (designed before distributed programming was a thing) and what people actually mean…

A side point here is that it's incredibly hard to make people stick to abstractions when not sticking to them gives a competitive edge.

Say we've implemented your entire idea with JIT-optimized message passing. What would happen there is people learning ins and outs of particular JIT implementation and JIT-hacking being a required topic on job interview, just like today knowing millions of ways of hacking CPU cache is something expected from a professional (non-web) programmer (web programmers are expected to know there is something called 'processor' and that it doesn't like nested for loops; source - was a professional web programmer).

Anyway, while OTP does a pretty good job of papering over some of the local/remote objects difference and helps you keep the whole thing running even if something external breaks, I think it would be cool to go further in the direction of the ideas you just described.

Re: The Dynamic Def – abusing Ruby's def statement

#86

Post by JoeAltmaier »

TeMPOraL wrote: post #61
icebraining wrote: post #25

Earlier quoted context omitted.

I disagree, operator overloading often makes the code much more readable. I don't see the problem unless you're trying to write C in Ruby. As long as the overloaded implementation keeps the expected semantics as described in the language documentation, it's fine.

Most problems people have with operator overloading seem to be caused by the same issue that makes them whine about "debugging metaprogramming" (I referenced that in other comment here). Namely, instead of trying to understand the code and the model behind it, they try to bring over their own assumptions about how the code should work. That 5-component object compared by ==? How does it work? Sit down, read the code…

That's exactly the issue. When its a small program that works fine. A large one? Its a matter of time and effort. Anything can be looked into, with time. Which is money. And effort over time ~mistakes.

Its too simple to do victim-blaming here. You don't understand my code? Well, just read it all so you know how clever I was.

If you want to write code that can be easily assimilated, which most readers would think they understood from its source and not by reading it at some meta-level, then you have to code with one hand behind your back.

Re: The Dynamic Def – abusing Ruby's def statement

#87

Post by JoeAltmaier »

lispm wrote: post #67
JoeAltmaier wrote: post #11

Earlier quoted context omitted.

Without explicit comments/documentation it is hard to imagine a good example. Its a longstanding issue. Even Lisp has 'equals' and 'equals?' which is an abomination. One looks for identity of object; the other for identity of value (if I understand it right). These kind of things are bug factories.

Lisp does not have 'equals' and 'equals?'. Lisp has 'eq', which is for object identity. Lisp has 'equal' which checks for structural equality.

and 'equals?'
Post reply on HN