[erlang-questions] Fear and Loathing in Programming La La Land

[Garrett Smith]

On Wed, Apr 4, 2012 at 6:50 PM, Jan Burse <janburse@REDACTED> wrote:
> Garrett Smith schrieb:
>
>> It's no surprise at all to me that developers in these communities
>> prefer zero arg constructors and property configuration.
>>
>> These are just two totally, totally different world views. Almost
>> certainly dangerous to cross the streams [2].
>>
>> Garrett
>
>
> Either you are relatively young that you don't
> know, or you haven't been around much.

Alas, I wish I was younger. Upside is that I've learned manners along the way.

As for being around, I ran a Java tools product line back in the
nineties and can assure you that GUI tools drive underlying software
design. Like it or not.

> Widgets with attributes are in existence before
> Visual C and Java. For example we find <1988 the
> Athena Widget set for X11 (*).
>
> These Widget sets have a different kind of API.
> For the programmer there are generic constructors
> and generic setters, which make use of varargs.
> These varargs are supposed to be lists of key
> value pairs.
>
>    createXXX(.., KEY1, VALUE1, ..., KEYn, VALUEn).
>
>    set(.., KEY1, VALUE1, ..., KEYn, VALUEn).
>
> Since widgets have a state and are supposed to be
> muttable, it is perfectly valid to have setters
> beside an initial constructor.
>
> The setters can be used to change the features of
> the widgets in the course of the interaction with
> the end-user in the user interface. There existence
> is not determined by some GUI builders.
>
> I don't think we can make a case against setters.
> But we can make a case against the research paper
> that has spun this thread: varargs are a third option
> in creating an API.
>
> But I guess there are possibly even further options,
> maybe already found in some widget sets for X11, that
> come with their own programming paradigms.
> Not sure. (**)

I'm quite happy with the functional model. I think the rather horrible
practice of creating an object, manipulating its properties, and then
setting it lose on the world by calling methods is a recipe for Really
Bad Software.

If the study had targeted F# developers, it might have had another
result. Perhaps there are some amazing graphical tools in support of
that language. I haven't used it.

Regardless, my point was that tools drive developer models. It's
unfortunate I think in this case. But I think it's a sound explanation
for the paper's findings.

Garrett