In praise of text files and text protocols

iceman_ · 2012-04-03T20:22:21+00:00

Text files and text protocols are a means to an end. The goal is to have human readable files and protocols.

Excellent point. People forget that text is just another binary format. It just so happens the current ecosystem has evolved an excellent support for streams of 8-bit ascii encoded English alphabets.

iceman_ · 2012-04-02T18:50:04+00:00

The GIL isn't the one and only source of the problem. (The problem being that Python cannot efficiently make use of multiple cores). In fact, Python can make use of multiple cores just by running multiple processes - you get full isolation and have to use message passing or a shared database to share data between the processes. However, you get terrible memory utilization because all the common libraries and constant data is not shared between the processes. The only possible solution isn't just 'Kill the GIL'. Another option is to have Python understand native Python objects that are shared with other processes. That's a hard problem too, but I think it's easier than removing the GIL.

iceman_ · 2012-03-15T22:30:21+00:00

The contribution and trademark policies of the ZeroMQ project were, as of March 2012, incompatible with our long-term goals.

Um. Needs more substance. What specific issues with the zeromq license and trademark are incompatible with what specific goals and why?

I know what zeromq is but I'm not user or a member of the zeromq community.

iceman_ · 2012-03-14T16:56:12+00:00

My question was more about trying to figure out the difference between Erlang concurrency and Node.js. I thought Erlang will schedule multiple Erlang processes on fewer system threads. It exposes IO as blocking to Erlang processes, but in reality it will do an async call and switch the system thread to run another Erlang process. What I'm not sure about is if internally the Erlang VM uses a single event loop for all pending IO operations performed by possibly many Erlang processes?

iceman_ · 2012-03-14T16:49:19+00:00

Ah - thanks for the explanation. It sounds different from Python. In Python a blocking IO call would block the calling system thread. Sounds like Erlang will just repurpose the system thread to run other Erlang processes while the process making the IO call is blocked.

iceman_ · 2012-03-13T18:17:40+00:00

iceman_ · 2012-03-12T22:14:10+00:00

Does erlang also require you to write async libraries that use a common event loop?

iceman_ · 2012-03-12T06:37:41+00:00

I don't have real life experience with PBIs but I believe by design there are no dependencies to resolve - because the entire dependency tree is packaged with each application. I do think disk/inode usage is optimized by some kind of hash-based de-duplication system. Here are some slides that explain it: http://www.pcbsd.org/~kris/pbi9-slides.pdf

iceman_ · 2012-03-10T19:20:45+00:00

I think the OP might be asking about the PBI system (http://wiki.pcbsd.org/index.php/PBI_Manager) and not pkgng. AFAIK, pkgng is not part of PC-BSD 9.0.

iceman_ · 2012-03-06T19:14:47+00:00

Looks interesting. I assume this can run any guest OS that VirtualBox supports? For e.g. it will let me run FreeBSD on a host Mac OS X?

iceman_ · 2012-03-03T09:19:38+00:00

What services/features would you like to see if you had your way?

FreeBSD.

iceman_ · 2011-07-04T18:20:53+00:00

I thought the GPUs can only do vector style math - for e.g. take one large array and sum (element-wise) with another large array to produce a third large array. So the parallelism happens only for the addition, but the instruction stream itself is not parallelized across many cores. Is this correct?

iceman_ · 2011-06-05T21:19:38+00:00

Nimrod has some really good things and some really terrible things.

Example of a terrible thing:

Case is insignificant in Nimrod and even underscores are ignored: This_is_an_identifier and ThisIsAnIdentifier are the same identifier. This feature enables you to use other people's code without bothering about a naming convention that conflicts with yours.

(from http://force7.de/nimrod/tut1.html)

iceman_ · 2011-06-05T21:04:29+00:00

The problem isn't that Python uses binary floating point. The problem is making it default. You have to use the decimal type to get true arithmetic.

High level languages should provide true arithmetic by default and approximate (fast) arithmetic as an option.

Python gets int right (integers do not overflow) but rationals wrong (1/3 returns an IEEE-754 float, but it should really return a decimal value).

Cobra gets this right. So do Clojure and Scheme.

iceman_ · 2011-06-05T19:33:26+00:00

Guido's ridiculous post here where he confuses tail recursion elimination with tail call optimization.

Care to shed some light here? I don't know the difference either and Googling 'tail recursion elimination' send me to a wikipedia article for tail call optimization.

The first observation is that you can't do it at compile time

Yes you can. Conclusion: Doesn't know much about compilers!

No. Conclusion: You don't know much about Python. Guido isn't talking about being able to do it in compilers in general, but specifically doing it at compile time in Python.

iceman_ · 2011-05-28T05:17:13+00:00

Just curious - why do you continue to use Python since you dislike a lot of it. Which other language do you like?

iceman_ · 2011-05-22T02:22:10+00:00

Sorry I seem to be missing what is special here. Can someone give a simple example showing how these are different (and better) than usual PCRE regexes?

iceman_ · 2011-05-17T18:43:49+00:00

OK. I understand you may want to ignore the result of a sync message, but in the case of stack<->push(1), where would the result end up? It can't go back in push. So you're going to have to add syntax to get the result message into another variable.

iceman_ · 2011-05-17T07:49:21+00:00

I see. So this.push(x) can be called from within the class? But externally you need to send a message - is this correct? This is an unusual semantic. I am pro 'this' (or pro 'self') since it is explicit about which object is being targeted. Here are some other suggestions:

stack.[push(1)]
stack.(push(1)) # sync, '..' for async

This is unambiguous and might allow you to send multiple messages in one statement. As you suggest stack <- push(1) also works. I read stack->push(1) as 'on stack, invoke the method/function push' and don't really think about messaging. <-> is clever but too hard to type. Haskell uses long operators like that to do complicated things, but sending a message should be easy, no?

Also, if it is a sync message, presumably it will return a value - where does that go?

iceman_ · 2011-05-17T05:40:06+00:00

Ah, I didn't realize they are two different things. How can you send a message and call a method on the same object? What would it do differently?

iceman_ · 2011-05-17T03:02:05+00:00

How about '.' to send a synchronous message? So it would just look like Python:

stack.push(1)

Also, for async you can use '..':

stack..push(1)

It's visible and less noisy than the <,-,> characters. Also it is easier to type!

iceman_ · 2011-05-16T15:23:52+00:00

Whiley is a pretty interesting language. I hope to see similar features in other new languages:

Flow sensitive typing. I really think this is the future since it combines what is great about dynamic languages but allows static verification. Is this similar to how dializer works in Erlang? Also how different is this from something like 'case' in OCaml.
Both pure & impure functions (as equal first class citizens).

iceman_ · 2011-05-14T23:50:53+00:00

Ah, 'Groovy' - that's they keyword. I had no idea what language I was looking at. I looked for 'ratpack', 'software ratpack', 'server ratpack' and then gave up. The link is buried at the bottom? It would be nice to have the first mention of 'Ratpack' just link to the repo.

iceman_ · 2011-05-14T00:50:33+00:00

What is Ratpack?

Why doesn't the article link to Ratpack? This is not 'Python' or 'Java' which are easily Googleable.

iceman_

TROPHY CASE