PHP cheat: ==, ===, empty(),is_null(),isSet() - <AUTHOR> http://www.blueshoes.org/en/developer/php_cheat_sheet/

<comment><USER2> So, it's just a colorized, otherwise identical rip off of what PHP already gives you as part of their official documentation? <http://www.php.net/manual/en/types.comparisons.php>

Blogspam is the bane of the internet...

<comment><USER3> It also lacks the bolding and heavy cell borders and gutters that turn the PHP manual's table into a wall of gray noise. It's a solid improvement.

<comment><USER4> This wording...

> The PHP Documentation Group has now added the Appendix K. PHP type > comparison tables to the official PHP manual.

...seems to make the claim that the linked article came before the PHP manual's version. I'm too lazy to verify (e.g. by checking archive.org or something) though.

</comment></comment></comment><comment><USER5> I'll admit that I know nothing about PHP, but please tell me it is a mistake in the design table that they have "foo" == 0. Otherwise, we have this rather disturbing* non-transitivity of (==):

true == "foo" == 0 == false

I also generally dislike the idea of having certain values being treated as "false", e.g. 0 is false but 2.2e-16 is true... or "a" and "1" are true but "0" is false. It just seems to be clumsy, and not very robust. It reminds me of the "and-or trick" in Python, which busts if you aren't familiar with the fact that values such as 0/0.0 are false.

* Actually, on review, it's obvious that some non-transitivity is desirable by design, in the sense that 1 and 2 are both "true" but we don't want 1 == 2, even though 1 == true and 2== true. However, I still maintain that the chain I have above represents bad design.

<comment><USER6> in PHP "foo" == 0 due to how php handles type juggling - the string is converted to an integer before the comparison, with strings that don't contain numbers converted to 0. so "foo" == 0 and "0" == 0 but "1" != 0.

<comment><USER5> This makes more sense, but I still find it odd and disagreeable. I tend to prefer that my programs fail loudly, so I'd write string -> int conversion to raise an exception on seemingly non-numerical input like "foo", "ba6r.5", "pwn3d", etc. Then again, admittedly I know very little about web development. Is it not practical to do this?

<comment><USER7> There is nothing special about web development that makes implicit typecasting or returning an arbitrary value when a cast fails instead of raising an exception a good idea. Another reasonable option is to return NaN (Javascript does this) or null.

</comment></comment></comment></comment><comment><USER8> This is PHP? Sold!</comment>


As New Services Track Habits, the E-Books Are Reading You - <AUTHOR> http://www.nytimes.com/2013/12/25/technology/as-new-services-track-habits-the-e-books-are-reading-you.html?hp&_r=0

<comment><USER2> > "and help writers give readers more of what they want"

If all writers write stuff based only on what readers want to read we're doomed.

There are great books written, that were not popular at the time of publishing; but instead they became popular years and years later.

Even worse, this data will be used by publishers as a filter what kind of books to produce next, and authors may have their works rejected. For example, Orwell's Animal Farm was once rejected with the publisher saying "It is impossible to sell animal stories in the USA". Clearly the publisher had an opinion on what kind of books are (not) profitable. With this new data publishers will have even more opinions.

<comment><USER3> Since it has never been easier for anyone to publish a book of their own creation, I don't see "data publishers" as being gatekeepers.

</comment></comment><comment><USER4> My Kindle won't give me any sort of analytics for my reading. I can track my computer program use with RescueTime, my keystrokes with SelfSpy, my travels with my phone, and my heart rate, wattage, and location on my bike with my GPS, but not what and when I read on my Kindle. Does anyone know of a hack to do it? Or an e-reader that does or could be made to do it?

Separately, I'm not convinced that reading analytics would cause a big shift in what is published. Publishing houses appear to publish what turns out to be great literature mostly by accident, and as business tend to publish mostly what they believe will make them money. Analytics might help publishers make a little more money on their commercial works, but it's difficult to imagine a Flaubert, a Joyce, or even a Franzen decide to alter their vision based on some prospective sales numbers. But who knows, perhaps someone will use the technology to create something that is both profound and accessible to a larger audience.

<comment><USER5> Good thing ebooks increasingly make publishing houses irrelevant. Write a book, hire a copyeditor, and publish it yourself.

<comment><USER6> From my experience, most self-published works are far worse in quality than curated material.

The fact of the matter is that most self-publishers aren't willing to pony up the money to hire content and creative editors.

</comment></comment></comment><comment><USER7> Remove the DRM from your ebooks; convert to an open format like epub; read it with open source software on anything you like without tracking.

If you don't do this, acknowledge that you are renting a reading experience -- and pay what that's worth to you, as opposed to the price of owning a copy of a book.

<comment><USER8> Do you know of a good open source ebook reader?

<comment><USER9> Calibre is the best ebook manager. It's the iTunes for ebooks.

On Android, the FBReader.app is quite good, however you probably will want to tweak the options to get it to look as nice as the Kindle.app looks "out of the box."

On iOS, the Bluefire.app is the best of the unaffiliated apps, but I preferred to open .mobi files in the Kindle.app.

</comment></comment></comment><comment><USER10> Or just download from pirates and get high quality drm free ebooks that dont fuck around.

<comment><USER6> Yeah, everyone knows that authors make most of their money touring anyway.

Right guise?!

