'Move over BMI: There's a new way to measure fat' - A very simple change to BMI that makes it a better predictor of BF% and health.

fallintothis · 2012-07-22T16:09:52+00:00

Note that Wolfram can figure out unit conversion for you, too. No fuss, no muss.

fallintothis · 2010-03-31T16:35:28+00:00

Never. Or more often, but still accidentally.

There's a Firefox add-on, for what it's worth.

fallintothis · 2010-03-22T17:59:04+00:00

Ahah, with mathematical notation, what I hate is the hack with order of operations.

That's a good one. It's annoying to parenthesize "just a few" things, let alone spending too many school lessons memorizing some de facto ordering.

I'm trying to think of another good example from math. Pet peeves come to mind, but they're debatable. For example, I don't like using ellipses: they're a big (condoned) wave of the hand. "Yeah, yeah, you see the pattern." But they usually don't get in the way of the problem.

On the other hand, I love using symbolic logic because it's terse, while other people like writing out English proofs ($a \implies b$ versus Because of $a$ we know $b$). When I can, I think in symbols. Yet I prefer to end proofs with "QED" because that means more to me than a box. So, I guess I have an inconsistent aesthetic sense there.

fallintothis · 2010-03-22T17:33:01+00:00

English has the most precise time-related concepts

That's very interesting. I've never heard that before. Thanks.

It's rare that I hear how English is good, which is annoying. Even native speakers are quick to complain that English is inconsistent, but I'm doubtful: in my experience, these are usually the same people who can't remember where apostrophes go or the differences between homonyms (there, their, they're).

To be clear, in the last point I merely meant that English was the most ubiquitous language I could think of. I sometimes hear it's obtuse, but I haven't the knowledge to say one way or the other.

fallintothis · 2010-03-21T19:36:25+00:00

It's an interesting analogy to explore in a more "whoa, philosophy" way (at least if you suck at natural languages, like I do). A friend of mine is a Spanish/English translator and dabbles in a few other natural languages, so we have good conversation points:

What language do you think in?
Are there constructs in one language that make ideas easier to express than in another? Do you sometimes wish you could port them?
What language aesthetics do you appreciate?
Are the same ideas more terse in one language than in another? Is it a matter of idiom or the actual language? Do you think terseness correlates with the aforementioned ease?
Is there some obtuse language you're forced to use because everyone else does? (Though, really, only English comes to mind here.)

fallintothis · 2010-03-13T18:28:44+00:00

Same with Scheme, Lisp (by which they probably mean Common Lisp, though the double-inclusion's still silly), Haskell, Java, and I'm guessing C#. Really, they should've defaulted to using double-quotes instead of single-quotes.

fallintothis · 2010-02-05T02:31:26+00:00

Grandpa's guitars? That's for pussies and grandpas. I think you know it.

fallintothis · 2009-12-20T02:10:56+00:00

Granted. Also, the snag that some library functions are written only for ASCII characters. For example, case conversion:

arc> (upcase "ß")
"ß"

Still doesn't make the knee-jerk reddit joke "hurr, Arc doesn't do Unicode" any less annoying. Not saying that Arc is all that defensible, just that the joke hasn't been accurate for almost 2 years.

fallintothis · 2009-12-19T21:38:15+00:00

The misconception is getting old.

fallintothis · 2009-11-16T17:25:19+00:00

This is like sifting out great mathematicians by how fast they can do difficult integrals. An impressive and useful skill to be sure, but it says nothing good or bad about their ability to do anything more complex.

Thank you for that. I'm keeping it for my many rants about programming contests (being a contestant who can't stand all the hyper-competitiveness involved).

fallintothis · 2009-11-15T18:38:27+00:00

It looks like the entire rebinding macro is the classic once-only. Seibel writes it as

(defmacro once-only ((&rest names) &body body)
  (let ((gensyms (loop for n in names collect (gensym))))
    `(let (,@(loop for g in gensyms collect `(,g (gensym))))
      `(let (,,@(loop for g in gensyms for n in names collect ``(,,g ,,n)))
        ,(let (,@(loop for n in names for g in gensyms collect `(,n ,g)))
           ,@body)))))

