I'm actually not talking about the potty mouths:) APL is up there on my list now, but it hasn't knocked Prolog out of the top slot.
I've done a bunch of test automation. I really enjoy testing because on a good day it can approach something reminiscent of science, but OTOH the test code I ended up wrangling (often my own code) wound up the worst sort of mess, for a few reasons. Not-test code that I've worked on or composed myself has always been a lot better, for reasons I don't totally understand yet. I can toss some guesses out there: One is that people who do automation are often outnumbered 5:1 or worse by the people making the artifacts under examination, such that there's too much to do in order to do anything very well. Another is, testing often fails to strike decision makers as important enough to invest much in, so you end up hacking your way around blocking issues with the smallest kludge you can think of, instead of instrumenting proper hooks into the thing under test, which usually takes a little longer, and risks further regression in the context of a release schedule. Things I learned from Smalltalk and Lisp have been really useful for reducing the amount of horror in the test code I've worked on, but it's still kind of bad. Actually I was inspired to look for an EDSL in my last adventure that would cut down on the cruft in the test code there, which was somewhat inspired by STEPS, and did seem to actually help quite a bit. Use of an EDSL proved very useful, in part just because most "engineering" orgs I've been in don't seem to want to let me use Lisp. Being able to claim honestly that I'd implemented what I'd done in Ruby seemed to help justify the unorthodox approach to my managers. I did go out of my way to explain that what I'd done was compose a domain specific language, and this did not seem to get the same kind of resistance, just a few raised eyebrows and funny looks. I keep getting the feeling that the best tool for the job of encoding and "running" invariants might be a Prolog, and so this one is currently at the top of my list of things to understand deeply. Anyone else here ever deal with a bunch of automation? Ever find a way to apply what you know about programming languages themselves in the context of software verification? Because I would *love* to hear about that! On Jun 5, 2011, at 7:06 PM, David Leibs <[email protected]> wrote: > I love APL! Learning APL is really all about learning the idioms and how to > apply them. This takes quite a lot of training time. Doing this kind of > training will change the way you think. > > Alan Perlis quote: "A language that doesn't affect the way you think about > programming, is not worth knowing." I love this quote. Thanks for your (snip) > > -David Leibs > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
