Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

[OPINION] Perl 6 object system

Name: Anonymous 2011-05-23 15:16

Hi, /prog/. What are your thoughts on Perl 6's object system?

Name: Anonymous 2011-05-23 15:20

Not familiar with it, but I can tell you that object-oriented programming is now on the decline, even among former object-oriented purists.

Name: Anonymous 2011-05-23 15:29

>>1
It's... class based. There's not much to say about it other than it has the usual stuff, including roles and monkey junk which I guess has been in demand lately.

The interesting thing is the grammar stuff and the way it ties into the object system. You can supply an :actions object to a parse method to build a result object instead of just a plain old match.

Name: Anonymous 2011-05-23 16:00

>>2,3
What would be the ideal object system in your opinion, and why?

Name: Anonymous 2011-05-23 16:04

>>4
Do we really need one?

Name: Anonymous 2011-05-23 16:09

>>5
Sometimes, though quite rarely, you do. For example, for a GUI library.

Sorry for not saging, but I actually want to bump this thread.

Name: Anonymous 2011-05-23 16:15

>>6
For example, for a GUI library.
Quite ironic, I got flamed (trolled?) today because I implied somehow that OOP is good at GUI libraries.
I'm ok with whatever is default, as long it is not forced on me and it's not the primary way to define user-defined types, and prefer prototypes. No specific reason, I just like it and feels more Lispy in Lisps.

Name: Anonymous 2011-05-23 16:33

>>6
I think the use of object-oriented design for GUI systems needs to end. Yes, it makes it simple for novice programmers, but at the cost of serializing everything.

GUI libraries need to move more towards how modern highly-parallel game engines are structured, using data-oriented design, task-oriented parallelism with concurrent algorithmic skeletons, and functional techniques like actors/monads.

The free lunch is over, and GUI library developers are straggling way, way behind every other type of developer at adopting concurrent programming practices.

Name: Anonymous 2011-05-23 16:38

>>8
GUI libraries need to move more towards how modern highly-parallel game engines are structured, using data-oriented design, task-oriented parallelism with concurrent algorithmic skeletons, and functional techniques like actors/monads.
I'm not sure I understand what you mean. Would you mind crafting up a simple example demonstrating the paradigm shift referred to in your post, or at least giving more details?

Name: Anonymous 2011-05-23 16:51

>>9
http://publications.dice.se/attachments/CullingTheBattlefield.pdf
http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

They still use C++ as their primary development language (in fact, game developers are moving away from scripting languages because they just don't scale all that well... maybe they'll adopt something more like haskell or scala in the future for scripting, who knows?). But instead of rich class hierarchies with fine-grained objects, they have very shallow class hierarchies and heavier-grained objects which manage homogeneous arrays of properties.

Name: Anonymous 2011-05-23 17:17

>>9,10
And for concurrency, they're using stuff like Cilk, FastFlow, TBB, MS PPL, etc. although they often build their own implementation modeled after the above.

http://calvados.di.unipi.it/dokuwiki/doku.php?id=ffnamespace:about

Name: Anonymous 2011-05-23 17:44

>>4
There is no ideal. I would settle for almost any prototype system besides Lua's. I think you can sweet-talk Perl 6 into doing it IIRC.

A fun thing about Perl 6's system is that everything is an object of some kind, which is more normal in prototype systems.

Name: Anonymous 2011-05-23 18:03

>>10,11
Sorry for holding you back from work with my stupid posts. While I wholeheartedly agree with you that a GUI library needs to be designed with large workloads in mind and thereby optimized for speed (using the various techniques described in your posts), wouldn't the exposed interface still be OO-ish? Back when I wrote >>6, I never meant coding an entire GUI library using OOP constructs, God forbid -- I was only referring to the interface exposed to the application. Sorry for not being more specific.

Talking with you about this has helped me settle a few things in my mind, and I thank you for that.

Name: Anonymous 2011-05-23 18:25

>>13
Only a subset of object-orientated programming.

