Live data from Hacker News

Programming and Programming Languages

papl.cs.brown.edu

61–68 of 68 posts

Re: Programming and Programming Languages

#61
post #52

I'd like to learn from this book. > If you ask Pyret for the value of this program, it will unsurprisingly tell you that it’s 3. I am not sure how to do that. In [this tutorial]( http://www.pyret.org/docs/latest/A_Tour_of_Pyret.html#%28par... ) everything is a test. Is the program 3 supposed to be run as a test as well? Just running 3 in the editor does nothing. Where can I read up on Pyret syntax so i can follow thi…

Sorry about the confusion. Looks like you've already found https://code.pyret.org/editor (but the link is here for the information of others). You can run programs by typing them in the interactions area (a.k.a. REPL), which is the area on the right. To wit: > 3 3 > 1 + 2 3

I see. I was typing my code on the left half of the window and expecting the result show up on the right half. It works now. Thank you.

Re: Programming and Programming Languages

#62
post #49

Earlier quoted context omitted.

I agree, my gripes are not with the entire document, or even with the chapter in question. I also don't have a problem with starting from a statement that may be wrong in an informative way, it's a valid approach to learn a subject. My problem is that it's not presented as a starting point or even implied that the definition might be wrong. It categorically states "The simplest notion of an object—pretty much the onl…

> My other gripe is that I've heard too many vague, biased or incomplete answers to the question Well, "behaviour and state" is also incomplete, because it fails to mention anything about how you refer to parts of state and particular behaviours. "a mapping of names to values and functions" on the other hand mentions both state ("values") and behaviour (functions) and also tells you that they have names. > they've ne…

How you refer to state or behaviour is not strictly relevant to the definition of an object, because it depends on how you implement it. It might fit in the language it was used in, but it doesn't in others. Behaviour might be reactive on state changes, it might be perpetual in a nameless loop, it doesn't matter. In the same vein, referring to state as values and behaviour as functions is too narrow. The lifecycle of the object is part of its state too, an object's construction and destruction is part of its behaviour. That may sound like hair-splitting, but it can seriously trip you up and give you a wrong idea of what an object is in non-conventional settings. An object is more than a map of 'name' to 'value or function'.

It's possible that my dismissal of many definitions is partly because they're not my preferred one. I'm human, so it's most likely the case. I like to think my preferred one at least came about through some investigation, and it's the only one that I've seen fit a wide enough variety of cases. For me, at least part of the validation comes from the fact that I was frustrated at the definitions people gave me long before I found one I liked. Too many conversations with college teachers, mentors and colleagues that went

  "So how would you define/describe an object?" 
  -"..."
  "OK, but what about [language/edge case/model]?"
  -"Oh yeah..."
I'll gladly have this conversation again, and again, and again, and I hope somebody can poke holes in the definition I prefer, and put me on the other side of it.

Re: Programming and Programming Languages

#63
post #62

Earlier quoted context omitted.

> My other gripe is that I've heard too many vague, biased or incomplete answers to the question Well, "behaviour and state" is also incomplete, because it fails to mention anything about how you refer to parts of state and particular behaviours. "a mapping of names to values and functions" on the other hand mentions both state ("values") and behaviour (functions) and also tells you that they have names. > they've ne…

How you refer to state or behaviour is not strictly relevant to the definition of an object, because it depends on how you implement it. It might fit in the language it was used in, but it doesn't in others. Behaviour might be reactive on state changes, it might be perpetual in a nameless loop, it doesn't matter. In the same vein, referring to state as values and behaviour as functions is too narrow. The lifecycle of…

> [...] An object is more than a map of 'name' to 'value or function'.

Ok, after that explanation I understand what you mean. I could argue that, for example, object construction and destruction semantics are not characteristics of an object itself but rather of a particular object system or "meta-object protocol" being used; or that it's almost impossible to talk about object destruction outside of particular language context, because it relies on many different language-level features to work. But that would be too much of a hair-splitting for me :)

On the other hand I could argue that a set of functions is enough to express every possible type of behaviour and that a set of values is enough to express any possible state. But this in turn depends on the definitions of "value" and "function", which are highly language specific.

So, after thinking about it for some time, I think I can agree that "behaviour and state" is the best (possible?) definition of those which avoid diving into any implementation details and language specific features.

I'm not entirely convinced that such a definition is very practical though. You probably won't need that level of generality until you decide to implement your own object system. It won't help you (I think?) in OO design or OOP inside of some particular object system.

But anyway, you're right in that your definition is the best one in the category of "general" and "minimal" definitions of what objects are.

Sorry for ad personam in my previous comment and thanks for the discussion, it was enjoyable :)

Re: Programming and Programming Languages

#64
post #49

Earlier quoted context omitted.

