jonsterling

Not to mention, at least as a musician you may create some beautiful things, even though people may not appreciate them. With a startup, you may not do anything of the sort. It only makes sense if it makes you a lot of money, and that's not likely for most founders.

Wow, this sounds like an incredibly unhealthy way to work. I look forward to seeing the inevitable, expensive failure & blowback.

<3 bob harper

Related: http://tardis.wikia.com/wiki/Horror_of_Fang_Rock_(TV_story)

Yeah (though I don't agree with the Torvalds comment), I basically agree. “Write-only” means “I am the center of the universe, and the plebs should listen to what I have to say and write, but I will listen to nobody: and if you were smart, you would stop listening to me and only broadcast, but if you are not, then you should keep reading my blog.”

It really strikes me as another variation on the Carefully Curated Instagram Feed that contains a million pictures of some hustler douche skydiving or touring Africa, or something. Building engagement with the Personal Brand, etc. I mean, everybody kind of does it, but it's a new level of narcissism to write a blog post about how “I’m going to focus on #1 right now, which is me, and the fact that I am the only one who has anything worthwhile to say.”

If you really want to focus on knowing yourself and being reflective, that's great! But don't “broadcast”. Just be silent for God's sake.

This resonates in a certain sense, but honestly I could not help but find this post incredibly narcissistic.

“Hustlers dudes” are awful.

(to be clear, when I said "I don't know about treeline", I was not expressing doubt; I just mean I have never looked at it.)

I don't know about treeline. At a previous company, we committed early on to using Parse and it was a disaster for us. Most of our problems as a company were not technical of course, but pretty much all our serious technical problems can be traced to us locking ourselves into using Parse, when it would have been 1000x easier to just put a server of our own making on Heroku and run a postgres database.

Our userbase was TINY (so you think scaling should not even remotely be an issue), but we had constant downtime with Parse; not to mention we observed between 1% and 3% of all requests to Parse failing for obscure reasons (and it was never clear if it was just our node, or if it was global). I seem to recall the Parse team fixing these, and then repeatedly rolling back their fixes since they would inevitably cause something even more catastrophic to happen. I am sure all of them were working really hard, and I don't want to say anything to make them feel bad, but honestly, the class of problems that plagued Parse (at least at the time I was familiar with it) did not inspire confidence. It is possible that it is much better now; I have not used it in months.

Parse is a lot of fun for quick prototypes and demos, and I recommend it for that if you find yourself wanting to iterate quickly and repeatedly on such things, particularly if most of your "innovation" is happening on a client (like an iOS or Android app, etc.).

Agreed, but this could have just been a tweet.

They've done a lot of good work, but it's not quite done yet. The original conjecture has not been answered in the affirmative, and there are also further questions...

Really? Might also say, “I have no spine”... There's a tricky line to walk between two different kinds of cringe--the kind that happens when someone sees you let someone walk all over you, and the kind that happens when you freak out and air your grievances.

Nice post! By the way, I'd love to see a readable/beginner's introduction to dealing with worlds in Twelf. I've read the Twelf wiki a few times, and also Harper/Licata's Mechanizing Metatheory in a Logical Framework, which are quite good—but a gentle introduction would be really nice too.

Nope! You may be able to get evaluation order out of it, but the main reason I care about strictness is not CBV evaluation order. It is the following:

1. Reasoning by induction: not possible with a lazy function space

2. Non-pointed types: also not possible in Haskell

3. Compatibility with a proper treatment of effects

It's great that you can do strictness annotations in Haskell! But they don't accord one the above facilities at all.

Hi! Thanks for writing the post. I didn't mean to criticize you for talking about what you know; I hope I was able to help give a broader perspective on some of the other issues at hand too. :)

Hi! Please feel free to email me at any time. I can't promise that I will know everything you want to know (since I only know very little), but I would be happy to help with what I do know. jon [at] jonmsterling [dot] com.

BTW, I looked at your OCaml stuff yesterday, and it seemed pretty cool.

1. that's why I qualified it "proper". Of course there is unsafePerformIO, but in the presence of laziness, this is really unsafe. as opposed to ML, where doing IO may harm your ability to reason about stuff, but it won't be unsafe.

Debug.Trace is also unpredictable; actually, it's perfectly predictable if you understand laziness, but it's still not what's really wanted in most cases.

2. ST is a single instance of an effect that can be interpreted into "pure" code. There are plenty of other effects that don't work like this in Haskell, not to mention the problem of composing them together.

So thanks for chiming in! But what you have said is not really that different from what I have said.

sgeisenh — wow! How cool. If that is the case, than that's awesome, and makes me very happy.

lps25:

> Consider the case of a set implemented as a binary tree. The type of such a set should be parametrised by the type of the elements and the ordering used. With applicative functors this is the case as your set type will be `Set(O).t` where `O` is a structure containing the type and the ordering. With generative functors each individual set type is abstract -- so the type itself is not parameterised by the ordering.

You make a good point about this not being strictly about type classes. But I'd say that the issue is only a problem in the presence of implicit resolution, since otherwise, you can just bind the result of the functor to a structure once and be done with it. It becomes an issue with type classes, because you don't have the choice to share a single structure during elaboration.

IMO, the generative version is still better for most use-cases (pure or not), but it's nice that you can have both in OCaml.

Hey, sorry... You're right, I shouldn't have said this. Over the past few days, certain parts of the Haskell community have been particularly vicious (toward me and others), and I have been feeling a bit beleaguered. I shouldn't have brought it here though. Cheers.

There is a weak form of modularity which can be achieved by using two parts of haskell:

1. hiding constructors in files 2. type classes

But it doesn't really begin to approach the kind of structuring that is possible in an ML-like system. Unfortunately, the issue is very (needlessly) controversial, and I don't think I want to get dragged into it here.

I'll mention, though, that Haskell does have one form of modularity which ML doesn't really, which is the fact that you can write algorithms separately, compose them together after the fact, and expect to get reasonable performance in most cases. This is because of two things: haskell is non-strict, and GHC has pretty good fusion. In ML, you often end up manually fusing things together in order to get good performance, so composition can be a bit more difficult.

After numerous discussions with Bob Harper (and reading Derek Dreyer's work, who has been the biggest proponent for applicative functors), I have come to understand that there are only two compelling use-cases for applicative functors:

1. higher order functors.

2. modular type classes

Higher order functors are kind of cool, but IMO Standard ML does not seem to be suffering too much from the lack of them. I'm not too interested in it, since it gets super gnarly super fast, and this happens to be pretty much the main use-case for applicative functors. I suspect that most use-cases of higher order functors in OCaml could be reformulated to be first order, with a lot less monkeying around in the module system. There may be compelling use-cases though.

The other use-case is possibly a version of modular type classes that behaved a bit more like Haskell's. The idea is that if functors are going to be applied automatically during elaboration to provide something like type classes, you'll get MkWelp(S) called in multiple places, and you would prefer that any type members of the resulting structure be compatible. Applicative functors would do this.

I am not too convinced by this use-case, though I could see that people would find it useful.

In all other cases, generative functors have the correct semantics. Pretty much the whole use-case of putting abstract types in a functor is that you can then reason intensionally about them (i.e. distinguish them based on their access path). This is super useful, for instance, if you have a notion of "index" or something and you want to prevent yourself from using indexes from one table in another one, or something along those lines.

This is what the Scala people mystifyingly call "path dependent types". It's just generative abstraction.

So maybe it is an interesting feature to have applicative functors, but these should be added post facto, and generative functors should be the default. OCaml now supports generative functors if you add an extra () parameter; it's strange syntax, but it's good enough for me! :)

:) Thanks! And yes, I don't know about Anthony, but my intention has always been for Vinyl to be a proof-of-concept for what happens when you try to make a clean, minimal & well-factored HList experience; my motto is, “Now build your own Vinyl”.