<comment><USER11> Why the death of DRM would be good news for readers, writers and publishers - [http://www.theguardian.com/technology/2012/may/03/death- of-d...](http://www.theguardian.com/technology/2012/may/03/death-of-drm-good- news) written by science fiction author Cory Doctorow

</comment></comment></comment><comment><USER12> _What writer would pass up the opportunity to peer into the reader's mind?_

Hemingway, Faulkner, Dickens, Twain, Thoreau, Capote... (I can go on and on, but you kinda get the idea.)

Do you honestly think that great writers ever gave a shit about what people wanted?

Or did they just write what channeled through them?

This technology vividly demonstrates the #1 flaw of social:

WhatPeopleWant != Quality

<comment><USER13> > _Writers and people who had command of words were respected and feared as > people who manipulated magic. In latter times I think that artists and > writers have allowed themselves to be sold down the river. They have > accepted the prevailing belief that art and writing are merely forms of > entertainment. They're not seen as transformative forces that can change a > human being; that can change a society. They are seen as simple > entertainment; things with which we can fill 20 minutes, half an hour, while > we're waiting to die. It's not the job of the artist to give the audience > what the audience wants. If the audience knew what they needed, then they > wouldn't be the audience. They would be the artists. It is the job of > artists to give the audience what they need._

\-- Alan Moore

How many hack writers can hustle in the non-existing wriggle room between this and what Bill Hicks said about artists suc^H^H^Hselling out? Whenever I pull up the analytics dashboard, it just reads "way too many".

</comment></comment><comment><USER14> I've been thinking for many years about e-readers and the consequences of tracking user reading behaviors. One likely outcome is that it will result in a wave of "pop literature". As I understand it, pop music is already heavily customized to appeal to the masses based on tracking loads of data, going as far as analyzing past hits to identify the combinations of tunes, vocals, instruments and audio effects that work best to create new hits. Record labels and producers apparently have it down to a (data) science.

Some may point out that mass-produced "pop literature" is not really new: for instance, the entire Hardy Boys/Nancy Drew series was just that. However, since this is not a widespread practice so far, (almost) nobody has complained about it.

But once this data starts getting used more and more, and feedback loops get more efficient, eventually pop literature may suffer from the same criticisms as pop music. In a way it's good: you're giving the customers what they want. But it also has the downside that creators will shape themselves to their audiences rather than express themselves freely, limiting the variety and individuality of creative output. As long as enough creators choose the latter at least once in a while, I think it's a worthwhile tradeoff.

However, this is just the low-hanging fruit and does not explore the full potential of e-readers. E-readers need not just be dumb terminals that phone home with reader behavior -- they're fully capable general-purpose computers, and we should use them as such! We should be thinking of e-readers that "adapt" to the reader and the material. And not just an "average reader" profiled aggregately over an entire audience, but individual readers. Let the authors freely express themselves, and let technology bridge the gap between the creative work and the reader.

I haven't thought it through completely, but we certainly have the technology -- things like NLP and machine learning and user profiling and heuristics can go a long way in performing basic adaptive tasks. User likes short chapters but the book has long ones? Re-segment the text to match the user's preferences! (Maybe using a variant of text tiling.) User looking for new reads? Recommend books based on similarity of reading behaviors! They could even change the language based on user profiles. User too young? Tone down the profanity! User too old? Replace "really whips the llamma's ass" with "totally funkadelic"!

Technology is, of course, not advanced enough, so we would still rely on human input to a great extent. Editorial staff (or other readers) would need to provide tons of annotations and metadata that can help e-readers adapt better.

But eventually it may happen that for the same material two users may end up having very different reading experiences.

<comment><USER15> It will breed sequelitis, a specialty of movies. And more grave-robbing of dead authors (see fourth _Millennium_ series book recently announced while Stieg Larsson spins in his grave).

<comment><USER6> Sequelitis is a problem in any creative industry.

TV shows do it, and video games do it too (biggest offenders are Call of Duty and Pokémon)

<comment><USER15> "industry" is the key word.</comment></comment></comment></comment>


Frege: A JVM pure functional programming language in the spirit of Haskell - <AUTHOR> https://github.com/Frege/frege <comment><USER2> "Frege is thought as a substitute for this missing GHC port. While not derived from any existing Haskell implementation, it is more or less equivalent to Haskell 2010. Please see the wiki page that details the differences."

So now Haskell can produce native executable code, run in a JVM and as subset of it ([https://github.com/faylang/fay/wiki](https://github.com/faylang/fay/wiki)) run in the browser. Now there is no excuse for me to NOT using Haskell ;)

Thanks for bringing Haskell to the JVM!

<comment><USER3> If you look at the differences page, it is equivalent in power, but does not have the same expression.

Pragmas now sorta start with @, and type classes are (in my opinion) kinda funky coming from Haskell.

<comment><USER4> Another difference not mentioned is given the use of recursion in Haskell and the JVM's lack of tail-call optimisation, I have to wonder how dangerous this is. I know Clojure has recur (I'm not a Clojure programmer) but unless Frege has something similar, I predict many an exploding stack.

<comment><USER5> It can compile to a loop. JVM can't optimize it for free at runtime. Scala has tail recursion elimination

<comment><USER6> What about tail calls for mutually recursive functions? My understanding is that Scala is not able to do tail call elimination in this situation. So the only situation where you can be sure that deep recursion won't overflow the stack is when a function is tail calling itself.

If Frege isn't able to do any better with mutual recursion then that might be a severe limitation on its utility. Scala users can work around the issue by writing loops manually. In a pure language, not so much.

<comment><USER7> Frege _can_ handle mutual recursion.

The only problematic point is recursion through a strict function argument, like in:

        length (x:xs) = 1 + length xs

</comment></comment></comment></comment></comment></comment><comment><USER8> As a programmer who's getting annoyed and tired of Java's boilerplate, I welcome this. I went from Haskell to Clojure to JavaScript.

I loved Haskell __the language __. What I don 't is third party libraries are usually directly or indirectly (through a dependency) tied to an OS. I've heard, even on irc's #haskell, that it's hard to reuse code unless you're on linux. Coming from Java, this is a deal breaker for me.

Then I tried Clojure. I liked it, but I found it very challenging to refactor and mentally debug my code. I missed all the benefits of static typing. core.typed seemed like an answer, but when you compare it to other languages it seems to triple the verbosity which is a real turn off.

JavaScript (via CoffeeScript) is a pretty good middle ground, but immutable state is nearly impossible. If I get lazy, it's so easy to go back to a OO/procedural style and I don't like that. That probably does have its benefits, but not when you're trying to learn a new programming paradigm.

I know very little about Scala, but I get a terrible impression from it. Where Clojure is about simplicity, Scala seems to be about complexity.

Since I learned Haskell, I wished there was a way I could use it and have it "just work" when I decide to use a library. Frege may be the answer. I've heard of it a long time ago. My concern is that I'd be 1 of 3 people who'd be using it. But nothing's perfect.

<comment><USER7> > My concern is that I'd be 1 of 3 people who'd be using it.

This concern is probably well founded. :)

And yet. Remember, you get Java source code from the Frege compiler, and once you pack up your JAR with Proguard, say, nobody will be able to tell you didn't write it in Java. (Well, slightly exaggerated, but you could have used some obscure library, who knows?)

So, if you have a small project, or some Haskell project without too many GHC extensions you want for some reason on the JVM, give it a try.

<comment><USER9> I suspect the GP is more worried about community support for the language than other people making fun of them for using it. :)

<comment><USER7> Sure, nothing can replace a big community.

OTOH, it looks like the Poster did have bad experience with Haskell community, though.

A small community is superior insofar as they are more motivated to help, and are more likely to take (critical) feedback into account.

