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

Programming and Programming Languages

papl.cs.brown.edu

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Programming and Programming Languages

#41

Post by shriramkmurthi »

agumonkey wrote: post #31
krat0sprakhar wrote: post #5

Earlier quoted context omitted.

How is HtDP opposed to the SICP philosophy? From my reading both come off as espousing the more or less same ideas for building programs.

One is that SICP had a fair amount of math (I believe caused by Electrical Engineer authors), so while you're trying to grok recursive logic, you also have to deal with arithmetic invariants (convergence with reals). HtDP had much less. Based on https://www.coursera.org/course/programdesign (which is inspired by HtDP) you only deal with simple data and logic but focus on regular and precise analysis of ad-hoc types (…

SICP and HtDP are two very different books that have the unfortunate feature of using somewhat similar languages (which are syntactically very similar, hence causing the confusion).

I was recently re-reading SICP, and was amazed by how cleverly structured it is. It somehow goes for an entire fifth of a book without any data structure at all. It retrospect, I consider it something of a virtuoso achievement to have pulled that off while writing a book that is utterly compelling on every page. However, the only way it can achieve that is by focusing _entirely_ on what we call "domain knowledge". As the kind of person who has always loved the play of numbers, I was immersed fully and barely noticed what was happening when I read it as a student. To most students, however, this material is both uninteresting and difficult, and difficult material that isn't even relevant to the domain is especially uncompellling.

Of course, diving into data early means you need a lot more help structuring your programs. HtDP focuses precisely on that problem, _using_ the data to drive the structure (inspired by earlier efforts such as The Little Lisper). And this highlights exactly how very different the two books are. It is much like the comment about the US and UK: "two countries separated by a common language". The coincidence of using (almost) the same language in both books has, sadly, created a great deal of confusion on this point.

Re: Programming and Programming Languages

#42

Post by moron4hire »

acbart wrote: post #3
yzzxy wrote: post #2

At first glance this book appears in many ways to be a spiritual successor to SICP... does this hold up for anyone who has read it more throughly?

The author is one of the big people in the Racket curriculum.

So that is why this looks like PLT's documentation format.

Re: Programming and Programming Languages

#43

Post by chton »

shriramkmurthi wrote: post #39
chton wrote: post #32

Earlier quoted context omitted.

It's surprising to me how few developers, even hardcore OO developers, are able to just give this minimal definition. It's the core of the entire paradigm, that an object is state and behaviour on that state, and yet everybody always gives some convoluted, hardly understandable-to-a-beginner definition. If you're going to be teaching people, "behaviour and state" should be your starting point, not "a value that maps…

You should read the chapter. Apparently even Alan Kay doesn't quite agree with your view. Also please note that I did not offer this as a _definition_. What I wrote, quite carefully, was: “pretty much the only thing everyone who talks about objects agrees about”. I stand by that, because there are people who don't agree with what you say.

Alan Kay disagrees that objects exist to 'encapsulate state'. I agree with him. They also encapulsate behaviour. While it's difficult to get a precise overview of Kay's definition (he never gave them explicitly), this page does a good job of collecting the various bits: http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

Notable for the "behaviour and state":

   3. Objects have their own memory (in terms of objects).
   4. Every object is an instance of a class (which must be an object).
   5. The class holds the shared behavior for its instances (in the form of objects in a program list)
But my point is that I don't agree that an object is "a value that maps names to stuff". I bet even Alan Kay would disagree, seeing as he was a proponent of the Actor model style of working, where objects exchange messages instead of method calls or values. In that case, there are no names to map, there is incoming data that matches a protocol. The object itself determines what behaviour to enact on its own state. Seeing an object as just values and methods is too simplistic, and at the same time too vague to mean anything.

And more importantly, as a first sentence to explain what an object is, it's misleading and will raise a lot more questions later.

Re: Programming and Programming Languages

#44

Post by agumonkey »

shriramkmurthi wrote: post #41
agumonkey wrote: post #31

Earlier quoted context omitted.

One is that SICP had a fair amount of math (I believe caused by Electrical Engineer authors), so while you're trying to grok recursive logic, you also have to deal with arithmetic invariants (convergence with reals). HtDP had much less. Based on https://www.coursera.org/course/programdesign (which is inspired by HtDP) you only deal with simple data and logic but focus on regular and precise analysis of ad-hoc types (…

SICP and HtDP are two very different books that have the unfortunate feature of using somewhat similar languages (which are syntactically very similar, hence causing the confusion). I was recently re-reading SICP, and was amazed by how cleverly structured it is. It somehow goes for an entire fifth of a book without any data structure at all. It retrospect, I consider it something of a virtuoso achievement to have pul…

Wasn't HtDP written to address issues in SICP ? completely or partially ? I always felt that HtDP was sharing more than a language to express programs in.

> It somehow goes for an entire fifth of a book without any data structure at all

Funny, in the MOOC I linked, from what I remember, they spent a lot of time writing programs without compound data types too. Only by having naive conventions (item0, item1,...) to let us recognize the logic behind complex type in the problem data and let it sink in our minds. I don't know how close to the book this was though so I don't wanna give off conclusions.

Re: Programming and Programming Languages

#45

Post by shriramkmurthi »

agumonkey wrote: post #44
shriramkmurthi wrote: post #41

