HN user

maxtilford

69 karma

maxtilford@gmail.com

Posts2
Comments39
View on HN

What you quoted doesn't mention an IDE at all. "extract interface" is just the name of series of steps that you can accomplish with or without an IDE.

Martin Fowler's book 'Refactoring' gives names a whole bunch of these. That might be where the op is coming from.

JSONSelect 15 years ago

That S-expressions can/often contain code doesn't make them more complicated when used for data only. Anything can contain code.

No technical limits were hit. They have nearly the same feature set.

Geocoder's api feels a little bit more modern Geokit (rails3 vs 2). Having read the code for both, Geocoder was cleaner and would be easier to tweak if necessary.

So really it's just a preference: they do the same thing.

I just switched from geokit to geocoder in the app I'm building. I found geocoder to be significantly better for my purposes.

CommonPlace -- Cambridge, MA (http://commonplaceusa.com)

We're a nearly-funded startup creating a social platform for local communities and neighborhoods.

* Web Dev Intern: Will be working on a Ruby on Rails web app with some civic-minded Harvard students. Some programming experience nice, but not required. We will help you learn as needed.

Contact maxtilford at gmail

Awesome. I've got it up and running. I've been looking for a solution for the client/server distinction for a while. How much have you thought about the implementation of that?

Cambridge, MA

We're building a social network for communities and neighborhoods and ooking for Rails developers.

Contact maxtilford@gmail.com if you're interested.

I used it a lot before and I use it a lot now. It took a bit of getting used to, but I rather like the new design. I've found that I'm listening to a lot more new music, where before the redesign I just kept listening to the same stuff over and over.

Using do-notation is probably cheating, but what do you think of this? (in Haskell):

  do { w <- widgets;
       s <- sprockets;
       l <- locations;
       guard (l `hasInStock` w);
       guard (l `hasInStock` s);
       guard (w `isUsableWith` s);
       return (w, s, l); }
We're trading horizontal space for vertical space. I think it's much clearer than either list comprehensions or plain map/filters. It's the best of both worlds.

Obviously, map and filter are better because ... ah, hmm, I don't know.

I think it is a matter of language design. Higher order functions are not as prominent in Python as say, Haskell, where map & friends are generally preferred for composability. Lispers prefer map & friends just because list comprehensions add all that messy syntax.

If I were a Python programmer, I would probably use list comprehensions, since they seem to be the preferred idiom.