5 ms·

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

42 points by bascule 16y ago

viraptor 16y ago
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?
- rubyrescue 16y ago
  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.
  - viraptor 16y ago
    > 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 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.
- mononcqc 16y ago
  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.
baddox 16y ago
The title is correct, albeit vacuously.
deno 16y ago
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?
- mononcqc 16y ago
  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.
- bascule 16y ago
  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.
  - deno 16y ago
    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.
    - 16y ago
deleted 16y ago
[deleted]
yah 16y ago
Clearly the author knows Erlang almost as well as he knows Perl.
- bascule 16y ago
  For what it's worth I know Erlang a hell of a lot better than I know Perl
- azgolfer 16y ago
  LOL - Ruby is Smalltalk, not object oriented PERL. PERL has had objects for quite a while.

42 points by bascule 16y ago

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?

rubyrescue 16y ago
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.
- viraptor 16y ago
  > 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 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.
mononcqc 16y ago
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.

baddox 16y ago

The title is correct, albeit vacuously.

deno 16y ago

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?

mononcqc 16y ago
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.
bascule 16y ago
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.
- deno 16y ago
  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.
  - 16y ago

deleted 16y ago

[deleted]

yah 16y ago

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

bascule 16y ago
For what it's worth I know Erlang a hell of a lot better than I know Perl
azgolfer 16y ago
LOL - Ruby is Smalltalk, not object oriented PERL. PERL has had objects for quite a while.