Nice post! There are a lot of good reasons to use OCaml over Haskell which are more compelling than “JavaScript”, though. A few of them are:

1. modularity (and now that they have added generative functors à la SML, you can have true abstraction)

2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possibility of, e.g., using effects to implement a semantically pure interface. On the other hand, OCaml has actual effects, which can be used in an open-ended way to implement all sorts of functional interfaces.

3. strictness: arguments abound about whether laziness or strictness is better; for me, it comes down to the fact that with some pain, you can embed laziness in a strict language with effects, but you cannot embed full-on ML-style strictness into a language like Haskell; moreover, strictness-by-default permits safe uses of benign effects.

I'd call Haskell an expression-oriented programming language, since the types end up classifying expressions and algorithms (i.e. the particular "effects" you used get put into the type). Whereas I'd say (OCa)ML is a value-oriented language, since values (canonical forms) are considered separately from general expressions (canonical and non-canonical forms); moreover, implementation details don't end up in the types, so you can really consider them to be classifying values and functions (i.e. equivalence classes of algorithms, not algorithms themselves). This is largely orthogonal from strictness vs laziness, but as soon as you add partiality in, strictness becomes the only tractable way to have canonical-form-based meaning explanations for the judgements of the theory.

P.S. My day job is writing Haskell. (In case the Pedagogical Brethren wish to come and "correct" me.)

> Let's Chat is a persistent messaging application that runs on Node.js and MongoDB

nope nope nope

I came here to write a super snarky comment, but I don't have to. Thanks!

flagged for #isomorphic

I don't want to liberate the smalltalk, I want to punch it down like a sore thumb.

It's just really confusing, since it has literally nothing to do with the established meaning of "isomorphism". Also kind of cringe-y, since you know it's just JavaScript people trying to sound cool. Another commenter suggested "JS which runs everywhere"; that's cool, or I'd even suggest something more mundane like "shared code".

It's just that "isomorphism" has a very well-defined meaning, and this is essentially cargo-culting mathematical-sounding language to refer to something that has nothing to do with isomorphism at all (at least, not in the sense that the word is usually meant).

You can do all the reverse etymology you want, but in the end, we all know this is just a word that JavaScript kids are using because it makes them feel cool.

This sort of reminds me of when that weird kid nobody likes tries on a new nickname (like "The Chief" or "Serpent" or "T") and I have to kindly say, “Hey bingo/bud, I'm really sorry, that nickname is just not happening".