Classes with instance methods? Yes.
Encapsulation? Sure.
Inheritance? Not so much.
Composition? Yes.
Class-invariance rules and RAII? Yes.
Runtime polymorphism? Hell no.
Runtime reflection? Hell no.
Rich object graphs, trees and collections representing complex relationships between objects? Hell no.

What about functional concepts?

Templates/strongly-typed macros? Yes.
Functors/closures and lambda functions? Yes.
Actors? Yes.
Generators? Yes.
Continuations? Yes.
Parallel patterns like map, reduce, filter, fold, etc.? Yes.

Name: Anonymous 2011-05-23 18:42

>>14
Great, that pretty much fully confirms my thoughts on the matter.

But why do you consider Actors to be a functional concept?

Name: Anonymous 2011-05-23 19:48

>>15
I am not >>14, but Wikipedia argues that lambda functions were the first actors. I'd guess that the immutability of functions makes concurrency trivial/easier.

Name: Anonymous 2011-05-23 20:11

did the [quote][OPINION[/quote] keep out the trolls from this thread lol?

Name: Anonymous 2011-05-23 20:12

>>17
>[OPINION]

Name: Anonymous 2011-05-23 21:11

>>17
PIG DISGUSTING!!!

Name: Anonymous 2011-05-24 0:51

>>14
Class-invariance rules and RAII? Yes.
Why RAII, when unwind-protect does it better?

Name: deppricated 2011-05-24 3:35

deppricated

Name: Anonymous 2012-03-22 19:24

I was just reading about perl6 yesterday. The object system is good (IMHO), but that twigil thing need some explaning
class C {
  has $.x;
}

Then, if you ask for the attributes
say C.^attributes;

It shows
$!x

The ! indicates that it is a private attribute.

But $.x does not declare a public attribute. It is a private one with an public accesor called $.x

In fact, if you ask for the available methods of C...
say C.^methods;
you will get this:
x <--- The 'x' accesor.

Name: Anonymous 2012-03-22 20:05

on a somewhat unrelated note, perl6 has support for AST macros now. I dont think the feature is mature yet, but is interesting anyway.

Name: Anonymous 2012-03-22 20:07

Too many sigils and twigils, not enough ASCII characters.

Name: Anonymous 2012-03-22 20:09

Some perl6 operators even have unicode versions, like >>

Name: Anonymous 2012-03-22 20:31

>>14

This is typical GUI in Java:

class Component {
  void paint() {
    // paint background
  }
}

class Button extends Components {
  void paint() {
    // paint button
  }
}


Somewhere else:

for (Component c: components) {
  c.paint();
}


It would be useless without polymorphism. Why use inheritance without polymorphism and not just composition?

Does `switch' really cost less than virtual table lookup?

Sorry for going off-topic.

Name: Anonymous 2012-03-22 20:45

This is a typical faggot in /prog/

Hey check this dubs
kajudisaudiosaudioqewueoiqwe
X is shit
Fuckin Jews|Nigger|Jewnigger

Somewhere else:
(on a thread dead from 1 year ago)
Bump

It would be useless without other /progriders/ to play along. Why troll some other dead boards with no captcha?

 Does reporting really cost less than ignore the shitposts?

 Sorry for going off-topic.

Name: Anonymous 2012-03-22 20:47

>>27
nice audio dubs, bro!

Name: Anonymous 2012-03-22 21:20

>>26
This is a Perl 6 thread motherfucker: @comonents».paint;

And, hey >>8, PAY THE FUCK ATTENTION! That was some auto-threaded OO code right there.

Name: Anonymous 2013-09-01 13:30


Why does that guy have the Mozilla logo on his uniform?

Name: Anonymous 2013-09-01 15:01


I'm now wanting to write larger programs, with more moving parts - acquiring data from a variety of different sources, cleaning it, processing it in various ways, displaying it in user interfaces, persisting it, communicating over networks, etc. How could one best structure such code to be legible, maintainable, and adaptable to changing requirements?

Don't change these.
Name: Email:
Entire Thread Thread List