Earlier quoted context omitted.

SICP and HtDP are two very different books that have the unfortunate feature of using somewhat similar languages (which are syntactically very similar, hence causing the confusion). I was recently re-reading SICP, and was amazed by how cleverly structured it is. It somehow goes for an entire fifth of a book without any data structure at all. It retrospect, I consider it something of a virtuoso achievement to have pul…

Wasn't HtDP written to address issues in SICP ? completely or partially ? I always felt that HtDP was sharing more than a language to express programs in. > It somehow goes for an entire fifth of a book without any data structure at all Funny, in the MOOC I linked, from what I remember, they spent a lot of time writing programs without compound data types too. Only by having naive conventions (item0, item1,...) to le…

> Wasn't HtDP written to address issues in SICP ? completely or partially ?

Absolutely. (Though that wording suggests a stronger causal link than was really present. It was written to address a need, a need that happened to not be addressed by SICP.)

Re: Programming and Programming Languages

#46

Post by shriramkmurthi »

dagw wrote: post #35
yzzxy wrote: post #9

Earlier quoted context omitted.

Interesting... It seems to me that FP is having quite a renaissance recently, which could limit the relevance of that paper's contentions today. I'm also seeing quite a backlash against OOP and especially OOP as the One True Paradigm that it was pushed as in throughout the 00s - this can be seen not only in FP language growth but also in the design of other new languages like Go that lack many OOP features. Honestly,…

It seems to me that FP is having quite a renaissance recently It seems that FP is always having a renaissance. I distinctly recall lots of people (including me) talking in 2001-2002 about the big FP renaissance just round corner. I also recall a few old school lisper rolling their eyes at us and saying that they where saying the same thing back in the early-mid 80's.

Doesn't mean it's not true. There is now hard-core industrial use growing, which has never quite been true in the past two decades. Not to mention, mainstream languages have mostly all now accepted the starting premise of FP (closures as first-class values). That's the first step; there are many more to come.

Old Lispers' eyes are stuck in a permanent roll position, like the Agena-Gemini 8 dock.

Re: Programming and Programming Languages

#47

Post by shriramkmurthi »

chton wrote: post #43
shriramkmurthi wrote: post #39

Earlier quoted context omitted.

You should read the chapter. Apparently even Alan Kay doesn't quite agree with your view. Also please note that I did not offer this as a _definition_. What I wrote, quite carefully, was: “pretty much the only thing everyone who talks about objects agrees about”. I stand by that, because there are people who don't agree with what you say.

Alan Kay disagrees that objects exist to 'encapsulate state'. I agree with him. They also encapulsate behaviour. While it's difficult to get a precise overview of Kay's definition (he never gave them explicitly), this page does a good job of collecting the various bits: http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented Notable for the "behaviour and state": 3. Objects have their own memory (in terms of object…

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 be a pedagogic instrument, not a dictionary or other book of definitions. Every chapter is written in this style.

Re: Programming and Programming Languages

#48

Post by shriramkmurthi »

moron4hire wrote: post #42
acbart wrote: post #3

Earlier quoted context omitted.

The author is one of the big people in the Racket curriculum.

So that is why this looks like PLT's documentation format.

Yep, it's written in Scribble [http://docs.racket-lang.org/scribble/]. Which is magical for writing substantial documents. You notice the build time for your book has crept up to 30 seconds because you've forgotten to run the separate compiler in a while. You do it — which compiles all the chapters (taking a little over 30 seconds) — after which subsequent compiles are back down to 4 seconds. Good luck getting that with most other writing tools.

Re: Programming and Programming Languages

#49

Post by chton »

shriramkmurthi wrote: post #47
chton wrote: post #43

Earlier quoted context omitted.

Alan Kay disagrees that objects exist to 'encapsulate state'. I agree with him. They also encapulsate behaviour. While it's difficult to get a precise overview of Kay's definition (he never gave them explicitly), this page does a good job of collecting the various bits: http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented Notable for the "behaviour and state": 3. Objects have their own memory (in terms of object…

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 only thing everyone who talks about objects agrees about— is". If it had said "One notion of an object -one that many people who talk about objects agree on- is", all would be dandy. When you're stating things as fact in a document dedicated to learning, they should be solid.

My other gripe is that I've heard too many vague, biased or incomplete answers to the question "what is an object". These are structures people use every second of every day, but they've never learned a proper definition for it?

Re: Programming and Programming Languages

#50

Post by makmanalp »

shriramkmurthi wrote: post #20
makmanalp wrote: post #8

His other book was PLAI which was pretty cool: http://cs.brown.edu/courses/cs173/2012/book/ I worked through it for a class, and I distinctly remember a moment where I thought "what the fuck - did I just write a working type inferencer?". It has a great way of simplifying things to the point where adding a complex new language feature isn't a distant theoretical proposition, it seems like a simple and straightforward…

By the way, you've summed up Pyret quite nicely (-:, though it is more than just that sum (with more goodies on the way).

Thank you - I wasn't expecting a response from you here! "Bastard child of python and plt" is a high compliment coming from me :-)

I keep hearing your name, first because Kathi was my beloved teacher and advisor, second because Justin worked with you, and third because I made Frank Goodman take your class. Maybe we'll finally meet one day!

Post reply on HN