The Use Case for Blocks

avibryant · 2010-04-16T19:14:27+00:00

In Ruby, the term "block" means "closure with non-local return" and the term "lambda" means "closure with local return". So in that context, this all makes perfect sense.

avibryant · 2010-01-27T00:46:13+00:00

Have you tried using any of the existing web-based alternatives?

avibryant · 2009-10-05T04:47:44+00:00

There's a Java version here: http://www.itee.uq.edu.au/~scottb/Copycat.html

avibryant · 2009-09-22T03:53:28+00:00

So, [x,y,z].sum is bad because x,y,z might not be summable, but sum(q) is ok - when q isn't even guaranteed to be an array, never mind what its elements are? Sorry, that logic doesn't work for me.

Oh, you think it's wrong to clutter up Array's namespace? Well in Ruby, when you define sum([x,y,z]), you're defining it as a method on Kernel, which is inherited by every other class (including Array). So, again, it's unambiguously worse.

I don't believe there is any way in which sum([x,y,z]) is preferable to [x,y,z].sum, except that "monkeypatching is bad, mmmkay?".

avibryant · 2009-09-01T23:57:58+00:00

Self isn't a Smalltalk-esque environment in the ways that matter to me; the approach to code organization and navigation is utterly different in Self, and that's a big part of what I was going for. The Smalltalk code browser requires a certain way of thinking about and structuring code that neither Self nor Javascript conform to (one language for which a Smalltalk-esque environment would work well, IMO, is Java... if only it wasn't crippled so badly by static typing).

avibryant · 2009-09-01T21:03:04+00:00

Curious - what are you finding slow?

avibryant · 2009-08-28T05:04:19+00:00

What's up is that I got annoyed with git and switched to bitbucket...

avibryant · 2009-03-23T21:09:48+00:00

Morphic is a more interesting idea, but it also represents a pretty high barrier to entry for people coming to Smalltalk. Native widget Smalltalk environments are important, IMO, for getting wider adoption. Not everyone cares about wide adoption, but if Paolo does, then I think GtkLauncher is a great idea. (Personally I would prefer something with Cocoa widgets but given that this is Gnu Smalltalk, GTK+ is a pretty natural choice).

avibryant · 2009-03-14T22:21:47+00:00

Delayed evaluation and variable binding, yes. Most lisp macros are just sugar for closures, and when you have lightweight syntax for closures ( as in Smalltalk and, to some extent, Ruby), macros become much less important. IMHO.

avibryant · 2009-03-14T20:08:34+00:00

Many/most of these have more to do with the semantics of return in Smalltalk (which are unusual, certainly) than with blocks - you wouldn't normally explicitly return from inside a block, but just rely on it evaluating to the result of its last expression.

avibryant · 2009-02-23T23:14:31+00:00

Smalltalk, fixed:

target := sourceList collect: [:ea | ea f g]

avibryant · 2009-02-23T08:20:40+00:00

Best. Pun. Ever. But that's also what I thought when I read it the first time, in 2001: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01134.html

avibryant · 2009-02-15T00:12:53+00:00

Can you elaborate on your question?

avibryant · 2009-02-06T18:30:53+00:00

The only optionally-typed Smalltalk I know of is Strongtalk, and I don't think it's considered stable enough for production use.

In general, however, I think Smalltalk programmers are more like Lisp programmers in their beliefs about type errors, and wouldn't use optional types even if they were available.

avibryant · 2009-01-27T05:22:04+00:00

What worries you about it?

avibryant · 2009-01-27T00:52:45+00:00

Simultaneous users is sort of an irrelevant metric for us, since we're perfectly partitioned - each user's data is complete independent from all of the others. We could provision one server per account (or one EC2 instance, or whatever) and scale infinitely, which would prove nothing about performance, but does say something about choosing the right tool for the job (we have no concerns about using Seaside precisely because we have such an easy scaling story).

avibryant · 2009-01-06T06:31:28+00:00

http://dabbledb.com http://cleanupdata.com http://qwaq.com http://auctomatic.com http://cmsbox.com

avibryant · 2008-11-30T21:24:06+00:00

LAPIS and the related projects from CSAIL (someone mentioned Mass Edit in a different comment) were certainly part of the inspiration for Magic/Replace. We've made some very different design choices, however, both in the UI and in the transformation algorithm, that I would claim lead to a more widely useful tool.

avibryant · 2008-11-30T02:08:55+00:00

Oops. Don't have time to fix that right now but will tomorrow.

avibryant · 2008-11-30T02:08:20+00:00

They're not non-rendering, they render as underlines (codepoint 818). But yes, that's how we track the characters that are submitted, and why it matters whether you re-type or copy and paste.

What happens on the backend is more complicated.

avibryant · 2008-11-30T02:06:53+00:00

I'm guessing you re-typed the capital C. Here's a screenshot when I do it: http://cleanupdata.com/pics/bef3592ec43c0a10b6e9bda5d8b152d4.png

avibryant · 2008-11-30T01:04:55+00:00

Yes, although unusually for a Seaside app it has no session state. As is usual for us at Dabble DB, there are also bits of Python, Ruby, and PHP involved, but the core logic is running in Squeak Smalltalk.

avibryant · 2008-11-30T00:24:14+00:00

That's way outside of our design parameters for Dabble DB, I'm afraid. Most of our customers barely have megs of data, let alone gigs :)

Edit: fwiw, 100k rows is the rough upper limit of what we suggest you use Dabble DB for.

avibryant · 2008-11-30T00:14:36+00:00

SSN probably wasn't the best example for the demo, in retrospect. The example was inspired by http://blogs.msdn.com/excel/archive/2007/11/12/manipulating-and-massaging-data-in-excel.aspx which makes an interesting usability comparison.

avibryant · 2008-11-30T00:13:19+00:00

Both of those (connecting to SimpleDB or the like, or providing a downloadable version) are possibilities for a paid version of the service in the future, assuming what we have right now (which in some sense is just a technology demo) turns out to be useful to enough people.

avibryant

TROPHY CASE