(Am I the only one who checked the coedastronomy site in case they meant March 3 Greenwich time?)
I can post an admission that I'm half-done with a handful of projects, but I don't have to like it. I finish projects! Or I give them up! (Right now, I am making a "chop" hand gesture to emphasize my willingness to give up on stalled projects.) So after posting that blog item, I forced myself to get my act together. (Right now I am gritting and baring my teeth to illustrate my renewed strength of purpose.)
Thus: a page of photos of San Francisco's 17th Street. A couple of weeks back, when it stopped raining, I walked the length of 17th Street. I snapped a bunch of photos. And then for two weeks, I didn't get around to captioning/uploading them. Instead, I just groused about not enjoying being in the middle of projects. Today, I finally finished slapping some captions on. Allez-oupload! I will now stop worrying about those photos.
Last night, I wasn't doing photos. Last night, I finished off my Erlang experiment. I was trying to learn about Erlang concurrency. And sure enough, concurrency is indeed easy with Erlang. Here's my program's, uhm, central dispatch control loop thingy:
queue(Migrant) ->
receive
TradedList ->
RanList = cull_unhealthy(TradedList),
{NewMigrant, NewList} = judge(Migrant, RanList),
spawn(critter, run_n_trades, [self(),
clear_state(NewList), 500]),
queue(NewMigrant)
end.
That "spawn" spawns a new thread, a thread that executes a function called run_n_trades. That "receive" receives a message.
run_n_trades(Queue_PID, List, 0) ->
Queue_PID ! List;
run_n_trades(Queue_PID, List, N) ->
run_n_trades(Queue_PID, run_trades(List), N-1).
It's not obvious from this code, but run_n_trades does a lot of data crunching and then sends the results back to the, uhm, central dispatch control loop thingy. (It's that mysterious Queue_PID ! List blob.) That's sending back the data structure that the queue will receive. How does this message-passing benefit me? Well, I actually had two threads doing big data crunching at the same time. Each one would crunch, crunch, crunch, then send results back to the queue. The queue could combine their answers. (In this case, the "combine" was allowing one of the genetic-algorithm "critters" to migrate from one batch of critters to... whichever batch was next passed back to the queue. (But this parenthetical remark probably doesn't make much sense unless you're looking at the whole program, which isn't really interesting enough to be worth it.))
What did I learn from all this?
- Erlang is not so bad. I am not fond of languages designed by people in love with recursion. Among those, Erlang is not so frustrating as many.
- Erlang concurrency is indeed easy. If I were writing a program whose main challenge was coordinating many threads, watching a little data on each thread, I'd be glad to have Erlang in my bag of tricks. Because those problems can be really hard, and Erlang has nice language structures for these.
- Erlang was not a great choice for my sample program's purpose: yet another genetic-algorithm prisoner's dilemma fun-fest. Part of Erlang's safety comes from discouraging you from changing the value of variables. Instead, you're supposed to create new variables whose values don't change. (Is "variables" even the right word?) So if you're moving around little structs, there's some extra copies but you don't sweat it much. But if you make many tiny changes to a big array of structs... Erlang isn't a great choice.
- But it does suggest some ways to make thread-safe programming safer in, you know, real programming languages like C++. Maybe you make a rule saying that cross-thread messages pass in copies, not originals. That's one extra copy, but one extra copy maybe isn't so bad. And at least everyone knows which thread is responsible for which data structure.
Am I rambling? Sorry, I'm rambling. I'm just so happy that I have an excuse to stop thinking about Erlang now that I did what I set out to do. And I'm glad I finally uploaded those photos. So... I'm rambling. You shouldn't have to listen to me ramble. Here, go look at photos instead.
Labels: photo, programming languages, site