Diving into the middle of a large and complex document and extrapolating from that is always a dangerous venture. The style of the book is to gradually reveal things as it goes along, often even starting with incorrect statements, because we learn best when we see missteps, not only from perfect solutions. Therefore, there's nothing wrong with "starting from" a statement that may not be where we end up. It's meant to…

I agree, my gripes are not with the entire document, or even with the chapter in question. I also don't have a problem with starting from a statement that may be wrong in an informative way, it's a valid approach to learn a subject. My problem is that it's not presented as a starting point or even implied that the definition might be wrong. It categorically states "The simplest notion of an object—pretty much the onl…

[deleted]

Re: Programming and Programming Languages

#65
post #62

Earlier quoted context omitted.

> My other gripe is that I've heard too many vague, biased or incomplete answers to the question Well, "behaviour and state" is also incomplete, because it fails to mention anything about how you refer to parts of state and particular behaviours. "a mapping of names to values and functions" on the other hand mentions both state ("values") and behaviour (functions) and also tells you that they have names. > they've ne…

How you refer to state or behaviour is not strictly relevant to the definition of an object, because it depends on how you implement it. It might fit in the language it was used in, but it doesn't in others. Behaviour might be reactive on state changes, it might be perpetual in a nameless loop, it doesn't matter. In the same vein, referring to state as values and behaviour as functions is too narrow. The lifecycle of…

The difference between you and me is that I've seen enough different notions of object (and defined some of my own) that I don't believe there is any such definition. In class I discuss why, but it's difficult to transcribe such an interactive discussion; but it is essentially the other side of "this conversation again, and again, and again".

I don't find your definition particularly useful, either: it's too encompassing to really be of much use _to me_. By this definition just about all computation is an "object", which doesn't really tell me anything interesting.

Also, as a general pedagogic principle, I'm opposed to definitions that are too vague to say much to a middle-of-the-pack undergraduate. I'd definitely put your definition of objects in that space. It sounds like good stuff—it's certainly "quotable"—but the typical student would be hard-pressed to actually explain it or put it to use.

Re: Programming and Programming Languages

#66
post #62

Earlier quoted context omitted.

How you refer to state or behaviour is not strictly relevant to the definition of an object, because it depends on how you implement it. It might fit in the language it was used in, but it doesn't in others. Behaviour might be reactive on state changes, it might be perpetual in a nameless loop, it doesn't matter. In the same vein, referring to state as values and behaviour as functions is too narrow. The lifecycle of…

The difference between you and me is that I've seen enough different notions of object (and defined some of my own) that I don't believe there is any such definition. In class I discuss why, but it's difficult to transcribe such an interactive discussion; but it is essentially the other side of "this conversation again, and again, and again". I don't find your definition particularly useful, either: it's too encompas…

It's definitely possible that there is no one good definition, but it's a good discussion to have. I applaud that you treat this with your class.

The usefulness is debatable. To me, it's been useful because it helped me see that, for example, a process can also be an object, and you can apply object oriented rules to interacting processes. The Actor model is an extension of that. Modelling a set of Microservices as an object model has also proven valuable.

How you communicate it to students is a not an easy matter. I'm opposed to giving definitions as an absolute truth if they aren't, even if you're doing to prove a point. If you want to teach with different definitions, that is of course perfectly fine, but at least a mention of the debate could solve some later problems. People tend to adhere to the 'laws' they learn for a long time, and if you teach them a definition that is incorrect in some cases, they'll have trouble with those cases.

Re: Programming and Programming Languages

#67
post #62

Earlier quoted context omitted.

How you refer to state or behaviour is not strictly relevant to the definition of an object, because it depends on how you implement it. It might fit in the language it was used in, but it doesn't in others. Behaviour might be reactive on state changes, it might be perpetual in a nameless loop, it doesn't matter. In the same vein, referring to state as values and behaviour as functions is too narrow. The lifecycle of…

> [...] An object is more than a map of 'name' to 'value or function'. Ok, after that explanation I understand what you mean. I could argue that, for example, object construction and destruction semantics are not characteristics of an object itself but rather of a particular object system or "meta-object protocol" being used; or that it's almost impossible to talk about object destruction outside of particular langua…

The practicality is a very personal thing. For me, it's helped me see that a wider variety of things match the definition. Realizing an Actor model, communicating processes, microservices or nodes in a storage model can all be seen as objects, and applying some object oriented modelling techniques to them, has been a very powerful tool for understanding them and building them. This value is entirely personal to me, though.

No apologies necessary, it was absolutely fair to call me out on a bias on my end. You too thanks for the discussion :)

Re: Programming and Programming Languages

#68
I know the answer to the following question is probably scattered in the comments below but, to get a concise/precise version of it in one place, I am going to ask it anyway - How does PAPL compare to SICP, HtDP, PLAI & EOPL considering there is quite some commonality amongst them? What does each book offer, what is the intended audience for each book, where do they overlap, which would be a good idea to read first for a novice?

Thanks in advance. :-)

Post reply on HN