If Ruby is object-oriented Perl, then Reia is object-oriented Erlang | Hacker News Reader

If Ruby is object-oriented Perl, then Reia is object-oriented Erlang

unlimitednovelty.com

42 pointsbascule13 comments

Besides Ruby-like syntax how does it differ from parametrized modules?

From his example:

= Reia:

  class Foo
    def initialize(value)
      @value = value 
    end 
    def value
      @value
    end 
  end

= Erlang:

  -module(foo, [Value]).
  value() -> Value.

And it's actually prettier.

Can you do some crazy pattern matching and type overloading like with Scala? Or is it just syntactic sugar for parametrized modules?

My quick guess would be

1. the initialize function allows you to encapsulate modifications to data when it is received. A parametrized module only takes a variable, so any modification done to the parameters needs to be done outside the module (Mod:new(F(Arg))).

2. Semantically speaking, parametrized modules are NOT classes/objects. They're meant as a syntactic shortcut to carry state and a module name as a single variable when calling it and writing the module itself. What I mean is that Mod:Fun(Arg) now becomes Mod:Fun(), and Arg is hidden within Mod (The current implementation is {ModuleName, Arg}:Fun()).

This use is rarely necessary and often seen as bad form by many Erlang regulars (myself included), mostly because it introduce new [superfluous] ways to do existing things in a language where its small core is appreciated. Also functional programmers getting mad at OO programmers trying to get their way in a language that was not meant for that.

Parameterized modules don't have constructors. That doesn't matter in a trivial case, but it does when you want some complex state set-up which you don't want to repeat every single time you "instantiate" a parameterized module?

Also, Reia has inheritance. Parameterized modules don't.

They certainly do with -extends(). As for constructors… there's probably way around that too. Point is Reia's OO-revolution doesn't introduce any fundamental changes besides syntax.

-extend() is another half-assed solution. It's closer to mix-ins than inheritance.

Object orientation in Reia is baked into the core language itself. Like Ruby, all of its core types are objects. In Perl and Erlang they are not. Reia factors the core language types into objects, instead of amalgamations of the core types with arbitrary and poorly factored functions which act on them.

I wonder about "The canonical approach, Erlang records, are a goofy and oft reviled preprocessor construct with an unwieldy syntax." After writing a bit of Erlang code, I don't mind records that much. They're not prefect, but I would never call them bad, goofy, etc. They're also used in pretty much every situation where a state in a predefined form is needed (config files, server state, etc.) so that proplists are not needed (no need for dynamic list).

So... what is the complaint about records really?

One of the problems with records (except the ugly syntax, especially with nested records) as a compile-time construct comes when you need to do hot loading of a module while keeping it running. The transition function using the record can no longer use the '#name{}' construct because the expanded tuple form will not match in both cases and the function will crash.

You instead need to expand the old version of the record to avoid the problem. If you forget to, things will go wrong.

So yeah, they're ugly and get tricky in some areas of your programs, but they're still essential when you want a data structure with named fields AND pattern matching. You get used to them, but they're still considered a wart to many programmers.

i agree, you get used to them. but what i don't like about them is that the way you have to specify the record every time you reference the object. so

Bar = Foo#foorecord.bar, Baz = Foo#foorecord.baz

it feels unnecessarily redundant. Shouldn't we already know Foo is a record of 'fake type' #foorecord? It's like a poor man's type system, and it's ugly.

Also, probably more importantly, since they're a compile-time trick you can't use them in the console, which makes experimentation and sometimes debugging harder.

> Bar = Foo#foorecord.bar, Baz = Foo#foorecord.baz

#foorecord{bar=Bar, baz=Baz} = Foo

Readability depends on what does your brain process, when you see "=" ;)

> since they're a compile-time trick you can't use them in the console

Check the `rX` commands from http://www.erlang.org/doc/man/shell.html You can use the records just like in normal code, but you have to load them explicitly.

The title is correct, albeit vacuously.

Clearly the author knows Erlang almost as well as he knows Perl.

LOL - Ruby is Smalltalk, not object oriented PERL. PERL has had objects for quite a while.

For what it's worth I know Erlang a hell of a lot better than I know Perl

Reply on news.ycombinator.com