Humanist → Blog - Latest Comments in General

Re: Why Make Erlang a Functional Language?

LukeHoersten — Thu, 04 Sep 2008 12:32:48 -0000

Thanks for the comment. Unfortunately, I know what you mean. Programmers seem to be conditioned to look for a catch-all language and languages that fit a specific domain are easily cast aside for the wrong reasons.

Re: Why Make Erlang a Functional Language?

Banador — Thu, 04 Sep 2008 06:24:35 -0000

Your site has beautiful layout and it's readable. Thank's also for information!

Too bad Erlang sucks in the shootout. It gives some wrong signals about the language to newbies.

Re: Ubuntu Nvidia Compiz “Black Window Bug” Fix

noob ubuntu — Tue, 02 Sep 2008 15:57:01 -0000

THANK YOU

Re: Fix Disqus Validation Errors on Wordpress

winstonyw — Wed, 06 Aug 2008 17:05:35 -0000

No worries man! Thanks!

Re: Fix Disqus Validation Errors on Wordpress

LukeHoersten — Wed, 06 Aug 2008 14:06:47 -0000

You are correct. We can only fix code we host. The point of the iFrame is that it's hosted and controlled by Disqus. Sorry about that.

Re: Fix Disqus Validation Errors on Wordpress

winstonyw — Wed, 06 Aug 2008 13:26:40 -0000

Hi, please correct me if I am wrong, but I think this only fixes the snippet of code that is embedded at the end of our blogs?

I am using the Firefox plugin: https://addons.mozilla.org/en-US/firefox/addon/249, and it still shows me errors with the iframe: dsq-reply-frame, which contains http://disqus.com/embed/reply.html (this is the form for adding a new comment, and in fact, this very page I am on right now while posting this, is invalid too).

Any fixes for that? Or is that beyond our control?

I have actually posted this question on the forum: http://disqus.disqus.com/making_disqus_xhtml_co... and I think Daniel was trying to point me to this post.

Thanks in advance.

Re: Talking to Erlang

LukeHoersten — Tue, 29 Jul 2008 03:26:47 -0000

Good find. Just to clarify for the readers, JSON-RPC is a special specification for calling functions remotely. This example is just a simple HTTP body with JSON. Designed with the explicit intent of simplicity. More functionality would come from adding different URLs like REST. Kevin Smith has actually just completed a screencast that should describe this RESTful setup in more detail. I'll add a link when it becomes available.

Re: Talking to Erlang

mark — Tue, 29 Jul 2008 02:41:34 -0000

luke,
check this out, a somewhat similar but more constrained way of exposing erlang methods/ functions

http://www.lshift.net/blog/2007/02/17/json-and-...

Re: Personal Brand Management

LukeHoersten — Mon, 21 Jul 2008 19:46:26 -0000

I've been working at an algorithmic trading firm for a few months now. I hardly have time to even write once a month for my own blog but thanks for the offer.

Re: Personal Brand Management

techwinter — Mon, 21 Jul 2008 06:39:41 -0000

I love it! You are doing so well. Still don't want to join up?

Your quality is so high! You would really do well to publish with us big guy... PS. How is school? You must be done by now, did you get your marks back yet?

Good luck with the new job as I imagine it is coming up soon!

Cheers
Roger

Re: Shortcomings of Mercurial

Jakub Narebski — Sat, 05 Jul 2008 18:18:32 -0000

Ooops... sorry for repeating myself.

Re: Shortcomings of Mercurial

Jakub Narebski — Sat, 05 Jul 2008 18:12:29 -0000

Git pack files uses binary xdiff for deltaifying, so having many large binary files and moving them around shouldn't be the problem. On the other hand Git does not track renames, but does similarity estimate based rename detection, so if representation of binaries changes much (e.g. encrypted files) you are out of luck...

Re: Why Make Erlang a Functional Language?

LukeHoersten — Tue, 01 Jul 2008 04:15:57 -0000

I agree with you on both points. The first one I've addressed countless times already in response to other comments.

The second point, I believe, is partly why Erlang has been so popular in industry: it's a small and simple language. Simple fine-grained explicit concurrency works well and composes well enough with a very shallow learning curve. This was done by focusing on a smaller problem set and cutting some of the functional features available in academic languages. Implicit concurrency, for instance, is still very academic and doesn't have the pragmatic efficiencies that I tried to highlight in the conclusion of my post. There are already many fully-featured functional languages out there and you see how well they've done in industry. Point taken, though.

Most functional languages start with abstraction and cut away until the hardware level is reached. Imperative languages tend to start with hardware and add abstraction. Erlang is one of the few functional languages that took the lessons of the highly abstracted functional languages and made it machine aware. Hybrids are the key and are why languages like Python and Ruby are becoming so popular.

Re: Why Make Erlang a Functional Language?

Greg M — Tue, 01 Jul 2008 03:17:25 -0000

Nice article, the core point is very sound, but a couple of minor flaws: Firstly the syntax of Erlang comes largely from Prolog as you said, but Prolog is not a functional language (and one might argue that putting so much syntax from a logic-programming language into a functional language is a big part of what people are complaining about with Erlang syntax). And secondly I don't believe that too much work has gone into using the immutability properties of Erlang code as a basis for compile-time optimization, although in theory it's certainly possible. Unfortunately Erlang only has the nice properties of functional languages at the smallest scale, the explicit fine-grained concurrency makes it harder to reason about on a larger scale.

Re: Why Make Erlang a Functional Language?

