spacemanaki

Actually, these examples are similar to the first example in my post (under the first "pathological case" heading) and don't quite exhibit the worst case behavior since the type can be represented in linear space as a dag.

Clearly I should write more blog posts with lots of questions at the end, thanks!

Thanks for pointing that out! I hadn't made the connection and now I've got another reason to figure out how fold works (have yet to wade through all of http://mlton.org/Fold)

It's unlikely to occur as the type is exponential in size and thus quite unwieldy to do anything with! I haven't worked with generated ML or Haskell code, but I still think it's unlikely to be an issue in "real" code.

Thanks, that's very flattering as I've been a long time fan of your blog!

That's very interesting! This seems to me like it might be a different kind of edge case though, since the type of x is still t -> t, even if it takes a long time for the type checker to arrive at this. From the little I got out of Mairson's paper, it seems that the proof he uses depends on the exponential size of the type itself, but I could be mistaken... either way I wonder how they're related?

Rent the Runway - New York, NY (VISA candidates welcome!)

Rent the Runway is building the first online rental platform for retail goods. We're a disruptive e-commerce business that believes democratizing luxury products in the US is just the first step of a broader vision to drive aspirational experiences for tens of millions of users across the globe. We're more than "Netflix for dresses"—we're Cinderella Experience as a Service. Find out more about the challenging product-oriented problems we face across the boundaries of e-commerce, mobile, analytics and shipping/fulfillment here: http://blog.tech.renttherunway.com/

We are hiring front-end, back-end, DevOps, and mobile (iOS) engineers. Our stack:

* Service-oriented architecture with Java 7 (soon to be 8!) and DropWizard: Modern Java is a thing and we've got the proof!

* Ruby and Sinatra for lightweight, scalable web applications.

* JavaScript and Backbone for a front end that's becoming faster and more awesome to work on every day.

Job postings: http://www.renttherunway.com/careers

Well here's another honest question: what's real object-oriented programming and where can I learn more about it?

Rent the Runway is hiring all sorts of engineers (Java, Data, iOS, full stack) in the NYC area.

Rent the Runway is building the first online rental platform for retail goods. We are a disruptive e-commerce business that believes that democratizing luxury products in the US is just the first step of a broader vision of helping drive better aspirational experiences for tens of millions of users across the globe.

Our engineering team works on challenging product-oriented problems across the boundaries of e-commerce, mobile, analytics and shipping/fulfillment, and the backbone of our business is served by our custom logistics management system which is core to our capacity to deliver the right product to the right user at the right time. We utilize data, engineering and algorithms to create a personalized website and an adaptive supply chain to fulfill our commitment to an amazing customer experience.

Engineers at Rent the Runway focus on solving business problems first, and receive the satisfaction that they have true impact on the success of the company. Many of our engineers are entrepreneurs themselves, and we strongly encourage a collaborative, product-driven culture across our organization. We have a very diverse team and welcome those with supernerd CS degrees as well as those with non-traditional backgrounds.

http://www.renttherunway.com/careers

Short answer: I don't think LYAH would be entirely sufficient background, and I think familiarity with imperative equivalents is a prerequisite, but along with some other background.

Long version: I stumbled a bit when trying to read this book, because I'm not super comfortable with the formal techniques for analyzing algorithms. I'm not talking about the kind of fluffy-tech-company-interview-"knows what big Oh is and can estimate it roughly on a whiteboard" ability but actually something much more concrete and formal, the kind taught in an undergrad algorithms class or in CLRS. I've taken those classes, I have CLRS on my shelf and have read some of it, but it's been a long time and it's not at my fingertips. There are exercises in the book ("prove that this data structure has this amortized performance", "prove that it does if you change this one thing", etc...) that challenged me quite a bit, and I ended up putting it down after a while thinking I would revisit it after refreshing my fundamentals.

The ML code is easy enough to follow if you know Haskell, but since the point is often to understand the subtlety of the performance characteristics of the data structures and algorithms, just reading and playing with the code wasn't enough for me. After all you can trivially implement functional data structures naively just by copying everything on every operation.

Frankly, Rich Hickey's videos on Clojure's data structures have done a lot more for me in terms of understanding how functional data structures work, even though they are much less formal in presentation. To be clear: I think Okasaki's book is probably a very good book and an important work, but am not so sure it is crucial for the working functional programmer to internalize all the mathematical details.

Anyway, YMMV. Check out his thesis and see what you think before buying it.

A researcher in programming languages once told me that when she encounters the "HTML isn't a programming language" meme she always thinks: Agda and Coq aren't Turing complete, are they also not programming languages?

The point being, I think, that drawing this bright line at Turing completeness doesn't hold up when you give it any thought, and so it's not very useful. Aside from that, you've utterly missed the point of the OP.

Please feel free to submit things that you think are more suitable for Hacker News.

I have no idea what you're working on, but I spent a few weeks this summer writing parsers and trying to figure out how to tackle the ugliness that seems to be inherent in hand-written recursive descent parsers. While I learned a lot, I am not an expert by a long shot. However I did find an interesting technique that is not well covered elsewhere.

I came across this* article, which uses JavaScript as the implementation language, and found it very interesting, in large part because this approach (Top down operator precedence) sort of pulls the precedence hierarchy out of the call graph of a recursive descent parser and into a table, but also because it's an approach that OOP (and JavaScript in particular) is well suited to. I've used it (in combination with traditional recursive descent) in a functional setting (Standard ML) as well, and would use it again, especially for parsing infix expressions (arithmetic expressions, type annotation expressions).

This is a bit of a tangent, but I thought you might be interested given the intersection of parsing and JavaScript. I've been meaning to write this up in a short blog post...

* http://javascript.crockford.com/tdop/tdop.html There's another article on this using Java as the implementation language: http://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-e...

The purpose of a question like this, and of the classic FizzBuzz question, is to be a lightweight test of whether a candidate can actually write code or not. That's all. It provides a negative signal if they fall completely to get anywhere close, and nothing more.

There are alternatives, you could ask them to explain a piece of code they wrote on their own before the interview, any piece of code would do. I suppose that could be gamed which is why most companies opt for FizzBuzz.

Personally, once I started thinking about these kinds of questions like this, I had less issue with them. Interviewing people who failed to write FizzBuzz opened my eyes too.

It's not about macros, it's about homoiconicity. I encourage you to read chapters 4 and 5 and think about how sweet.js would help you port those chapters to JS.

As others have pointed out, chapters 4 and 5 are as wonderful and rich as they are because Scheme is homoiconic which makes writing Scheme interpreters and compilers in Scheme very easy -- no need for hairy lexing and parsing steps. Since (IMHO) these chapters are the best introduction to the study of programming languages and their implementation, it would be a real shame to discard them simply because JavaScript is more widely known and used than Scheme.

It's true that the ideas in the book transcend programming languages, and that the first 3 chapters could probably could be covered in JavaScript with little modification, if a little clumsily. But rewriting the 4th and 5th to include sections on parsing JavaScript would be quite challenging, and furthermore JavaScript does not have as simple semantics as Scheme, so there would be a loss of a great deal of elegance and beauty. The metacircular Scheme interpreter can run itself, which would be harder to do in JavaScript since its core is more rich and Scheme's core: objects, methods and so on complicate it quite a bit.

C-_ is undo in Emacs. That's hold Control, and press "underscore". On my keyboard (most keyboards?) this requires holding Shift and pressing the "minus" key. Hopefully that's clear.

When did it become something we have to love and wrap up so much of our self-image into?

When we started spending 50, 60 hours a week at work. Even at 40 hours a week, it's exhausting to try to find any real time to devote to hobbies and "extracurricular" learning outside of work. If you feel like you're stagnating, feeling like you're wasting those 40 hours of life every week, why stay, just because "work is a financial transaction" ?

IANAL but I don't think you need to worry about this too much as an application or open source developer USING Clojure the language and Clojure's standard libs. This question and its answers on Stack Overflow points to an interpretation that makes sense intuitively to me, but again, not a lawyer, pretty ignorant of this stuff, etc...

http://stackoverflow.com/questions/168254/can-you-write-gpl-...

It would be nice if someone from the Clojure team would add a FAQ page or something about the license to clojure.org as it pertains to users of the language... Since this seems to come up a lot.

As others have pointed out, apparently the police can seize your property under certain circumstances. This was discussed recently when the article mentioned in this blog post was submitted here, well worth the read IMHO https://news.ycombinator.com/item?id=6161465

If writing compilers in C++ sounds like a pain, there's also an OCaml version of this tutorial: http://llvm.org/docs/tutorial/OCamlLangImpl1.html

Props to you for actually testing simultaneous pushes where conflicts arise at the Dropbox-level, but I would still never do this (for a multiuser repo, for a single user it's probably fine).

Maybe I'm overly risk-averse, but I've been bitten a few times by Git setups that are non-standard or complicated and decided that it's far better to keep things as simple as possible. I'm not really interested in fiddling about keeping Git running smoothly, when it's incidental to the real work. It's just not worth it to save a few bucks, versus hosting a Git repo yourself on a VPS or something.

I think you can preload them or just wait and it will preload them and then you can play it around 10FPS which is as fast as you'd want to in order to catch all the action, but doing this manually with images in a viewer would be pretty tedious, I would think.

It's quite clever actually, and pauses on interesting frames with dialogue, as voted by people previously? or something: https://github.com/deplicator/xkcdTime_atyourownpace/blob/ma...

Because selling C++ programmers on Java was hard enough ;)

The full discussion that quote is from is a very interesting read: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

Guy Steele suggests that even though some of the people working on Java at the time might have been ok with closures, it was a hard sell when programmers used to manual memory management in C++ were worried about whether things were allocated on the stack or the heap and how much control they had over them. Thus you get the awkwardness that is anonymous inner classes in Java, which are effectively closures, but by another name and papered over with boilerplate.

    "Actually, the prototype implementation *did* allow non-final
    variables to be referenced from within inner classes.  There was
    an outcry from *users*, complaining that they did not want this!
    The reason was interesting: in order to support such variables,
    it was necessary to heap-allocate them, and (at that time, at least)
    the average Java programmer was still pretty skittish about heap
    allocation and garbage collection and all that.  They disapproved
    of the language performing heap allocation "under the table" when
    there was no occurrence of the "new" keyword in sight."

Reading through this thread is delightful, I developed quite a lot of respect for Mr Steele.

It's not clear from your original top level post whether you've played the game and are complaining about the UI quirks described elsewhere in this thread, or if you're talking about the ASCII art.

If you're talking about the interface design, keyboard commands etc, ignore this comment.

If you're talking about the ASCII art I would say it absolutely is deliberate. DF is actually a sequel (Slaves to Armok, God of Blood, Chapter 2: Dwarf Fortress) and the first game was 3D. They chose to make DF a roguelike ASCII art game because if they had tried anything else, it wouldn't be half as deep as it is now. The ASCII art enables the depth that the game has developed.

As I said, if you are primarily arguing that they should keep the ASCII art and revamp the interface, you can safely ignore this comment.

Well, even Tarn Adams himself agrees: http://www.reddit.com/r/IAmA/comments/1avszc/im_tarn_adams_o...

I used to feel like this, until I saw Simon Peyton Jones use Comic Sans for a slide deck on Haskell and decided this was a such a petty, knee-jerk reaction to something as superficial as font-choice. At this point, I'd almost choose Comic Sans on purpose for my own presentations, just to weed out and troll the people who aren't paying attention to what matters.

http://research.microsoft.com/en-us/um/people/simonpj/papers...

edited to add: Dug up an actual comment from SPJ on this, I hadn't realized he uses Comic Sans for all his talks:

http://www.reddit.com/r/haskell/comments/1bd1ia/spj_and_comi...

Which API were you using? Java's HttpUrlConnection is notoriously badly designed [0] On Android (and elsewhere of course) you can use Apache's HttpClient instead which is a bit less horrible [1]. Part of this problem is checked vs unchecked exceptions, and some of the older APIs in Java use checked exceptions too heavily, IMHO. On top of that, I think all the Java IO stuff provides a pretty leaky abstraction over the system calls.

I had a somewhat long discussion with a colleague about this over the past year, and we looked at all the error cases in the C standard library and came to the conclusion the Java API was probably throwing checked exceptions in one or two corner cases where it should throw unchecked runtime exceptions. I'd be curious what other people think about this. I think specifically, I was asking him (a more Sr. engineer who has used Java heavily and considers it basically good) why closing an IO stream in a finally block throws another checked exception.

In short, I don't think you're doing anything wrong.

[0] See this, but I should caveat this with saying it's a bad API as designed to be consumed by an application. http://www.tbray.org/ongoing/When/201x/2012/01/17/HttpURLCon...

[1] http://developer.android.com/reference/org/apache/http/clien...

unless of course the recipes you're using are hosted on github

Yeah, the problem I was having at the time was that Homebrew was trying to fetch a tarball hosted on Github. I was just whinging though, that was the only time I've ever hit that particular snag.

The system you propose would be great, but more work than switching to running headless Linux VMs on OSX for most dev work ;) This is something I have been drifting toward for a while now, using Vagrant.

Even worse is other tools that rely on Github, like Homebrew (Mac OS X package manager) which breaks in various silly ways when Github is down.

Anyone happen to know a way around this specifically? Trying to install some stuff and brew just bails after getting 5xx from github.com.