[jon.kiparsky]

I believe the something else that's going on is that cond is a macro, and else is only defined within the context of that macro.

That would explain why this works:

 (define else "else")
(cond (else else))

[jon.kiparsky]

For what it's worth, if anyone wants more practice with streams, the collatz conjecture is fun to play with here. I imagine that you could also use it to explore memoization.

[jon.kiparsky]

Quick heads-up: if you're using JewelryBox to upgrade Ruby on a Mac, it'll install a .bash_profile. If you've got a custom .profile, the .bash_profile will take precedence, and you're going to be looking at the crappy stock setup again. And also, /usr/games will no longer be on your path.

Obviously, this can be remedied easily enough .

I don't know whether jewelrybox will overwrite an existing .bash_profile, or what it does if it finds one. You might want to back up yours if you have one, or you could find out the hard way.

This post has been edited by jon.kiparsky: 02 March 2013 - 10:04 PM

[cfoley]

That's me just finished the second Racket homework. I feel like I'm lagging behind!

MUPL is a lot like SML, isn't it?

Something I have been wondering about making languages in lisp is the syntax you end up with. We ended up with something that looks a lot like lisp but feels like a subset of SML. Read almost any article about lisp and it will mention something vague about the ease of implementing languages in lisp, yet google "c in lisp" or "java in lisp" and you'll find the converse: lisp implemented in c or lisp for the JVM.

Have I misunderstood something? I always assumed macros would make it easy to drop the parens but every example of a DSL-in-lisp I've seen has those parens.

[jon.kiparsky]

I think that's partly got to do with time - if you're showing the ease of implementing some other language, you probably want to focus on something deeper than the syntax. We can all implement parsers, I think. It's a little tricky to parse some languages, but once you get the trick, you pretty much know how to do it (and you let a machine do it for you ) But to show that all languages are more or less equivalent in two steps, you can simply use lisp to implement enough language features to convince your audience that any language you can define can be implemented in lisp, and then show that lisp itself can be implemented in any language.

In principle, any language could have been used for this, but lisp is preferable because it's the easiest representation of an AST to work with - so it's easy to translate into and out of.

[cfoley]

I think you're right about tutorials going with easy-to-implement syntaxs. From Wikipedia:

Quote

The macro system in Racket has been used to construct entire language dialects. This includes Typed Racket—a statically typed dialect of Racket that eases the migration from untyped to typed code,[35] and Lazy Racket—a dialect with lazy evaluation.[36] Other dialects include FrTime (functional reactive programming), Scribble (documentation language),[37] Slideshow (presentation language),[38] and several languages for education.[39][40] Racket's core distribution provides libraries to aid the process of constructing new programming languages.[13]

Such languages are not restricted to S-expression based syntax. In addition to conventional readtable-based syntax extensions, Racket's #lang makes it possible for a language programmer to define any arbitrary parser, for example, using the parser tools library.[41] See Racket logic programming for an example of such a language.

This post has been edited by cfoley: 11 March 2013 - 01:14 AM

[jon.kiparsky]

Due to a busy week, I'm just now looking at assignment 7. Has Grossman just become a parody of an FP drone at this point?

Quote

The SML solution is structured with functions and pattern-matching. The Ruby solution is structured with subclasses and methods, including some mind-bending double dispatch and other dynamic dispatch to stick with an OOP style even where your instructor thinks the ML-style design is easier to understand

Say what? So this assignment is just here to show us that object-oriented programming is a Bad Thing? I don't know about you all, but I don't have time for bullshit of this magnitude. "Hey, kids, for your next lesson on Ruby programming, here's why Ruby sucks!" Gee, thanks, buddy.

This post has been edited by jon.kiparsky: 17 March 2013 - 02:59 PM

[cfoley]

Apparently so. There have been a lot of examples where FP is better than OO but few the other way around. I wonder why. Does it reflect Dan's preference or are we just supposed to already know what is good about OO? I think I would have benefited from a fuller comparison.

Dan gave one example where OO is a good choice: GUIs. There has to be more to it than that. The entire industry can't be so wrong it has chosen the wrong tool for just about every job.

The way I see it is that most programs have mixtures of subproblems that are variously amenable to OO or functional solutions. Most modern languages support both at some level. Most OO languages (e.g. Ruby) support closures and at least some functional languages (e.g. Racket) support OO.

[jon.kiparsky]

I'm coming to feel that the distinction between "functional" and "imperative" and "object-oriented" programming is obsolete and has been since before any of the people yapping about it even knew what a closure was.

cfoley, on 17 March 2013 - 05:53 PM, said:

Dan gave one example where OO is a good choice: GUIs. There has to be more to it than that. The entire industry can't be so wrong it has chosen the wrong tool for just about every job.

And honestly, GUI isn't even that great a use case. Swing, for example, is agonizing, but the declarative style that we get in Android or in Django is actually a lot more pleasant.

No, OO is great for real-world programming. There's tons of great use cases - that's why it's part of most modern languages.

[cfoley]

I think they are useful distinctions in so far as they let people talk about concepts. I also think you can learn a lot from forcing yourself to use a solely functional language like ML or Haskell. The same can be said for a purely OO language like smalltalk; C for imperative; Erlang for concurrent; Prolog for logical...

I also agree that the level of fanboyism for both functional and OO camps is a little silly.

Going back to the problem of a huge case statement versus little bits scattered through objects: both are pig ugly. What you have is a combinatoric problem where you have to evaluate all possibilities yourself. Imagine 10 or 20 different object types! I don't want to write 400 cases any more than I want to write 400 methods!