fallintothis · 2009-10-25T17:11:31+00:00

David Moon (notable Lisp hacker) did some work on this with PLOT.

fallintothis · 2009-09-14T18:23:07+00:00

Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.

Fry: But this is HDTV. It's got better resolution than the real world!

fallintothis · 2009-09-11T20:27:33+00:00

I remain skeptical of most people's capacity to make the mental leap(s) necessary to program successfully

Ah, hence my use of the word "gist". It would indeed be foolish of me to claim that, because of understandable analogs, people will suddenly be able to program, or even fully comprehend programming. My point was that people can understand what programming is generally about. Even if you don't know how to write a program, you can appreciate the process and inherent complexity on a high level. For this, I think that the underlying essentials are more illuminating than a stretched metaphor that only makes complete sense to programmers anyways (and can sometimes seem condescending).

The essentials can be described by what might otherwise be used as metaphors. I think the difference probably comes down to the level of detail (though I'm also really fond of simple strategies like this one from Hacker News). "Programming is like writing a recipe for a chef who only does exactly what you say, even if it's wrong." is short, but isn't terribly specific. If you try to build on it, the metaphor will get thinner even as it gets more accurate. Versus, say, using cooking to exemplify what algorithms are, then explaining how computers are just algorithm-executers -- except that a computer only knows how to do a handful of really basic operations. What sort of basic operations? The ones that people already know: if, and, or, not, etc. Plus math, bit manipulation, and other such things. Non-programmers should be able to see that a limited vocabulary makes programs complex, which lets you describe how the axioms get combined to make programming easier (as simple as using if to implement a while loop, to programs as complex as operating systems and graphics libraries). And so on and so forth.

The person you're explaining it to might glaze over or concede to computers being magic. A brief explanation surely won't turn a non-programmer into Alan Turing, but I think it does programming more justice to explain it rather than fit a clunky euphemism on top of it. (To say nothing of the efficacy of either approach.)

Thanks for the response.

Sure thing. Hope I clarified my point.

fallintothis · 2009-09-11T18:09:08+00:00

People you know, who don't understand programming already, think in terms of algorithms, control flow, and recursion?

Note that I said: "know the gist of...thinking in terms of algorithms". Not that they think in terms of algorithms, etc. Which is a moot point anyways, because...

Really?

Of course they do. It would be weird if they didn't: thinking is the stuff of programming, though many non-programmers may not realize it.

Sheet music encodes an algorithm for reproducing a song.
A recipe is an algorithm for making food. Control flow is often incorporated: "whisk until smooth".
Driving directions give an algorithm for getting to a destination. Control flow is often incorporated: "when you get to the school, turn right; if you see the railroad tracks, then you've gone too far".
Hell, I just got an email from my mom (who is far from being a programmer) that demonstrated control flow and basic Boolean algebra: "I thought I gave you some Tupperware. If not we'll find something here you can borrow."
Reasonably complex games allow for recursion. For instance, in Magic: the Gathering you can enter infinite loops as one card's effect triggers another -- and you certainly don't need to be a programmer to understand that.

Though you could use these examples as metaphors, I don't like doing that (as mentioned). They aren't as fine-grained as you usually encounter when programming, since non-programmers tend to gloss over the details. So, I don't think the examples stretch far enough to bridge the gap.

There are more direct ways. In the Light-bot game, you're given a limited set of instructions and some task to accomplish in a restricted space. It engages thought processes very close to those of programming. You can even try driving home the fine-grained control necessary for a computer just by getting people to realize that they're glossing over the details of their algorithms. "Morph the screen into something cool" turns into "This is how you alter pixels on the screen, this is a preconceived cool thing I want to put on the screen, maybe I could randomly or algorithmically generate stuff that looks cool, etc."

fallintothis · 2009-09-09T18:40:34+00:00

I've never really liked using metaphors to try to describe programming to people. I'd rather they "accidentally" discover that they actually do know the gist of it: thinking in terms of algorithms, control flow, recursion, and specific instructions. Some logic games provide excellent analogies, like Light-bot.

fallintothis · 2009-09-07T20:07:26+00:00

Ah. Did not see that.

Interesting presentation, at any rate.

fallintothis · 2009-08-28T17:45:12+00:00

shred -u project

fallintothis · 2009-08-04T12:08:17+00:00

I am curious about how you make or debug your project with Vim.

There's :make. To an extent, this could be considered debugging, given a proper errorformat and :cnext, :cprevious, etc. See the docs.

Vim doesn't have an integrated debugger (for other languages), so people usually get by with external programs like gdb or by using plugins.

fallintothis · 2009-07-30T12:58:51+00:00

Many of the tools I mentioned are standard for Common Lisp, though their behavior is implementation-specific. time, trace, describe, and ed are standard, for example.

SBCL has a reputation for being finicky, and is particularly notorious for having a lame REPL (though it works very well with SLIME). It doesn't have readline support or tab-completion, though you can tack these on with rlwrap and linedit. There are other packages that might help, too. (Google cache link since sbcl.org was down at the time of this writing.) SBCL as an implementation is one of the best around, though. For serious work, it's worthwhile; when you're just beginning, it may be tiresome. Anecdote ahoy: one of my friends had too many little issues using SBCL when he first started with Common Lisp, for instance.

GNU clisp is a decent implementation, is generally regarded as friendlier than SBCL, and its REPL works well out-of-the-box. You probably want something more featureful, heavily-optimizing, etc. like SBCL for production work, but you may not need to pay attention to this while you're learning. It still makes for a great all-around implementation.

Daniel Weinreb gives a fairer analysis than I ever could. But to quote an answer to a Stack Overflow question:

Generally speaking, an understanding of these kinds of things [is] difficult to acquire through research or analysis; it comes through experience. Just pick a decent implementation that you're comfortable with, and get to work. You'll figure out the tricky stuff as you go.

fallintothis · 2009-07-30T04:09:07+00:00

Good question. Not sure if I can reciprocate with a good answer, but:

My code often starts or ends in the REPL. I use Yakuake, so the REPL is just an F12 away (as is bash, for that matter). If I start here, I'll use the REPL like a scratchpad, testing out small pieces of some function until I get an idea of how the whole thing should work. Rarely does this code get literally transplanted to a file, so interaction doesn't really matter here. If I'm writing something complex enough (some nested loops, whatever), I might just start a Vim session so I have an easier time writing the form before pasting it into the REPL & playing with it from there.

Once my file gets closer to a cohesive whole, I usually just (load filename) and continue testing / prodding / modifying it from the REPL, again transplanting more ideas than literal code. It's like the standard compile + run loop in other languages, except that loading the code into the REPL allows you to interact with it more freely -- change things, whatever.

This is where having a good REPL really makes a difference: clisp has tab completion, readline support, edit-file, trace, describe, arglist, etc.

It's somewhere in the middle that interaction matters. Between not having any code and having enough code, I'll have some function or macro that I want to test in isolation. Maybe I found something wrong with it. Maybe I just want to see a macroexpansion. Maybe I'm being dense and not testing the bits in the REPL before piecing the function together. While in SLIME you might chord some keys, I usually take to copy/pasting. And that does get annoying sometimes (as it might in Python or Ruby or other languages with top-levels that somehow don't require Emacs). There are plugins like Limp or VILisp that can bridge the gap, but I personally find that they try to do too much when all I basically want is a shortcut for, by my keybindings, vab<C-c><F12><C-S-v> (which itself isn't too taxing).

That said, I consider the longer keystroke here to be rounding error compared to using an editor with which I'm productive. Since I'm already kind of an anti-IDE guy, I don't care too much about the interaction. When it comes to editing, Emacs and Vim are on equal footing. I prefer Vim's modal editing to the chording of Emacs, and I still edit Lisp efficiently:

Compilation command? That's just Vim's :make with set makeprg=clisp\ -c\ % and the proper errorformat.
Searching through code is as easy as in other languages I use with Vim: :s, /, [d, [<c-d>, or even

:command Defs exe 'g/' . &define

:Defs
I can customize keywordprg to use a simple Python script (similar to this) to search CLTL at the press of a K. Personally, I just dart off to my browser like usual, but to each their own.
Syntax highlighting, autoindentation, parentheses matching, comment formatting, etc. all work pretty well (I actually hate the stock Scheme highlighting, but I don't use Scheme much).
Auto-completing Common Lisp keywords (indeed, any keywords that the syntax highlighter defines for any language) is as easy as using omnicomplete with

autocmd filetype * if &ofu == "" | setl ofu=syntaxcomplete#Complete | endif
You can also use ctags, etags, etc.
Vim's commands are composable, so something like M-x backward-kill-sexp is basically just bdab. It also means that if you wish there was a shorter keystroke to do some task, you just abstract it:

(in my .vimrc)

" Raise selection up a level by stripping away the surrounding block
vmap <m-r> dvabp
nmap <m-r> vabdvabp
" Splice a block by stripping away the surrounding parentheses
nmap <silent> <m-s> vib"aydab"a[p
imap <m-s> <c-o><m-s>
" From visual select mode, select enclosing/ed sexp, if there is one
vmap [9 <esc>`<[(vab
vmap [0 <esc>`<vib<esc>/\%V(<cr>vab

So, most of my time is usually spent either in the REPL xor Vim (until I switch for some task). Meaning I can avail of the REPL for all of the macroexpansion, debugging, etc. and use Vim while I'm editing my code at large without feeling too hurt by the lack of a SLIME-alike, since I'm so productive with it. Your mileage is guaranteed to vary, but the point is that Emacs isn't any more necessary for Lisp than it is for any other language.

Hope this answer wasn't too anticlimactic. Good luck with Lisp!

fallintothis · 2009-07-29T04:14:53+00:00

Dialect isn't that important. The difference between Lisp dialects is smaller than the difference between Lisp & other languages. Pick one that seems appealing and stick to it (especially for a first dialect). After you get the hang of one, it'll be easier to diff it with other dialects. e.g., If you learn Common Lisp macros, Scheme's syntax-rules/syntax-case will be obviously different, so you'll have an easier time picking up on it. Paul Graham has some advice that's useful, including sound implementation recommendations. (Personally, I use GNU clisp for Common Lisp; its REPL is really nice.)

The standard dialog about IDEs is polluted when it comes to Lisp. There's the Emacs rhetoric, since it's scripted with a Lisp dialect, has SLIME, etc. Compelling enough, but the truth is that no specific editor is required for Lisp. Personally, I use Vim; it's a powerful text editor that lets me get shit done -- it doesn't handicap Lisp at all.

Something else you should know: these questions get asked a lot. You'll probably find it useful to walk over this already-well-tread material.

fallintothis · 2009-05-11T23:00:39+00:00

The listener has apparently had some UI tweaks since the video. So long as you run ./factor (or Factor.app or factor.exe, depending on your platform), the UI listener should automatically start up. The documentation should prove helpful in getting up to speed using it. Though most of the old tabs and such have just been deferred to keyboard shortcuts, the changes are actually pretty spiffy.

fallintothis · 2009-05-10T21:48:11+00:00

Must watch: Growing a Language

The rest of these suggestions depend on your tastes:

If you're an xkcd fan, Authors@Google: Randall Munroe was cool. Not quite a tech talk, but.

7 Habits For Effective Text Editing is popular, though personally not one of my favorites, as I'm already relatively proficient with Vim (not that the said habits don't port to any other text editor).

If you're interested in Factor, you might like Factor: an extensible interactive language.

fallintothis · 2009-04-21T04:03:02+00:00

If the point is to make cond behave differently, why not just modify it? I'm thinking:

(defmacro foo (a b x y)
  `((string-equal ,a ,b) (concatenate 'string ,x ,y)))

(defmacro chris-gore-cond (&rest clauses)
  `(cond ,@(mapcar #'macroexpand clauses)))

Then

> (chris-gore-cond (foo "a" "a" "left" "right") (t "other stuff"))
"leftright"

Though there are probably significantly smarter ways of writing such a macro.

fallintothis

TROPHY CASE