I think it is fair to say that the Frege community (currently about 6 more or less active contributors) does its best, judging from [http://stackoverflow.com/questions/tagged/frege](http://stackoverflow.com/questions/tagged/frege) and [https://groups.google.com/forum/#!forum/frege-programming- la...](https://groups.google.com/forum/#!forum/frege-programming-language)

Of course, if someone demands, say, to implements GADTs or multi-param type classes by tomorrow, the answer will be gentle, but not affirmative.

</comment></comment></comment></comment><comment><USER10> It's interesting to compare this to CAL - an earlier Haskell-like language on the JVM that was a project of some of my former colleagues at Crystal Decisions/Business Objects back in the 00's: [http://openquark.org/Welcome.html](http://openquark.org/Welcome.html)

I've worked quite a bit with CAL over the years and it has been used for some serious work. One of my big frustrations with it though has been the clunkiness of the Java interop, especially since this is one of the reasons you might choose to use a language on the JVM.

Looking at the Frege docs, I like the look of the way this has been handled - rather than using an FFI-style approach, things like Int, String etc map directly to Java types and Java classes can be used like ADTs, which would make life way, way easier.

Given the nature of the language calling Frege from Java is always going to be more complicated but it looks like they've done a nice "fluent" Java API for calling into the runtime.

Would be interesting to see how this performs relative to CAL, in terms of both speed and space.

<comment><USER7> > Would be interesting to see how this performs relative to CAL, in terms of > both speed and space.

Indeed. Do you have some CAL installation somewhere to make a comparison? (The links I find are all broken.)

<comment><USER10> Unfortunately it looks like you would have to build from source. The best place for that would be Rich Webster's fork - [https://github.com/rdwebster/Open-Quark](https://github.com/rdwebster/Open- Quark) \- which is the version maintained by Indicee.

<comment><USER7> In the "How to build..." document it says I need Eclipse exactly 3.3.0

I am not going to install this, even if I would find it somewhere, hence ....

<comment><USER10> I imagine the documentation is completely out of date.

Anyway, if you don't want to look at it, that's your loss - while I don't think CAL has much of a future a lot of work was invested in it by a very talented team and there is probably something to be learned from it.

<comment><USER7> > Anyway, if you don't want to look at it, that's your loss

Actually, I did look into it several years back. If I remember correctly, CAL was not pure and still lazy. (An explosive combination, if you ask me.)

</comment></comment></comment></comment></comment></comment><comment><USER11> I like some of the differences where it was not constrained by Haskell's choices, like splitting up the Monad, Applicative, Functor instances, and namespacing of accessors. I also quite like the • for compose, with then some shims so that . works too if it's not being used for the namespacing.

<comment><USER12> Yeah, I'd like to see more languages using unicode identifiers. Seems to be a very unpopular approach, though :(

<comment><USER13> Haskell can do it: there's a library with common Unicode operators[1] (including ∘ for function composition) and an extension allowing you to use Unicode _syntax_ [2] (things like → in place of ->).

I've seen these things used, but they're not super common. People still worry about not being able to input Unicode symbols in their editor! I personally think this is absurd in this day and age. Naturally, it's very easy to do in Emacs; somebody even wrote a Haskell input mode[3].

[1]: [http://hackage.haskell.org/package/base-unicode- symbols-0.2....](http://hackage.haskell.org/package/base-unicode- symbols-0.2.2.4/docs/Prelude-Unicode.html)

[2]: [http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/synta...](http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/syntax- extns.html)

[3]: [https://github.com/roelvandijk/emacs-haskell-unicode- input-m...](https://github.com/roelvandijk/emacs-haskell-unicode-input-method)

<comment><USER12> Oh, nice! I setup XCompose to support rfc1345, so I have fast unicode input everywhere. I'm definitely going to experiment with that Haskell extension. I've done that manually before in ML with a preprocessor, but it was a nasty hack. A proper extension is much nicer!

EDIT: How many people still have trouble with Unicode input? Should I publish my XCompose solution?

</comment></comment></comment></comment><comment><USER14> The conclusions of [http://fregepl.blogspot.jp/2013/03/adding-concurrency-to- fre...](http://fregepl.blogspot.jp/2013/03/adding-concurrency-to-frege-part- iii.html) lead me to believe that the author knows significantly more about Haskell than about either the JVM or concurrency. I hope that the language is able to attract a healthy number of contributors in those areas before it begins to accrete it's own idiomatic concurrency patterns.

<comment><USER15> Your comment would be more useful if you elaborated on these claims.

<comment><USER14> The section on forkIO vs forkOS is interesting because the author does not mention implementing green threads atop the JVM. It would be feasible for Frege and its core libraries to use an implementation of "green threads" based on Promises or CPS under the covers in order to implement a concurrency model indistinguishable from Haskell's.

While it is true that the vast majority of JVM code you interact with is blocking and expects to own whatever OS thread it is running on, that _could_ be treated as a concern of FFI, where untrusted/blocking code in Java land gets dedicated OS threads (similar to FuturePools/execution-contexts for scala Futures, or how you would manually isolate blocking code for Erlang or Go FFI.)

Additionally, the comment dismissing STM seems like an afterthought, because there are at least three JVM implementations (Clojure's, Scala's, and Multiverse)

But the main comment I was referring to was:

      To do serious concurrent work in an JVM environment is
      different and it will thus require different knowledge

... which suggests that the author isn't interested in supporting Haskell's idiomatic concurrency model atop the JVM, and is instead fine with the status quo of blocking code.

<comment><USER7> > which suggests that the author isn't interested in supporting Haskell's > idiomatic concurrency model atop the JVM

This is not quite true (I am the author). Yet I know my limits. Every contribution from the community is welcome, OTOH.

The point of the blog posts was only to explore how far one can get with what Java has.

</comment></comment></comment></comment><comment><USER16> Cute name. I wonder to what extent the language has anything to do with Frege's work in logic. I mean Haskell's last name was Curry, and currying is a big deal in FP. Thankfully that wasn't named after Moses Schoenfinkel.

<comment><USER17> That said, I always felt that "Finkel" would be a cute name for an FP language, service or library... I call dibs!

<comment><USER18> If that's the case, maybe you should name if after Raphael Finkel. [1]

Disclaimer: I had the privilege of meeting Dr. Finkel here at university a few times before I stumbled across his name in Wikipedia and in the front of a book in the library. Totally not biased.

[1] [http://en.wikipedia.org/wiki/Raphael_Finkel](http://en.wikipedia.org/wiki/Raphael_Finkel)

</comment></comment></comment><comment><USER2> A presentation about Frege from the author itself: [http://fregepl.blogspot.jp/2013/08/talk-at-karlsruhe- functio...](http://fregepl.blogspot.jp/2013/08/talk-at-karlsruhe- functional.html)

Actually it is the link to the blog entry that contains a link to the presentation.

</comment><comment><USER19> Anything that replaces the horribly overengineered and bastardized Scala travesty is welcome.

<comment><USER20> One of the things that make the JVM so cool is the easy interoperability of most JVM languages. It's good to have languages like Java (or Kotlin), Clojure, Frege and Erjang on the JVM, each with its own strengths. Each can remain relatively simple and consistent, and all interoperate and share libraries. This is far better than that "bastardized travesty" trying to be all languages at once, and ending up an incoherent mess, retaining little of the advantages of those simple languages.

</comment></comment><comment><USER21> I really wish this was strict.

I feel like most regular programmers could understand and benefit from using ML (or some similar language).

In Haskell, laziness kept the language pure while it was developing but now I'm not sure it should be the default. I like OCaml style opt in laziness.

For most people, they could get a lot of pretty vanilla typed functional programming language. Polymorphic type inference, algebraic data-types, pattern matching. That gets you really far.

<comment><USER22> There is Yeti ([http://mth.github.io/yeti/](http://mth.github.io/yeti/)), a JVM language from the ML family. I think it's close to a 1.0 release, and the compiler has been pretty reliable for a while now. I find it a delight to use.

</comment></comment><comment><USER23> I'm excited about this - but cannot seem to find a 'hello world' or any other actual code examples?

\--Edit-- is it the exact same syntax as Haskell? Unclear.

<comment><USER24> have a look at: [https://github.com/Frege/frege/tree/master/examples](https://github.com/Frege/frege/tree/master/examples)

</comment></comment><comment><USER25> The author Ingo Wechsung outlines the ideas and concepts of Frege in the German blog 'Funktionale Programmierung': [http://funktionale- programmierung.de/2013/10/10/frege.html](http://funktionale- programmierung.de/2013/10/10/frege.html)

</comment><comment><USER26> As an analytic phil PhD dropout _and_ a Haskell lover I can say with confidence that (a) Gottlob Frege (the philosopher) was awesome (I still want a 'morning star != evening star' tattoo) and (b) Frege sounds lovely too. I'd actually considered writing something similar.

</comment><comment><USER27> simplified one here too - [https://github.com/lwm/functional- java/blob/master/src/test/...](https://github.com/lwm/functional- java/blob/master/src/test/nonStrict/HigherOrderTest.java)

</comment><comment><USER28> Looks really cool! Oh, it runs on the JVM. Hm, too bad.

<comment><USER29> What would you prefer? A language that doesn't need a runtime, like C? A language that has only one available runtime, like node.js? A language that has a choice of runtimes but there are incompatibilities between them like Python or Ruby? A language that has a choice of runtimes from a choice of vendors like Java?

<comment><USER28> A runtime that can be used for a wide-variety of types of applications. JVM can really only be used for writing web servers and possibly daemons.

<comment><USER30> And building Twitter [1], and big-data next-generation databases [2], and android apps, and desktop apps, and big data [3], and as a platform for new languages (Clojure, Scala, Frege), and many more applications.

Really, the JVM can be used for anything that _computers_ can be used for, and it does so in a way that the code is runnable across all major platforms and still maintains a top-5 language performance spot, even beating C/C++ in some specific cases.

Why do you feel that the JVM is limited in its applications as a development platform?

[1] [http://blog.redfin.com/devblog/2010/05/how_and_why_twitter_u...](http://blog.redfin.com/devblog/2010/05/how_and_why_twitter_uses_scala.html) [2] [http://www.datomic.com/about.html](http://www.datomic.com/about.html) [3] [http://hadoop.apache.org/](http://hadoop.apache.org/)

<comment><USER28> > And building Twitter [1],

Web server.

> and big-data next-generation databases [2]

Daemon.

> and android apps

No, Android doesn't have a JVM.

> and desktop apps

If you say so, I see very few of these in production.

> and big data

Daemon.

> Why do you feel that the JVM is limited in its applications as a development > platform?

You can't write cli applications in a JVM language because the start-up time is too slow. Which means you can't compose scripts that call Java apps.

This is not just 1 type of application, it's the most important type of application by far. It's fundamental to how Unix operates. With Java you can't write small applications that do one thing well, you have to write big applications that are going to run for a very long time.

This is useful for things like web servers and daemons, but otherwise it sucks. It's why I can't get excited about JVM languages.

<comment><USER30> > You can't write cli applications in a JVM language because the start-up time > is too slow. Which means you can't compose scripts that call Java apps.

You're right. In the case of small, fast applications designed to be called as part of shell scripts, the JVM does suffer start-up costs. Some testing on my personal machine shows the JVM to be 2x to 8x slower than a comparable Ruby or Python script in startup time. [1] Depending on the script, that startup time may or may not acceptable, and if the script runs for longer than a second, which is entirely possible for anything that goes beyond the local machine, the JVM will get progressively faster.

> This is not just 1 type of application, it's the most important type of > application by far.

This needs more explanation. I've used Unix for many years, and I've definitely bought in to its philosophy of small and composable; It's a philosophy that in many ways mirrors functional programming. However, in my opinion, the most important type of application varies considerably by person. For you, the small, single-purpose applications may be what you use most.

And I agree, if you're programming for the Unix platform, the JVM would not be the best choice. Unix was built on C. A program that builds on that platform is probably a better choice.

But there are many more applications out there, and for any command-line program that operate in a time domain longer than 10 seconds, the JVM startup costs are mostly eliminated. This time-domain is very plausible for a command that operates on medium-scale databases or anything with network connectivity.

It's silly to completely dismiss an entire platform because it is not the absolute best choice for a single domain of programs.

I'm curious: What do you do where the short-lived, composable Unix functions are the most important programs?

[1] [https://gist.github.com/bostwick/8ee1d4df9c7743f9efed](https://gist.github.com/bostwick/8ee1d4df9c7743f9efed)

<comment><USER28> I think we simply approach software different. I feel that small, composable applications should be the default, and I nearly always start off this way. I've been involved in projects from writing a specialized version of cp, ETL processes, to developer focused but consumer-facing web applications and the first interface I write to anything I do is as a small cli application that works well with standard unix tools.

When you embrace this philosophy it doesn't particularly matter how good a language's ecosystem is, you have all of unix to interop with. For example, I don't care if a language has a good JSON parsing because jq[1] exists and is probably faster and easier to work with than just about any language's built in tools, even better than JavaScript itself.

With JVM you can't participate in writing software this way. Everything must revolve around the JVM and it's ecosystem.

[1][http://stedolan.github.io/jq/](http://stedolan.github.io/jq/)</comment></comment></comment></comment></comment></comment></comment>


Show HN: AutomateYourDate.com - Outsourcing your dating - <AUTHOR> http://www.automateyourdate.com

<comment><USER2> I know for a fact that this girl [[http://automateyourdate.com/testimonial/automate-your- date-t...](http://automateyourdate.com/testimonial/automate-your-date- testimonial-4/)] is on fiverr.com

<comment><USER3> Are you suggesting that they paid her to record a false testimonial?

</comment></comment><comment><USER4> I legitimately thought this was satire at first.

<comment><USER5> Is it not? I still can't tell

<comment><USER6> Probably not, although the post dated July 5th that states "the holidays are upon us" indicates to me they aren't very serious about quality.

</comment></comment></comment><comment><USER7> The question that I've got is what is your surrogate going to tell the girl in order to get you a date? You know the only way they can go viral is to start getting men dates.

What happens when the girl finds out that you're not Tom Cruise's younger brother who just sold his startup to Google? This makes much better sense as a reality TV show. Poor Allen Funt would be horrified.

Ref: [http://en.wikipedia.org/wiki/Allen_Funt](http://en.wikipedia.org/wiki/Allen_Funt)

</comment><comment><USER8> Not sure if this is the way to win the hearts of prospective partners: caring little about the approach as to outsource personal interactions.

I imagine there's room for improvement in online dating, and can see professional help being a viable service (tips on profiles, photographer, suggesting people to contact or automating some initial contact) but I don't know if this would appeal to people?

<comment><USER9> There's a market because online dating is a funnel process. In large markets, there are thousands of potential female matches and tens of thousands of potential female matches.

The funnel from initial message to reply is brutal. The funnel from conversation to date is also brutal. Relying on mass messaging has a terrible conversion rate. So you need relatively specific messages, and lot of them, to get as far in the funnel as "first date".

Some people feel that they don't have time for that nonsense. Along comes an English lit grad who needs some extra cash ...

</comment></comment><comment><USER10> It might be nice if the picture of the couple at the beginning actually rotated/fade-in/out between "traditional" image of a couple, interracial, same-sex, etc.

</comment><comment><USER9> Dating is not a "solvable" problem because asymmetric information and asymmetric supply/demand meaning that the solutions to the Stable Marriage Problem aren't applicable.

[http://en.wikipedia.org/wiki/The_Market_for_Lemons](http://en.wikipedia.org/wiki/The_Market_for_Lemons)

[http://en.wikipedia.org/wiki/Supply_and_demand](http://en.wikipedia.org/wiki/Supply_and_demand)

[http://en.wikipedia.org/wiki/Stable_marriage_problem](http://en.wikipedia.org/wiki/Stable_marriage_problem)

"Outsourcing" just makes the informational asymmetry worse. It's a negative- sum strategy. Hooray.

</comment><comment><USER11> LOL</comment>


JavaScript Needs Blocks - <AUTHOR> http://yehudakatz.com/2012/01/10/javascript-needs-blocks/

<comment><USER2> > In order to have a language with return (and possibly super and other > similar keywords) that satisfies the correspondence principle, the language > must, like Ruby and Smalltalk before it, have a function lambda and a block > lambda. Keywords like return always return from the function lambda, even > inside of block lambdas nested inside.

In case you want to get your google/wikipedia on, what Katz is talking about here is a "non-local return". Normal returns return from the immediately enclosing (i.e. local) lambda/fn/block/thing. Non-local ones unwind past multiple enclosing functions to cause an outer one to return.

In Smalltalk, the distinction is between methods and blocks. A return expression always returns from the enclosing _method_ and will unwind past any blocks that the return expression is contained in.

In Common Lisp, I believe you name functions and then indicate the name of the enclosing function that you want to return from by doing `(return-from <fn name> 3)`.

I thought non-local returns were a bit impure and kind of a weird language novelty for a while. Recently, I added them to a hobby language of mine (Finch) and then wrote some code that uses them.

Holy crap are they awesome.

Being able to early return is, I think, one of the things that's really handy about imperative languages. I use it all the time in my code. But that cripples your ability to define your own flow-control-like structures that take functions.

For example, here's some code that sees if an array contains a given item using a for loop:

        function contains(array, seek) {
          for (var i = 0; i < array.length; i++) {
            if (array[i] == seek) return true;
          }

          return false;
        }

Let's say you don't like doing an explicit C-style loop and you want to make your own forEach() control-flow-like function:

        function forEach(array, callback) {
          for (var i = 0; i < array.length; i++) {
            callback(array[i]);
          }
        }

Now we try to refactor `contains` to use it:

        function contains(array, seek) {
          forEach(array, function(item) {
            if (item == seek) return true;
          });

          return false;
        }

Crap, that doesn't work. There's no easy way to make `forEach()` stop early unless you go out of your way to make it support that by having the callback return some magic sentinel value. Or you do something hideous like throw a "return" exception.

Non-local returns solve this neatly and end up being pretty delightful to use in practice.

<comment><USER3> This problem doesn't exist:

        // returns true/false
        array.some(function(item){
          item === seek
        })

Your "magic sentinel value" would be a Boolean, which is exactly how `some` is implemented:

       function forEach(array, callback) {
          for (var i = 0; i < array.length; i++) {
            if (callback(array[i]) === true) break;
          }
        }

<comment><USER4> Let's modify the GP's example--instead of checking if an array contains something, he wants to return a copy where a callback is applied to each element. Kind of like "map". However, if the array contains other arrays, he wants to return an empty array.

No problemo in Ruby:

      def map_unless_nested(arr)
        arr.map {|v| return [] if v.is_a? Array; yield v}
      end

      map_unless_nested([2,3,4,5]) {|v| v+1 }
      # => [3,4,5,6]
      map_unless_nested([2,[3,4],5]) {|v| v+1 }
      # => []

This starts looking ugly in JavaScript if we want to generalize "map". Either we can keep "map" clean and wrap our callback so it throws exceptions on array input:

      function map(arr, callback) {
        var ret = [];
        for (var i = 0; i < arr.length; i++) {
          ret.push(callback(arr[i]));
        }
        return ret;
      }

      function map_unless_nested(arr, callback) {
        try {
          return map(arr, function(v) {
            if (v instanceof Array) throw "nested!";
            return callback(v);
          });
        } catch (e) {
          if (e==="nested!") { return []; }
          throw e;
        }
      }

      map_unless_nested([2,3,4,5], function(v){ return v + 1; })
      // => [3,4,5,6]
      map_unless_nested([2,[3,4],5], function(v){ return v + 1; })
      // => []

Or, if we want to keep the callback clean, we have to start fiddling with map, and then it's no longer really just map (it's map with halting parameters), and then you're using special return values to inform calling functions that the halting condition was met.

      function map_unless_test(arr, callback, test) {
        var ret = [];
        for (var i = 0; i < arr.length; i++) {
          if (test(arr[i])) { return false; }
          ret.push(callback(arr[i]));
        }
        return ret;
      }

      function map_unless_nested(arr, callback) {
        return map_unless_test(arr, callback, function(v) {
          return v instanceof Array;
        }) || [];
      }

If you still think that exceptions are the best language feature to solve this example, consider the situation where you want to do something with those nested arrays. For example, let's take the Ruby example and modify it so it will return a copy of the first-encountered innermost array with the callback applied.

      def map_first_innermost(arr, &block)
        arr.map do |v|
          return map_first_innermost(v, &block) if v.is_a? Array
          yield v
        end
      end

That was easy. You can see that non-local returns become useful very quickly.

<comment><USER3> They look useful from a specific mindset. How about these?

        function map_unless_nested(arr, cb){
          var res = []
          var has_nested = arr.some(function(item){
            if (item instanceof Array) return true
            res.push(cb(item))
          })
          return has_nested ? [] : res
        }

        function map_first_innermost(arr, cb){
          var res = []
          var has_nested = arr.some(function(item){
            if (item instanceof Array) return true
            res.push(cb(item))
          })
          return has_nested
            ? map_first_innermost(res[res.length-1], cb)
            : res
        }

<comment><USER4> Well, now you're dodging the spirit of the problem, which was to work through a single generalization of "map" (or, as tweaked in the second try, "map_unless_test") that is responsible for executing the callback and collecting the results into a new array. Here you are doing the result- collection on your own. You can't express these functions elegantly if you are required to silo the .push(cb(item))-ing into a separate "map" or map-like function.

That's not an outlandish requirement; imagine that the callback can be expensive, and we would like to be able to adjust a centralized "map" function later so it farms things out to different processes/workers/etc.

To solve this for map_first_innermost, you'd have to throw an exception with the nested array, but this is just getting hideously ugly.

      function map_first_innermost(arr, callback) {
        try {
          return map(arr, function(v) {
            if (v instanceof Array) throw {itWasNested: v};
            return callback(v);
          });
        } catch (e) {
          if (e.itWasNested) {
            return map_first_innermost(e.itWasNested, callback);
          }
          throw e;
        }
      }

<comment><USER5> I think you're inventing specific requirements to win a debate. So essentially "I can imagine a scenario that would hard for you to accomplish". Are you saying there is no scenario you can fathom that's difficult to accomplish in ruby? If that's that's the case, you should probably be lobbying to replace javascript with ruby. Not to spend lots of time and effort and pain to turn javascript into ruby.

<comment><USER4> Of course there are scenarios that are difficult in either language. And lobbying to replace JavaScript with Ruby (I assume you mean in web browsers?) is simply madness for a host of reasons that aren't worth repeating. Lobbying for blocks in JavaScript is sensible, though, since it is actually being considered for the new spec.

It sounds like you think my requirements are contrived. If you prefer to use functions as iterators in JavaScript, and who doesn't (unless you like polluting methods with counter variables?) ... there is no way to have iterators halt early without throwing exceptions or coming up with special return values. _Every_ programmer needs to iterate and break out of loops. It is easy to break from iterator functions in Python and Ruby, since the languages natively support this concept. JavaScript doesn't--that's all we're saying, and it _would be nice_.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I can't take Katz' suggestions for JavaScript seriously. He desperately wants JS to be his blub (ruby) and doesn't seriously think about how to accomplish his goals with what the language provides.

> There are two very common problems here. First, this has changed contexts. > We can fix this by allowing a binding as a second parameter, but it means > that we need to make sure that every time we refactor to a lambda we make > sure to accept a binding parameter and pass it in. The var self = this > pattern emerged in JavaScript primarily because of the lack of > correspondence.

 _Or_ , you could use Function.prototype.bind where it's needed. Only functions where an execution context is frequently provided should accept an execution context (as sugar, basically), and it's generally better to assume prudent use of bind(). But I guess I'm crazy.

He then proposes a wholesale change to function semantics in the language. There are no "acrobatics" performed if you want to return a value passed to forEach(). You just enclose a variable and assign from within the callback. Any experienced JS dev will tell you that the disadvantage of forEach() and relatives is _not_ that you can't easily return, but rather, that you can't easily _break_. However, proponents of a functional style would argue that you should be filtering your list first so that you only have to deal with interesting values, and so that there is no need to break: If you need `break`, use for ()!

I mean, come on, this is the same guy who wrote a reopenClass function in Ember.js -- for a language with plainly open prototypes.

This is nothing but a post glorifying Ruby and bashing JS for not being Ruby. There are plenty of valid nits to pick with JS, but being unlike Ruby is not one of them.

<comment><AUTHOR> _He then proposes a wholesale change to function semantics in the language._

Actually, I linked to a proposal by Brendan Eich, the creator of JavaScript.

 _I mean, come on, this is the same guy who wrote a reopenClass function in Ember.js_

JavaScript's open prototypes suffer from the inability to define a number of new properties at once using an object literal. reopen (not reopenClass), provides that functionality.

 _This is nothing but a post glorifying Ruby and bashing JS for not being Ruby_

Nope. It's a post glorifying the correspondence principle, which Smalltalk and Lisp had before Ruby, and arguing that JS would be better with it.

<comment><USER6> > Actually, I linked to a proposal by Brendan Eich, the creator of JavaScript.

Naming names doesn't change the idea: It is surely a wholesale change to function semantics in the language.

> JavaScript's open prototypes suffer from the inability to define a number of > new properties at once using an object literal. reopen (not reopenClass), > provides that functionality.

Sure, that's why you use a general-purpose merge function, prototypes just being objects themselves.

      var merge = function(o, o2, force) {
          for (var p in o2)
              if (o2.hasOwnProperty(p) && (!(p in o) || force))
                  o[p] = o2[p];
          return o;
      };

      var C = function() { /* ... */ };
      merge(C.prototype, {
          foo: function() { /* ... */ },
          bar: function() { /* ... */ }
      });

In any case a name like reopenClass() sounds very much like an attempt to make JS smell like Ruby even if all the function does is perform a merge.

<comment><USER7>
      I can't take Katz' suggestions for JavaScript seriously.
      ...
      Naming names doesn't change the idea.

I'm confused! Are we judging ideas by the source or by their merits?

<comment><USER6> He named a name rather than challenge the suggestion ... I named a name to show that I am noticing a common quality in Katz' recent foray into JavaScript, that being his desire that it be like Ruby, the language for which he's best known.

<comment><USER8> That's not what happened. You started out with "I can't take Katz' suggestions for JavaScript seriously." and he pointed out that it wasn't his, but Brendan Eich's proposal.

To which you answered "Naming names doesn't change the idea."

</comment></comment></comment></comment></comment></comment><comment><USER9> By the way, Google seems to think that it's called _Tennent's_ Correspondence Principle, not _Tennet's_. Might be helpful to those who, like me, hadn't heard of it.

<comment><AUTHOR> Fixed in the original post. Thanks for letting me know about the typo!

<comment><USER10> It's described briefly in R. D. Tennent's Book _Principles of Programming Languages_ , but it doesn't really go into much depth about the ramifications. Did Tennent write a paper with more discussion of the principle?

(I got a hold of a copy after I ran into the topic previously: [http://blog.marcchung.com/2009/02/18/how-closures-behave- in-...](http://blog.marcchung.com/2009/02/18/how-closures-behave-in-ruby.html) )

</comment></comment></comment><comment><USER11> Doesn't Coffeescript 'solve' this problem? (quotes because of the coffeescript vs javascript debate)

The binding of this is solved with => (fat arrow), and the returning value is resolved with the fact that both the inner function and outer function will return their result (I think? :\\) and thus the refactoring is essentially equivalent to the ruby version?

Anyone else read this as "Ruby guy wants javascript to be more like ruby." ?

</comment><comment><USER12> Weird question, can one download the 'source' to JavaScript, compile and therefore built on top of it? I guess I have never thought about it, it is free, is it open too?

<comment><USER13> v8: <http://code.google.com/p/v8/> TraceMonkey: <http://hg.mozilla.org/tracemonkey> rhino: <http://www.mozilla.org/rhino/> IE: n/a

<comment><USER14> knowtheory was right, follow the MDN SpiderMonkey links to <http://hg.mozilla.org/mozilla-central/js/src> \-- beware that <http://hg.mozilla.org/tracemonkey> is an inactive repo.

</comment></comment></comment><comment><USER15> I'm confused, aren't blocks just a hack around a lack of first class functions and/or closures?

The actual complaint seems to be that JavaScript's scoping rules are different to his expectations and 'this' binding is, well, we know.

<comment><USER7> No, blocks are not a hack around first-class functions. Let's talk about "what we're making first-class." A first-class function is something we both understand: A thingy with its own variable scope, its own notion of "this," some parameters, and some executable code that may or may not return a result.

So what is a block? That's easy in JavaScript. Here's a block:

      if (foo === bar)
      // The block starts here v
      {
        return foo;
      }
      // The block ends here ^

Blocks are the chunks of executable code living _inside_ of a function. They aren't functions! They share their enclosing function's scope. They share their enclosing function's notion of "this". You can't "return" from a block, if you execute a return form a block, you return from the surrounding function.

Blocks _already exist_ in JavaScript, but at the moment they only exist for built-in keyword construct like "if" and "for." Yahuda is simply explaining why it would be valuable to create a way to pass blocks to functions. The blocks would continue to be associated with their enclosing function invocation, unlike passing a function.

To summarize, JavaScript already has first-class functions, and it already has blocks, this proposal concerns a way to make blocks first-class. Blocks are not a hack around first-class functions, they're something else that JavaScript already has.

<comment><USER6> Actually, while it's almost never used (I certainly haven't seen code using it), blocks cooperate with labels too. The following is perfectly valid:

      var fn = function() {
          nowWeDance: {
              dance();
          }
      };

The block uses the same execution context and scope, of course, so it's not useful.

A block is legal alone too:

      (function() {
          {
              return 1;
          }
      })(); // 1

I suppose for a very long switch statement (god forbid), blocks could be useful:

      switch (x) {
          case 1: {
              // do stuff
              break;
          }
          case 2: {
              // do stuff
              break;
          }
      }

But I wouldn't favor it because it makes the break seem implicit to the reader when it in fact is not.

</comment></comment></comment><comment><USER16> Here's a question about blocks: should they even have return values? I was wondering about that because (1) they are supposed to have an equivalence with a code sequence and code sequences don't have values and (2) one awkward difference between blocks and closures is that a closure can return a value early whereas a block can only (as I understand) return the last value of its body.

Edit: Also, as I think about it, one could maybe argue that closures are to expressions as blocks are to statements. In which case, it seems that blocks should never be bound to values but things that invoke blocks should only be able to do so as in the Ruby 'yield' where the block is implicit. You could then avoid the whole escaping problem.

Edit: And further, a thing which invokes a block should maybe belong to yet another category from closures and blocks? In a sense, such a thing is analogous to:

        for (...)

or

        if (...)

In other words, such a thing is half-a-statement. You have to append a block to make a whole statement. :)

</comment><comment><USER17> Here is another way to refactor that example in JS -

        // constructor for the FileInfo class
        FileInfo = function(filename) {

          function withFile(block) {
            var f;
            try {
              f = File.open(filename, "r");
              return block(f);
            } finally {
              f.close();
            }
          }

          this.mtime = function () {
            var mtime = withFile(File.mtime);

            if (mtime < new Date() - 1000) {
              return "too old";
            }

            sys.print(mtime);
          };

          this.body = function () {
            return withFile(function (f) { return f.read(); });
          };

        };

An advantage with this refactoring is that the file handle, which isn't required after getting the mtime, is closed before doing other things.

</comment><comment><USER18> Interestingly, there are places where even Ruby doesn't follow Tennent's Correspondence Principle: the next and break keywords. They always act on the innermost block.

</comment><comment><USER19> +1 For some kind of keyword for Return-from (Although could be emulated with exceptions).

-1 For adding block syntax.

<comment><USER8> Why? Adding a new keyword also means adding new syntax and also will break stuff, e.g.

      var new-return-from-keyword = "test";

<comment><USER19> Its not about "breaking stuff". Its about keeping the language as small as possible. Part of JS's success is being small as a language.

[EDIT]

For example you could teach functions to beginner programmers once. And could then easily introduce lambdas/callbacks/generators(And maybe block lambdas) without introducing much new syntax.

</comment></comment></comment><comment><USER16> Alternate formulation with hypothetical shift/reset (delimited continuation support) and blocks that return the same way functions do:

        mtime: function () {
          return reset {
            var mtime = shift (succeed) {
              this.withFile ({ |f|
                var mtime = this.mtimeFor (f);
                if (mtime < new Date () - 1000) {
                  return "too old";
                }
                return succeed (mtime);
              });
            };
            sys.print (mtime);
            return "young enough";
          };
        },

The succeed function is a first class, indefinite-extent function equivalent to:

        function (mtime) {
          sys.print (mtime);
          return "young enough";
        }

It's the computation within the reset block that comes after the shift form is evaluated.

Calling it after returning from the method would not raise an exception.

Edit: Keep blocks with 'this' inheritance (I had originally used a standard closure).

<comment><USER14> Delimited continuations are not gonna happen. See [http://wiki.ecmascript.org/doku.php?id=strawman:shallow_cont...](http://wiki.ecmascript.org/doku.php?id=strawman:shallow_continuations), [http://calculist.blogspot.com/2010/04/single-frame- continuat...](http://calculist.blogspot.com/2010/04/single-frame- continuations-for-harmony.html), and [http://calculist.org/blog/2011/12/14/why-coroutines-wont- wor...](http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the- web/).

<comment><USER16> Thanks for the links. It's neat to see such things being considered. My feeling is that such complicated language devices are out of place in JavaScript but it was fun to run the experiment.

While I'm thinking about it... I wonder about the choice to overload/reuse the keyword 'return' in the blocks proposal. Any thought on using something else to emphasize the distinction in semantics?

Edit: Nevermind. That would break the Tennent Correspondence Principle wouldn't it? Bad idea.

</comment></comment></comment><comment><USER20> To play devils advocate here... This specific example could be solved with implicit returns in Coffeescript:

        class FileInfo

          constructor: (@name)->

          mtime: ->
            #implicit return
            @withFile (f)->
              if f.time isnt 999 then "too old"

          withFile: (block)->
            try
              block
                name: @name
                time: 1000
            finally
              console.log 'finished'

        f = new FileInfo('name')
        console.log f.mtime()

#finished

#too old

</comment><comment><USER21> Doesn't most of this apply to Python anonymous functions?

<comment><USER22> Technically python doesn't have closures, which is what he's talking about here. Python has lambdas, which are a sort of crippled version of anonymous functions.

[http://mail.python.org/pipermail/python-3000/2006-November/0...](http://mail.python.org/pipermail/python-3000/2006-November/004395.html)

EDIT: of course the replies are correct. i suppose it was unclear what the parent meant by "anonymous functions". if he meant lambdas, then they are indeed closures but without the same capabilities as normal python functions. their capabilities are unrelated to the fact that they're anonymous or closures.

<comment><USER23> Technically Python has what I like to call "Java closures" (although I admit that is not really fair). In Python the body of an anonymous function (lambda) can only be an expression and the bindings closed over by a named inner function are immutable. You can get around the second limitation with a single element list and this is the same way you get around Java's limitation that a local variable referenced by an anonymous inner class be final.

<comment><USER24> The single element list is no longer necessary w/ Python 3's nonlocal keyword (along w/ the old global keyword)

</comment></comment></comment></comment><comment><USER25> I might be missing something, but it seems to me like @wycats examples could be done quite easily in JS with a few extra return statements and the use of Function.prototype.bind. CoffeeScript handles that quite nicely with its `=>` binding syntax and implicit returns as well if you're into that. <https://gist.github.com/1593480>

</comment><comment><USER3> Why do Tennent's Correspondence and Abstraction Principles matter? That's missing.

<comment><USER26> From the article:

 _This is also known as the principle of abstraction, because it means that it is easy to refactor common code into methods that take a block._

I can attest that quickly refactoring code in Ruby is much more straightforward than in JavaScript. In practice, a small reduction in cognitive load means that it's easy to just do it now, instead of putting it off (to the point it never gets done).

</comment></comment><comment><USER27> JavaScript needs fibers and futures, asynchronous programming is incomplete without that. Happily Node supports that with <https://github.com/laverdet/node-fibers/>

</comment><comment><USER28> You forgot haskell and erlang, they need blocks too!

</comment><comment><USER29> No. What Katz really needs is not blocks, but RAII. See Python's with statement or C#'s using statement.

<comment><USER30> You can do RAII using `with` or `using` blocks, but you can't control execution with those like you can with blocks - the body of the `with` or `using` statement will always execute once. You can't prevent it from executing (unless you throw an exception), and you can't re-execute it with different values in the `as` clause.</comment></comment>


The Future of AI Looks Nothing Like Software Development (As You Know It) - <AUTHOR> https://medium.com/@matt__way/the-future-of-ai-looks-nothing-like-software-development-as-you-know-it-f7d6358c864b <comment><USER2> I think it isn't all about deep learning and the things that are trendy today, to have modules that fit together the issue of shared semantics needs to be addressed, so I think there will be something that looks a bit like the old symbolic AI together with modules based on neural networks and other methods like that.

</comment><comment><USER3> Very true. Most of it has to do with coding that involves prediction, statistical analysis, vector similarity and other experimental techniques that involve approaches outside the box of formal methods encapsulated in off-the- shelf libraries.</comment>


The Guantánamo in New York You're Not Allowed to Know About - <AUTHOR> https://theintercept.com/2016/02/05/mahdi-hashi-metropolitan-correctional-center-manhattan-guantanamo-pretrial-solitary-confinement/ <comment><USER2> That's just one. How many more of such places do we maintain here in the US and other places around the world?

<comment><USER3> Well, there's Homan Square in Chicago for one...

[http://www.theguardian.com/us-news/2015/feb/24/chicago- polic...](http://www.theguardian.com/us-news/2015/feb/24/chicago-police- detain-americans-black-site)

</comment></comment><comment><USER4> This is shameful and horrifying. How are these SAM speech restrictions even legal? Do these apply widely throughout the corrections system, or are they really mostly abused in "terror" cases?</comment>


Ask HN: Any suggestions for a better podcast app than the Apple iOS app? - <AUTHOR> I'd like a podcast app that:
 does not auto download any podcasts - plays only on demand
 does not retain downloaded podcasts, clogging up my free space
 does not stall to the point of freezing when updating podcasts <comment><USER2> Overcast seems to satisfy all of your requirements.</comment>


Are there any examples for running Docker applications on vSphere? - <AUTHOR> Are there any examples for running Docker applications on vSphere? <comment><USER2> Absolutely. You should check out this blog post from DCHQ. It seems it supports Photon as well. [http://dchq.co/2/post/2015/11/deployment-automation- of-docke...](http://dchq.co/2/post/2015/11/deployment-automation-of-docker- java-application-on-vsphere-and-photon.html). Here's the detailed documentation for setting up fully elastic Docker clusters on vSphere. [http://dchq.co/docker-vsphere.html](http://dchq.co/docker-vsphere.html)

</comment><comment><AUTHOR> Thanks for your help Dockerman!!!</comment>


Traditional Systems vs. Actor Based Systems - <AUTHOR> http://feederio.com/book/23/designing-reactive-systems <comment><USER2> When it comes to Actors Model implementation e.g. Akka, it can be very tricky to get it right.</comment>


Introduction to PageRank - Michael Nielsen - <AUTHOR> http://michaelnielsen.org/blog/lectures-on-the-google-technology-stack-1-introduction-to-pagerank/

<comment><AUTHOR> Submitted because of the discussion here:

<http://news.ycombinator.com/item?id=2012339></comment>