[Newbies] Feedback: Using Output as the Next Input
dnorton at mindspring.com
Sat May 2 19:33:57 UTC 2015
Writing and reading files can be done easily. For Cuis, I summarized the protocol in World >
Help... > Terse Guide to Cuis > File Streams. If a file is used for the output, then it will have to
be parsed in some way in the future. By compiling it into a class method which answers a
Dictionary accessed by the drawing methods, no further parsing is needed.
A GUI might be appropriate for a user who does not like computers, but a definite
requirement IMO is to not have the IDE obvious.
I'd like to use this discussion to provoke comment on app delivery in Squeak and Cuis. If you
google 'Future of Smalltalk' you'll find a concise statement of the problem: "One of the big
problems ... which prevents the take-up of any "workspace" based language
(Smalltalk, APL, Forth etc.) is that it's really hard to work out what it is that is
delivered to the customer." - Frank Carver http://www.efsol.com/FrankCarver.html.
On 2 May 2015 at 9:26, Ralph Johnson wrote:
> Writing to a file is very similar to writing to the transcript.
> You need to open a writestream on the
> file, then you write to it.
> If I were writing the data out, I'd probably try to write it out as
> a CSV (comma separated values) so
> that I could read it into a spreadsheet.
> If you want to make it easy for people who don't like computers,
> perhaps you should make a GUI
> for it. The GUI might list all the drawings in the top pane.
> When you select a drawing, you get to
> see its contents in the bottom pane.
> I assume that when you run drawn2012 it returns some kind of data
> structure that gives you the
> drawing for 2012?
> My son had something like this. He had his program send each
> person email, telling them who
> they drew. If you wanted to do this, you could focus on how to
> send email instead of on how to
> make a GUI.
> I'm not sure what your motivation is here. Is your main aim to
> learn a little Smalltalk? To make a
> useful tool for yourself? To make a useful tool for someone
> else? These are all worthy goals. My
> advice would depend on your goal. And of course, goals change.
> You might have started out just
> wanting to learn Smalltalk but now you just want to make a tool that
> someone else can use so you
> don't have to be in charge any more.
> On Sat, May 2, 2015 at 8:07 AM, Dan Norton <dnorton at mindspring.com>
> Dumb questions can have uses after all. Thank you Hannes and
> Ralph for your thoughtful
> responses. You must have been digging into the archives - my
> original post was nearly a
> year ago.
> Perhaps it is time to say what I chose to do. Design of Secret
> Santa was driven by:
> 1. A desire for simplicity
> 2. Relatively infrequent use (annual)
> Input is a text file listing the names of participants. A pair
> of names on the same line
> a couple. Output consists of the result of drawing names,
> compiled as a class method.
> Method names are serialized: drawn2012, drawn2013, ...
> The Transcript shows the latest drawing, as a Dictionary, which
> is compiled. Below that in
> Transcript are the statistics (iterations, rule violations). The
> image must be saved.
> I would appreciate any thoughts on application delivery. The
> above is a very crude, if not
> non-existent, way to deliver an app. Use of external files for
> output would improve things a
> little. Isn't it possible to do better than this for a Smalltalk
> app? What if the user is not a fan
> - Dan
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Beginners