LukeHoersten — Mon, 30 Jun 2008 12:28:09 -0000

There is no direct implementation of a priority queue in the Erlang stdlibs as far as I know but it has everything you need to build one. It's pretty reminiscent of C++'s stdlibs with sets, queues, trees, and dictionaries. Googling "erlang heap" turned up a heap sort which looks comparable to any imperative language. You wanted something pre-made though, correct?

Re: Why Make Erlang a Functional Language?

philharnish — Mon, 30 Jun 2008 02:01:07 -0000

Is this the library you mentioned in our conversation? I am pretty familiar with these modules--I even used a couple in my final project (pg stands out). Unfortunately there is nothing in here that I saw could be forced into a priority queue.

I seem to remember going through these modules with you to see if anything would work. It was so long ago so I may remember wrong :)

Re: Erlang Circular Process Communication

LukeHoersten — Sun, 29 Jun 2008 23:25:20 -0000

Thanks a lot =)

Re: Why Make Erlang a Functional Language?

LukeHoersten — Sun, 29 Jun 2008 23:24:01 -0000

Erlang may or may not actually copy the data. The point is that if the user is unable to treat the data as mutable, the compiler or VM can know more about the data and optimize where possible. Think of it like copy-on-write except without the write, we don't ever need to copy. So to the user, the data is always "copied." Similar tricks are done with tail recursion etc.

Re: Erlang Circular Process Communication

AlainODea — Sun, 29 Jun 2008 21:32:58 -0000

Nonetheless you did brilliantly. That is a very elegant solution. I hope you keep at Erlang. It is a very important language.

Re: Erlang Circular Process Communication

LukeHoersten — Sun, 29 Jun 2008 16:55:33 -0000

The eat function is the actual "dining" or resource sharing code. You'll have to write that part yourself =) You could have it simply print out the neighbors to see who all can communicate with each other.

I was more interested in the actual setup of a circular communication ring because it's not as trivial as it seems. This was my first Erlang program so doing it cleanly was a bit of a challenge for me.

Re: Why Make Erlang a Functional Language?

AlainODea — Sun, 29 Jun 2008 15:04:42 -0000

This is a very good overview of the reasoning behind some of the more fundamental design choices in the Erlang VM. I found it very interesting and informative.

Why does Erlang copy data between functions and messages if it has immutable data? It seems like copying is only really required for isolation if data is mutable. I have read that it certain circumstances (large binaries or lists for example) that the arguments/messages use shared memory under the hood if the receiver is local.

Re: Erlang Circular Process Communication

AlainODea — Sun, 29 Jun 2008 14:41:08 -0000

It is interesting to see how concisely Erlang's message-passing and pattern-matching addresses the Dining Philosophers problem. I would like to see how Kilim does this since it uses cooperative multi-tasking unlike Erlang which uses preemptive multi-tasking.

I would love to try this, but the dine_phil module does not compile:
./dine_phil.erl:50: function eat/3 undefined

Re: Why Make Erlang a Functional Language?

rvirding — Sun, 29 Jun 2008 01:05:20 -0000

I think that if you actually looked at Erlang you would see that the reason for this is very simple and obvious. In Erlang it is perfectly legal to have *different* functions with the same name but with different arities, so if you want to reference a function uniquely you need to specify the arity. Of course, in some limited situations this may not be necessary but in the general case it is.

This is usually demonstrated in the second version of factorial shown, the tail-recursive one.

Sorry for being so sarcastic here but this feature is so basic that to have missed it is really surprising.

Re: Why Make Erlang a Functional Language?

daniel b. giffin — Fri, 27 Jun 2008 23:07:39 -0000

yeah, the syntax for referring to top-level functions is pretty absurd. i've only barely peeked at Erlang, but i'm fairly sure the reason for this particular eccentricity is that (on account of the language's roots in Prolog) lower-case symbols are "atoms" (while upper-case symbols are variable references).

so when they added closures to the language (see Armstrong's fascinating "History of Erlang"), these could naturally be assigned to (upper-case) variables and then referred to by same. but top-level functions, historically lower-cased and distinguishable from atoms only by the syntax of their use (function application versus argument-passing), had to have their names mangled (prefixed with "fun", etc.) in order to distinguish them when used as arguments.

(i don't know why the compiler is so lazy as to require that you specify the function arity.)

it seems the best solution would have been to leave Prolog behind and name functions in the same way as other variables, reserving a special naming convention for atoms. Common Lisp's ":foo" syntax is not bad, and would leave lower-case names for variables.

i'm also worried about the scope of Erlang's atoms -- instead of using them to distinguish record types, i would prefer abstract datatype constructors (ala ML or Haskell) that are assigned to variables and thus scoped like everything else so that software can be safely composable (are atoms universally scoped in Erlang?!) -- but maybe this is an important mechanism for making hot code-update feasible (i've used a similar mechanism to ease schema migration in persistent object databases).

Re: Why Make Erlang a Functional Language?

LukeHoersten — Fri, 27 Jun 2008 21:59:48 -0000

When I say that "Erlang’s syntax derives from the functional programming paradigm," I don't mean to imply that Prolog is a functional language. I'm trying to point out that the syntax was chosen to try and facilitate the functional paradigm. Whether that was achieved or not is not in the scope of this post. The real point of this post is on data immutability and is why syntax was only mentioned in the first few paragraphs. I was trying to show that someone who wanted to bash on Erlang certainly could find something more fundamental than the syntax which they didn't even create.

I in fact agree that Erlang has a sub-par syntax but again, that wasn't the point of this post.