• A Django site. •
• •
April 7, 2008

Hans Fugal
no nic
The Fugue :
» Functional Floundering

Levi pointed me to a presentation on Clojure, "a dynamic programming language for the JVM". That's actually a pretty bland description. I'd describe it at least as a dynamic functional concurrency-oriented lispy language for the JVM. The presentation was interesting, though I wish I had been able to follow the ant colony demo (it's audio-only).

It awakened the oft-recurring "functional floundering" feeling. I've written a semester worth of scheme in a programming languages course. I've read the Erlang book and written a little Erlang code. I recently went through a graduate course in programming languages with emphasis on denotational semantics. I understand the lambda calculus, functional programming, etc. But I feel completely stymied whenever I think about actually programming in a functional language.

I'm not sure what the root is, but I'm sure it boils down to lack of practice. That undergraduate course aside, I haven't had any practice. And since that course was very handholding (too much in retrospect), I don't feel like I took any practical skill away from it. Yet I feel that in the future functional programming for concurrency will be important, even if I'm not convinced it will be essential.

So I don't have time right now to really rectify the situation, but that doesn't stop me from wondering—how does one learn practical functional programming? What problem sets do you work through to get the needed practice? I suppose the question can apply to learning any new language, but there is much paradigm carry-over between imperative languages (and probably between functional languages). Are there certain problems that will aid that paradigm shift? If you feel like you've developed functional chops, in any functional language, I'd like to hear in the comments how you got there, what you'd change in retrospect, and your advice for me and others like me.

by Hans Fugal at 12:21 AM under clojure , cs , erlang , functional , lisp , programming , scheme
February 21, 2008

Kevin Tew
no nic
Entrepreneurship: Life Long Learning
» Beating my head with PLT Scheme

I’ve been trying to communicate with a perl process from PLT Scheme using the process library call from scheme/system.

I’ve been a good systems boy making sure that I call flush-output after every string I write to the perl process. But the perl process never gets any input unless I close the output side of the pipe connected to perl’s stdin filehandle.

After hours of no progress I found this

http://pre.plt-scheme.org/plt/doc/release-notes/mzscheme/MzScheme_300.txt

* File-stream output ports (including file ports, the initial output
port, and ports created by `subprocess’) are now block-buffered by
default, instead of line-buffered. The exception is when an output
port corresponds to a terminal, in which case it is line-buffered
by default. Also, the initial error port remains unbuffered.

TCP output ports are block buffered (instead of unbuffered) by
default.

The file-stream changes are especially likely to affect stdio-based
communication among OS-level processes. For example, when
communicating with an ispell subprocess, adding a newline at the
end of a command previously would have been enough to send the
command to ispell. Now, the output must be flushed explicitly
(using `flush-output’) or the buffer mode must be explicitly
changed to by-line (using `file-stream-buffer-mode’).

The TCP changes affect most TCP-based communication. Explicitly
flush output using `flush-output’ or change the buffer mode using
`file-stream-buffer-mode’.

So I said what the heck, I’ll just add a (file-stream-buffer-mode outp ‘line)
call for grins.

And it started working.

by Kevin Tew at 7:19 PM under languages , scheme (Comments)
February 11, 2008

Phil Windley
pjw
Phil Windley's Technometria
» Unit Testing in Scheme

I put together a mini-lecture on unit testing in Scheme for my CS330 class. It's not a complete introduction, just a tutorial on getting started. If you have suggestions on using SchemeUnit, I'd love to hear them.

Students in CS330 submit their assignments to an autograder. They sometimes try to use the autograder as a test harness with bad results.

I think there are some distinct advantages to students using unit testing in preparing their assignments:

  • Unit tests separate tests from the code. It's cleaner and easier to manage.
  • They can write tests before they code. This forces them to think about the functionality and boundary conditions before they begin
  • Tests are easier to share. Unless the assignment were specifically about testing, I encourage students to share their tests for assignments as an aid to communal understanding of the problem.

On the last point, while I'm happy to have them share tests, I don't want to provide them. I want them to get experience in writing tests. Discussing tests with other students is a great way for them to learn.

Tags: cs330 scheme programming testing

7:08 PM under cs330 , programming , scheme , testing
January 30, 2008

Phil Windley
pjw
Phil Windley's Technometria
» Arc Is Released

Paul Graham has released Arc, his new language.

Arc is still a work in progress. We've done little more than take a snapshot of the code and put it online. I spent a fews days cleaning up inconsistencies, but it's still in the semi-finished state most software is, full of hacks and note-to-self comments about fixing them.
From Arc's Out
Referenced Wed Jan 30 2008 16:21:31 GMT-0700 (MST)

Paul mentions Arc in a number of his essays:

Paul wrote HackerNews in Arc as a "big project" to shake out the bugs and design issues.

Arc runs on top of mzscheme and is decidedly Lispy. What did you expect from the guy who wrote two of the leading books on Lisp and is one of it's biggest champions.

I think it's very cool that programming languages continue to be developed and that new ideas keep popping out of the woodwork. Many people are surprised by this, but programming languages are not technologies. They are notations--notations that can come alive and animate bits and atoms. There will always be a need for new and better notations.

Tags: programming+langauges scheme lisp programming cs330

11:40 PM under cs330 , lisp , programming , programming+langauges , scheme
January 16, 2008

Phil Windley
pjw
Phil Windley's Technometria
» Scheme and Ruby

Duane Johnson pointed me to a very interesting discussion on Y Combinator about the differences between Scheme and Ruby. This is an excellent discussion--not a flame war--that I found enlightening. The summary, if you don't want to read the discussion thread:

  • Ruby closures are more complex
  • Macros, macros, macros...

Can't say enough about macros. Every language besides Lisp and it's close relatives trade macros for complex syntax. Maybe that's a good trade-off, maybe not. Nevertheless, it is a trade-off. You can't have the full power of macros without simple (abstract) syntax that's exposed to the programmer.

Now, that I've said that, I wonder if IO's impressive reflection can do the same. Someone more enlightened than I tell me: what can't be done with reflection that can be done with macros?

I do believe that using reflection is more complex than using macros. It reminds me of poking a stick in a black box to flip a switch.

Tags: programming cs330 scheme ruby

9:16 PM under cs330 , programming , ruby , scheme