Dynamic languages are static languages

Originally posted on Existential Type:

While reviewing some of the comments on my post about parallelism and concurrency, I noticed that the great fallacy about dynamic and static languages continues to hold people in its thrall.  So, in the same “everything you know is wrong” spirit, let me try to set this straight: a dynamic language is a straightjacketed static language that affords less rather than more expressiveness.   If you’re one of the lucky ones who already understands this, congratulations, you probably went to Carnegie Mellon!  For those who don’t, or think that I’m wrong, well let’s have at it.  I’m not going to very technical in this post; the full technical details are available in my forthcoming book, Practical Foundations for Programming Languages, which is available in draft form on the web.

So-called dynamic languages (“so-called” because I’m going to argue that they don’t exist as a separate class of languages) are perennially…

View original 1,350 more words

Posted in Uncategorized

Artificial Intelligence, The Brain as Quantum Computer – Talk about Disruptive

Originally posted on CloudRamblings:


The AI side of the equation

I started my career studying Artificial Intelligence at MIT.  Back then the researchers thought that we would have computers that were smarter than humans in short order.  What I discovered after observing what the AI people had done was hardly anything close to “intelligence.”   Marvin Minsky called the bluff and wrote an article back in the day basically spelling out in a somewhat comical way that using the variable “learning” in a computer program didn’t mean the program learned anything.

What we have done with AI since then is to build smarter and smarter algorithms and if there is a learning variable in those programs it doesn’t mean those programs are learning anything either.    Some of these algorithms running against massive data stores like the contents of the internet and with virtually unlimited processing power can appear to produce answers to questions…

View original 6,081 more words

Posted in Uncategorized

Worse is Better vs. Better is Better

Originally posted on Andrew Myers:

In 1991 Richard Gabriel wrote a insightful and influential article about the difference in designing software systems in the “MIT Style” and “New Jersey Style” (AT&T), where he termed the latter “worse is better”. He argued that when building software, the “MIT style” of getting the design “right” (at the cost of complexity in implementation) loses out to the “New Jersey” style of keeping the design easy to implement (at the cost of giving users weaker guarantees and a more complex interface). This ease of implementation allows systems built in the “New Jersey”, worse-is-better style to acquire mindshare quickly; over time, with many interested users, they are fixed to the extent possible. As Gabriel wrote, “it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it…

View original 427 more words

Posted in Uncategorized

resto: a little api playground that just might work…


Tagged with: , ,
Posted in Development

Distributed Systems and the End of the API

Originally posted on The Quilt Project:

This is a written (expanded) narrative of the content from a talk I first gave at PhillyETE on April 23rd, 2014. It mostly follows the flow of the presentation given then, but with a level of detail that I hope enhances clarity of the ideas therein. The talk’s original slides are available, though the key illustrations and bullet points contained therein are replicated (and somewhat enhanced) below. When audio/video of the talk is published, I will update this page to link to it. Discussion about this piece has taken place on Hacker News, reddit, and Lobsters.

I have two claims of which I would like to convince you today:

  1. The notion of the networked application API is an unsalvageable anachronism that fails to account for the necessary complexities of distributed systems.
  2. There exist a set of formalisms that do account for these complexities, but which are…

View original 7,490 more words

Tagged with:
Posted in Development, distributed systems

Either monad to the rescue…

Lots of programming problems can be modeled by pipe-lining data through series of sequential or parallel processing steps. This data flow allows us to separate computational tasks into meaningful modules and
get more focused code base that is easier to debug and reason about. For example, a pipeline with three steps that takes input ‘req’ and successfully process it, would look like this:


And if at any stage there is error during the processing, we would skip the rest and return error…


Now, there are many ways to implement error handling, but this can easily end up in a messy combination of conditional statements and/or throwing and catching exceptions to stop processing. This adds noise to the real code logic and makes composing tasks harder… I’ve recently started to use Either monad to help with this this problem and am very happy about the results:

Here, I’m using Either implementation from the nice functional library Falktale

Till next time…

Tagged with: , ,
Posted in Development

functional refactoring: love when this happens

So, nice… ;)

Tagged with: ,
Posted in Development

RESTfull APIs screen-cast

Tagged with: , , , , ,
Posted in Development

Building Killer RESTful APIs with Node

Tagged with: , , ,
Posted in Development

Simple example of functional refactoring

I received a couple of request to show more examples of using functional techniques after my ‘Functional JavaScript’ workshop at Cowerks.

So, I’ll be putting out some examples – simple and to the point… Hopefully ;)

Tagged with: ,
Posted in Development


Get every new post delivered to your Inbox.

Join 325 other followers