[jon.kiparsky]

cfoley, on 18 March 2013 - 03:50 AM, said:

I also agree that the level of fanboyism for both functional and OO camps is a little silly.

Is there fanboyism in the OO camp? Is there even an OO camp? I can't think of any examples, honestly.

Quote

Going back to the problem of a huge case statement versus little bits scattered through objects: both are pig ugly. What you have is a combinatoric problem where you have to evaluate all possibilities yourself. Imagine 10 or 20 different object types! I don't want to write 400 cases any more than I want to write 400 methods!

I think I'd rather describe the objects than fiddle around with all the combinatorics in a case statement. At least then there's the chance you might get your object design right and then most of your cases write themselves, thanks to inheritance.

This post has been edited by jon.kiparsky: 18 March 2013 - 05:54 AM

[cfoley]

So, I made up my own challenge problem. Instead of implementing the whole thing in another language, I refactored the Ruby version and I think I ended up with a very concise and readable OO version. I made a lot of changes but here are the important ones:

• Put every class in its own file, blank line between methods and removed all comments (especially the ones that forbid me from modifying sections of code)
  
  
• Lots of cases just flip the arguments of intersect. I made this the default in GeometryValue. For example, if a class doesn't override intersectLineSegment, it gets this default implementation:
  
  

    def intersectVerticalLine vline
      intersect(vline)
    end
  

  
  
  It means you have to be careful to override enough of them or you end up with infinite loops but a comprehensive test suite covers this.
  
  
• Nothing intersects NoPoints. I deleted all the intersectNoPoints methods. Because of the above change, anything that tries to intersect it reaches NoPoints.intersect, which now returns a NoPoints. The class looks like this and a substantial amount is removed from all the other classes:
  
  

  class NoPoints < GeometryValue
   
    def shift(dx,dy)
      self 
    end
  
    def intersect other
      self
    end
  
    def intersectWithSegmentAsLineResult seg
      self
    end
  
    def contains point
    	false
    end
  end
  

  
  
  
• Every concrete value class has a contains point method, and Line has a method that takes an x coordinate and returns a Point on the line. This reduces most of the cases to a simple boolean check using the relevant methods to choose between self and NoPoints as the return value. This one in the Point class is typical:
  
  

    def intersectWithSegmentAsLineResult seg
      self_or_none(seg.contains(self))
    end
  

  
  The self_or_none method is defined in the superclass and behaves as expected.
  
  
• I also provided a default implementation for intersectWithSegmentAsLineResult which just returned the segment.

I did other things too like moving methods into classes where they were more appropriate but the above points are the most important. Most of the 25 cases were handled by the defaults in GeometryValue and NoPoints. The rest break down like this:

7 simple one-liners (including 1 intersectWithSegmentAsLineResult)
1 simple if statement (Line.intersectLine)
1 fifteen-line intersectWithSegmentAsLineResult (for the intersection of segments with other segments). This is easily the worst piece of code left and could probably be further refactored. The reason I stopped is because I wanted to use a Proc in a helper method but this conflicted with the spirit of the OO exercise.

So, by providing some default behaviour for the methods more than half of the 25 cases melt away and by defining the interactions between objects, all but 2 become trivial one-liners. As a bonus, the user of the geometry language has a few more operations he can perform easily. :-)

[jon.kiparsky]

Very nice. Maybe I'll actually take another look at the code with that in mind. I looked at the assignment and was so disgusted, I just shelved the class, but that looks like a fun approach.

[cfoley]

Unfortunately, I went too far to submit it for peer review: changing stuff in the superclasses and removing things from where I wasn't supposed to. I also got 100% on the first submission so bouncing it off the autograder could only harm my mark.

It also doesn't solve the general combinatorial problem. It's just a happy coincidence in this case that so many cases can be generalised. However, the standard OO practice of writing methods for interactions instead of exposing field values always gives a concise, readable result.

That final point sounds a lot like the common argument in favour of higher order functions. I might have another shot at refactoring this into a hybrid of OO and functional programming to see what I end up with.

Jon, it's a shame to drop out of the class on the penultimate hurdle. There was a lot of value for me in the course. It's consolidated the little bits of FP I already knew and has given me a solid foundation to build on. Enrolling has been one of the better decisions I've made for a long time. I do get the impression from your posts that your experience has been the exact opposite.

[jon.kiparsky]

I've learned a good bit from the earlier exercises. I found ML to be an atrocious language, but having done some side work on it makes me think it was more the presentation - the compiler is very persnickety, and Dan's approach works well only if you're doing everything exactly Dan's way. I'm more of a tinkerer, so I found things were breaking a lot more than I was happy with. Now that I've learned a bit more about the language itself, I find it's a bit more well-behaved.
The racket material was interesting, and the interpreter was a good fun exercise.


However, the class as a whole seemed more geared at an ideological point, and an incoherent one: Functional Programming is "better" than Object-Oriented Programming. This, to me, is both boring and wrong. It's clear to me that there are advantages in functional programming, I was more interested in learning more about how to make use of those advantages. Instead, I got the same old "FP good, OOP bad". So I bailed out and started writing exercises out of Sedgewick, in Ruby.

I'm not sure what I've lost by this - I can see badly-made OOP every day in the Java forums...
I might do the final, just for giggles, but I'd rather stick a fork in my eye than mess around with any more of Grossman's attempts to write object-oriented code. Frankly, I have to wonder if the reason he hates object-oriented programming so much is just that he's not very good at it.