1. Tutorial of sorts
- Posted by irv at ELLIJAY.COM
Oct 18, 1998
It looks like writing a tutorial is more work than anyone wants
to do - mainly because it's necessary to teach *programming* along
with *Euphoria*. So here's an alternative that makes it easier on
everybody, since anyone on this list can help when and if they want:
Assignment 1;
Write a program that takes input at the command line as follows:
C:> ex PAY Jose 40 12.00
and returns:
Name Hours worked Gross pay Tax Net pay
Jose 40 480.00 120.00 360.00
Hints:
See command_line and printf in your Euphoria docs.
For simplicity, tax is assumed to be fixed at 25% of gross.
Everyone is welcome to post solutions. Credit will be given for
clear, concise code, good comments, and use of Euphoria-specific
language features. Major points will be deducted for programs that
do not work. A lovely certificate of completion will be awarded at
the end of the course. That and $1.75 will get you a cup of Starbucks.
2. Re: Tutorial of sorts
- Posted by lithex <lithex at INTERGATE.BC.CA>
Oct 21, 1998
-
Last edited Oct 22, 1998
Hi
I like Irv's idea of programming problems as a way of teaching
Euphoria.
Here's my attempt at his first problem:
--Euphoria code starts:
--This is a version of PAY.ex
sequence cmd, name, temp
atom taxrate, hours, payrate, takehome, gross, tax
include get.e
cmd=command_line()
name=cmd[3]
temp=value(cmd[4]) hours=temp[2]
temp=value(cmd[5]) payrate=temp[2]
taxrate=0.25
gross=hours*payrate
tax=gross*taxrate
takehome=gross-tax
printf(1, "%9s %12.2f %12.2f %12.2f %12.2f", {name, hours, gross, tax,
takehome})
--Euphoria code ends
> It looks like writing a tutorial is more work than anyone wants
> to do - mainly because it's necessary to teach *programming* along
> with *Euphoria*. So here's an alternative that makes it easier on
> everybody, since anyone on this list can help when and if they want:
>
> Assignment 1;
> Write a program that takes input at the command line as follows:
> C:> ex PAY Jose 40 12.00
> and returns:
> Name Hours worked Gross pay Tax Net pay
> Jose 40 480.00 120.00 360.00
> Hints:
> See command_line and printf in your Euphoria docs.
> For simplicity, tax is assumed to be fixed at 25% of gross.
>
> Everyone is welcome to post solutions. Credit will be given for
> clear, concise code, good comments, and use of Euphoria-specific
> language features. Major points will be deducted for programs that
> do not work. A lovely certificate of completion will be awarded at
> the end of the course. That and $1.75 will get you a cup of Starbucks.
>
>
3. Re: Tutorial of sorts
lithex wrote:
> Here's my attempt at (Irv's) first problem:
> --This is a version of PAY.ex
> temp=value(cmd[4]) hours=temp[2]
> temp=value(cmd[5]) payrate=temp[2]
I hope I'm not intruding upon Irv's space when I say this,
and I also hope that I'm not viewed as being nit picky,
but I felt this was important to mention as it *is*
a learning situation...
My comment involves the throwing away of temp[1] in
the code lines above. I'm not real sure that is a wise
thing to do; after all, if the user of the program
mistyped something on the command line invoking the
program, and value() failed to convert it, then a very
ungracious program abortion will follow...
you can read that as 'bad nasty *crash*' :)
I would think that right about now would be the perfect
time to get into the habit of actually checking for
that situation, and if that situation is found, you can
either exit gracefully from the program (which gives you
the opportunity to save potentially precious data) or
you can reprompt the user for a more appropriate value.
Yes, I understand that the parameters for the "tutorial"
didn't really discuss this issue, but, once again, I
feel it's never too early to develop this habit...
you see this situation *actually coded* for (nearly) every
routine that uses: fn=open("blah","w") if fn=-1 then...
that gets posted to the listserv, so why should value()
be any different, eh? :)
As for the rest of the code, kudos indeed.
IMO, well written, nice variable names, easily read...
> Name Hours worked Gross pay Tax Net pay
> Jose 40 480.00 120.00 360.00
I am wondering about the header that was supposed to
go above the numeric output... ;)
but i'll leave that one up to Irv :)
take care, and I hope no feelings ruffled :)
--Hawke'
4. Re: Tutorial of sorts
Hah! - Bad habits revealed already!
Hawke is quite right - I've shamelessly neglected error checking in
my attempt at Irv's problem. I avoid error checking for the same
reason that I avoid Windows and gui's; that stuff is maybe 90% of
programming and none of the fun. For my own purpuses, I use David's
ee editor as my gui, and the programs crash most of the time anyway,
because as soon as they are debugged, I'm on to something else.
But, in the spirit of instruction, and for the purposes of this
thread, I'll try to mend my lazy ways. It's not easy mind - neither
mending my ways nor error checking.
Bye
Martin
5. Re: Tutorial of sorts
Here's another try
--Euphoria code starts
--This is a version of PAY.ex
sequence cmd, name, temp, titleline
atom taxrate, hours, payrate, takehome, gross, tax
titleline={"Name","Hours worked","Gross pay","Tax","Net pay"}
include get.e
cmd=command_line()
if length(cmd) !=5 then printf(1, "Data entry error at command
line",{}) abort(0) end if
name=cmd[3]
temp=value(cmd[4])
if temp[1]=GET_SUCCESS then hours=temp[2]
else printf(1, "Data error in hours",{}) abort(0) end if
temp=value(cmd[5])
if temp[1]=GET_SUCCESS then payrate=temp[2]
else printf(1, "Data error in rate",{}) abort(0) end if
taxrate=0.25
gross=hours*payrate
tax=gross*taxrate
takehome=gross-tax
printf(1, "%9s %12s %12s %12s %12s\n", titleline)
printf(1, "%9s %12d %12.2f %12.2f %12.2f", {name, hours, gross, tax,
takehome})
--Euphoria code ends
Bye
Martin
6. Re: Tutorial of sorts
On Thu, 22 Oct 1998 00:52:29 -0700, Hawke <mdeland at NWINFO.NET> wrote:
>lithex wrote:
>> Here's my attempt at (Irv's) first problem:
>> --This is a version of PAY.ex
>> temp=value(cmd[4]) hours=temp[2]
>> temp=value(cmd[5]) payrate=temp[2]
>I hope I'm not intruding upon Irv's space when I say this,
>and I also hope that I'm not viewed as being nit picky,
>but I felt this was important to mention as it *is*
>a learning situation...
...
>I would think that right about now would be the perfect
>time to get into the habit of actually checking for
>that situation, and if that situation is found, you can
>either exit gracefully from the program (which gives you
>the opportunity to save potentially precious data) or
>you can reprompt the user for a more appropriate value.
>
>Yes, I understand that the parameters for the "tutorial"
>didn't really discuss this issue, but, once again, I
>feel it's never too early to develop this habit...
Indeed, that is the next step in this tutorial - we are
trying to write something that will actually be _useful_,
so things like parameter checking are important.
>you see this situation *actually coded* for (nearly) every
>routine that uses: fn=open("blah","w") if fn=-1 then...
>that gets posted to the listserv, so why should value()
>be any different, eh? :)
The problem? We don't want to write three-line input validation
routines for every input - gets boring, takes up space, and
increases the opportunity for misteaks to crepe in.
So we have assignment 1.1
Write a *validate* function, to take input, return a number
within a specified range, or print an error message and
abort.
Hint: see functions, abort() in the docs.
Suggested syntax:
hours = validate(cmd[4],{1,80},"Hours")
payrate = validate(cmd[5],{5.50,35.00},"Payrate")
Suggested output:
* ERROR in Hours: should be between 1 and 80 *
Regards,
Irv
>As for the rest of the code, kudos indeed.
>IMO, well written, nice variable names, easily read...
>
>> Name Hours worked Gross pay Tax Net pay
>> Jose 40 480.00 120.00 360.00
>I am wondering about the header that was supposed to
>go above the numeric output... ;)
>but i'll leave that one up to Irv :)
We might have to deduct a couple of points for overlooking
the header ;)
Irv
7. Re: Tutorial of sorts
--On Wed, 21 Oct 1998 23:14:11 +0000, lithex <lithex at INTERGATE.BC.CA> wrote:
--Hi
--I like Irv's idea of programming problems as a way of teaching
--Euphoria.
--Here's my attempt at his first problem:
-------------------------------------------------------
-- * Comments added for those who are new to Euphoria *
-------------------------------------------------------
--Euphoria code starts:
--This is a version of PAY.ex
sequence cmd, name, temp
atom taxrate, hours, payrate, takehome, gross, tax
include get.e -- * file get.e allows you to use the value() function
cmd=command_line()
name=cmd[3] -- * command line input is parsed and can be indexed
-- * [1] will be the exe program, here "c:\euphoria\bin\ex.exe"
-- * [2] will be the ex program, here "pay"
-- * [3] will be "Jose"
-- * [4] will be 40
-- * [5] will be 12.00
-- * etc.
temp=value(cmd[4]) hours=temp[2]
temp=value(cmd[5]) payrate=temp[2]
-- * value returns a sequence of 2 numbers, i.e. {0,40}
-- * the first is a success/fail flag, the second is the value.
-- * if the first is not = GET_SUCCESS, then there was an error
-- * in the input, probably a non-numeric value.
taxrate=0.25
gross=hours*payrate
tax=gross*taxrate
takehome=gross-tax
printf(1, "%9s %12.2f %12.2f %12.2f %12.2f", {name, hours, gross, tax,
takehome})
--Euphoria code ends
-- Assignment 1;
-- Write a program that takes input at the command line as follows:
-- C:> ex PAY Jose 40 12.00
-- and returns:
-- Name Hours worked Gross pay Tax Net pay
-- Jose 40 480.00 120.00 360.00
-- Hints:
-- See command_line and printf in your Euphoria docs.
-- For simplicity, tax is assumed to be fixed at 25% of gross.
-- Everyone is welcome to post solutions. Credit will be given for
-- clear, concise code, good comments, and use of Euphoria-specific
-- language features. Major points will be deducted for programs that
-- do not work. A lovely certificate of completion will be awarded at
-- the end of the course. That and $1.75 will get you a cup of Starbucks.
Irv
8. Re: Tutorial of sorts
Irv wrote:
>So we have assignment 1.1
>Write a *validate* function, to take input, return a number
>within a specified range, or print an error message and
>abort.
>Hint: see functions, abort() in the docs.
>Suggested syntax:
>hours =3D validate(cmd[4],{1,80},"Hours")
>payrate =3D validate(cmd[5],{5.50,35.00},"Payrate")
>Suggested output:
>* ERROR in Hours: should be between 1 and 80 *
Here is my entry, I hope that it is not to long (>100 lines)
I use the function accept, developed by me because I was not satisfied wi=
th
the various input routines I used before. Especially the processing of
single ENTER or ESC keys. This one only accepts what you want it to accep=
t,
and the Backspace key.
Only problem is the CTRL-C or CTRL-Break checking. Under pure DOS this
works, but under WIN95 the program hangs. Does any1 have a solution to
this?
A more sophisticated version of accept.e can also accept function keys, t=
o
display help or popup a lookup table, for instance.
-- validate.ex
include file.e
include get.e
include graphics.e
global function equal(object o1, object o2) -- David Cuny
return not compare(o1, o2)
end function -- equal
-------------------------------------------------------------------------=
--
----
global procedure burp() -- Jiri Babor
atom tim
sound(250)
tim =3D time()
while time() - tim < .15 do
end while
sound(0)
end procedure -- burp
-------------------------------------------------------------------------=
--
----
global procedure backspace()
sequence pos
pos =3D get_position()
if pos[2] >=3D 1 then
position(pos[1], pos[2] - 1)
puts(1, ' ')
position(pos[1], pos[2] - 1)
else
burp()
end if
end procedure -- backspace
-------------------------------------------------------------------------=
--
----
global function accept(sequence prompt, sequence default, sequence
accepted)
-- version 0.02 -- October 23, 1998
-- Ad_Rienks at compuserve.com
-- returns a string, if a single enter is pressed default is returned
-- only characters you give in 'accepted' are accepted
-- so it can be used like this:
-- question =3D accept("Do you want to go on? (Y/n) ", "y", "YyNn")
-- if lower(question[1]) =3D 'y' then go_on() else exit end if
integer key
sequence string, pos
allow_break(0) -- user can't escape with CTRL-C or CTRL-Break
-- CAUTION: this does not work under WIN95!!!
key =3D -1
string =3D ""
puts(1, prompt & default)
pos =3D get_position()
position(pos[1], pos[2] - length(default)) =
while key !=3D 13 do
if key !=3D -1 then
if key =3D 8 and length(string) then -- backspace
-- remove last element
string =3D string[1..length(string) - 1]
-- update display too
backspace()
elsif find(key, accepted) then
if not length(string) then
puts(1, repeat(' ', length(default)))
position(pos[1], pos[2] - length(default)) =
end if
string =3D append(string, key)
puts(1, string[length(string)])
else
burp()
end if
end if
key =3D get_key()
end while
if equal(string, "") then
string =3D default
end if
allow_break(1) -- set breaking ability back on
return string
end function -- accept
-------------------------------------------------------------------------=
--
-----
global function validate(sequence prompt, -- the input prompt
sequence default, -- possible default value
sequence accepted, -- characters accepted
sequence bounds) -- possible bounds, if {}, no=
bounds checking.
object result =
while 1 do
clear_screen()
result =3D value(accept(prompt, default, accepted))
if result[1] =3D GET_SUCCESS then
result =3D result[2]
else
result =3D -1
end if
if length(bounds) then -- bounds checking
if result < bounds[1] or result > bounds[2] then
-- not within bounds
burp()
position(25, 1)
printf(1, "Give a number between %.2f and %.2f.", bounds)=
cursor(NO_CURSOR)
result =3D wait_key()
cursor(UNDERLINE_CURSOR)
else-- within bounds
exit
end if
else -- no bounds checking
exit
end if
end while
return result
end function -- validate
constant INTEGER =3D "0123456789"
constant DECIMAL =3D INTEGER & '.'
integer hours
atom payrate
=
hours =3D validate("Hours worked: ", "", INTEGER, {1, 80})
payrate =3D validate("Payment/hour: ", "", DECIMAL, {5.5, 35})
clear_screen()
puts(1, "Hours Payment Tax Net Pay")
printf(1, "\n%5d %7.2f %7.2f %7.2f",
{hours, payrate, hours*payrate*.25, hours*payrate*.75})
9. Re: Tutorial of sorts
Irv Mullins wrote:
> So we have assignment 1.1
> Write a *validate* function, to take input, return a number
> within a specified range, or print an error message and
> abort.
<me put hand up, meekishly>
ummm....
abort(). bad... bad bad.
<me watch user lose data>
allow user to re-enter improper data. good.
<me watch user retain data>
</me put hand up>
assignment 1.1A perhaps?
Write a validate function, to take an input from the
user or the command line, and return a number within
a specified range, or print an error message and
allow the user the ability to retype the improper input,
without having to have the user retype *all* of the
other inputs (such as only one parameter on the command
line being improper... just fix that one parameter)
10. Re: Tutorial of sorts
- Posted by Irv Mullins <irv at ELLIJAY.COM>
Oct 23, 1998
-
Last edited Oct 24, 1998
On Fri, 23 Oct 1998 18:42:35 -0700, Hawke <mdeland at NWINFO.NET> wrote:
>Irv Mullins wrote:
>> So we have assignment 1.1
>> Write a *validate* function, to take input, return a number
>> within a specified range, or print an error message and
>> abort.
>
><me put hand up, meekishly>
>
>ummm....
>abort(). bad... bad bad.
><me watch user lose data>
>
>allow user to re-enter improper data. good.
><me watch user retain data>
>
></me put hand up>
>
>assignment 1.1A perhaps?
>Write a validate function, to take an input from the
>user or the command line, and return a number within
>a specified range, or print an error message and
>allow the user the ability to retype the improper input,
>without having to have the user retype *all* of the
>other inputs (such as only one parameter on the command
>line being improper... just fix that one parameter)
OK, if you can do it in 10 lines or less. We're trying to
keep this at the beginning programmer level.
Besides, it's good for the programmer to learn that data
*CAN* get lost, and why.
It makes for more careful programmers.
Suppose you are printing paychecks for 3,000 people.
Do you stop and ask for each incorrect entry, or is there
a better way?
Irv
11. Re: Tutorial of sorts
>>assignment 1.1A perhaps?
>>Write a validate function, to take an input from the
>>user or the command line, and return a number within
>>a specified range, or print an error message and
>>allow the user the ability to retype the improper input,
>>without having to have the user retype *all* of the
>>other inputs (such as only one parameter on the command
>>line being improper... just fix that one parameter)
Irv wrote:
>OK, if you can do it in 10 lines or less. We're trying to
>keep this at the beginning programmer level.
I get your point 
Allright, here's my attempt. The function is 12 lines. You can deduct me =
2
points.
-- validate.e
-- a simple function to get data input from the user, and check for bound=
s
include get.e
function validate(sequence prompt, sequence bounds)
object result
while 1 do
puts(1, prompt & ' ')
result =3D gets(0)
result =3D value(result[1..length(result)-1])
if result[1] =3D GET_SUCCESS then
if result[2] >=3D bounds[1] and result[2] <=3D bounds[2] then=
return result[2]
end if
end if
printf(1, "\nError! Range =3D %.2f to %.2f\n", bounds)
end while
end function
--test
? validate("Hours worked:", {1, 80})
-- end of Euphoria code
Ad
12. Re: Tutorial of sorts
On Sat, 24 Oct 1998 05:42:03 -0400, Ad Rienks <Ad_Rienks at COMPUSERVE.COM>
wrote:
>>>assignment 1.1A perhaps?
>Allright, here's my attempt. The function is 12 lines. You can deduct me 2
>points.
>
>-- validate.e
>-- a simple function to get data input from the user, and check for bounds
>
>include get.e
>
>function validate(sequence prompt, sequence bounds)
>object result
> while 1 do
> puts(1, prompt & ' ')
> result = gets(0)
> result = value(result[1..length(result)-1])
> if result[1] = GET_SUCCESS then
> if result[2] >= bounds[1] and result[2] <= bounds[2] then
> return result[2]
> end if
> end if
> printf(1, "\nError! Range = %.2f to %.2f\n", bounds)
> end while
>end function
>
>--test
>? validate("Hours worked:", {1, 80})
>-- end of Euphoria code
>
>Ad
Now, here's a chance to illustrate something about programming:
The above routine is specialized, in that it always takes input from
the keyboard.
We have to write another routine to validate input entered on
the command line, and perhaps another for input from a disk file.
No fun, amd more code = more bugs
So, I suggest we write:
1. a validate routine that takes passed input and validates it,
regardless of whether the input comes from the keyboard,
the command line, or a disk file.
Q. What are the appropriate responses to the following failures?
1. Keyboard input invalid:
2. Command line input invalid:
3. Disk input invalid:
2. an input routine that prints a prompt, calls validate, and
returns the keyed input, or retries if the validity check fails.
Q. How best to indicate the reason for the failure,
so the user can try again?
(This should be something more meaningful than BASIC's
silly RE-DO FROM START message!)
We'll use these two routines in almost every program from now on,
so it's worth spending a little time writing various versions.
Apologies if this gets posted twice, my ISP is changing their
mail server this weekend, and all kinds of strange things are
happening.
Irv
13. Re: Tutorial of sorts
Irv Mullins wrote:
> Suppose you are printing paychecks for 3,000 people.
> Do you stop and ask for each incorrect entry, or is there
> a better way?
I would say, no, do not stop processing as that will allow
you to at least get out the checks that are right/proper.
IMO, what should happen to the 'bad' checks/data is a log
file would be written that indicated who the check was
for (either name or SS# or employee# or all of above),
how much the check was about to be written for
(ergo:the bad data), and at the end of the processing
of all the good checks, a single, attention grabbing,
error message that indicates a log file was indeed written.
if you want fancy, you could allow the user an
option to immediately view/print that log file.
so, as a side tutorial/challenge to the ones that
Irv has given, I'd like to propose the following exercise:
**write a function that accepts a single sequence/string,
**and writes that string to the bottom of a log file
**called "badcheck.log".
**if that file does not exist, then make it anew.
**each entry in the log file should be time/date stamped.
**an example log entry might be:
** May 3, 1998 at 17:32
** Jose Hernandez #121099 $135355.67
**that last line is what got passed to the log file routine
**and should have been preformatted before the function call.
**this way, the log file routine can be program independent.
**to wit: the call to the routine might be:
** for i=1 to length(database) do
** current=database[i]
** if current[NETPAY]<bounds[NETPAY][LOW] or
** current[NETPAY]>bounds[NETPAY][HIGH] then
** temp={}
** temp=current[NAME] &
** sprintf(" #%d",current[EMPLNUM]) &
** sprintf(" $%0.2f\n",current[NETPAY])
** logfile(temp)
** LOGWRITTEN=TRUE
** else PrintCheck(current)
** end if
** end for
** if LOGWRITTEN then
** puts(1,"Error encountered. See 'badcheck.log' for details.\n")
** end if
now, please, be careful when programming this, as it can
be a tad "dangerous" to program file manipulation routines.
things to watch for would be closing open files at the
proper time,reading/writing to valid file 'handles', and
checking your 'success/fail' values (just like value()).
a file handle is simply a number assigned to a file name,
just like 1 is the screen and 0 is the keyboard.
information to read would be the "open()" and "close()"
commands, as well as "puts()","printf()" and "sprintf()"
in library.doc.
enjoy!--Hawke'
14. Re: Tutorial of sorts
On Sat, 24 Oct 1998 18:47:50 -0700, Hawke <mdeland at NWINFO.NET> wrote:
(see previous message)
Some very good points:
Let's try to develop this as if it were a real-life programming
project.
I will supply the main body of code, written so that a client
could understand it. (They tend to like things like that.)
Anyone who wants to work on the tutorial can supply the functions/
procedures needed to implement the code. There *MUST* be more than
one way to implement each of these. Some ways are more Euphoric
than others. I hope to see some examples! Here goes:
-- PAY.EX - a payroll program written in Euphoria
-- version 1.3
object cmd -- storage for data input on the command line
atom data_is_valid
cmd = command_line() -- we'll get it the most simple way for now
if length(cmd) = 5 then -- valid number of arguments supplied
data_is_valid = TRUE
else -- invalid number of arguments supplied
notify("Syntax is:",
"ex pay employee-name hours-worked pay-rate")
abort(1) -- no point in going any further
end if
emp[name] = cmd[3] -- extract input items
emp[hours] = valid(cmd[4],{1,80},"Hours") -- and check for
emp[payrate] = valid(cmd[5],{5.25,35.00},"Payrate") -- reasonable values.
if data_is_valid then
print_check(emp)
log("PAYROLL.DAT",emp)
else
log("PAYERR.DAT",emp)
notify("Error",
"Unreasonable hours or payrate entered - see file PAYERR.DAT")
abort(1)
end if
--- end of program
-- FORMATS
-- for now, the check can simply be two lines to the screen:
-- Name Hours Payrate Gross Tax Net
-- Juan 40.0 12.00 480.00 120.00 360.00
-- the logfile formats
-- for PAYROLL.DAT:
-- 00/00/00 Juan 40.0 12.00 480.00 120.00 360.00
-- for PAYERR.DAT:
-- 00/00/00 Juan 40.0 333.00
-- end of assignment
15. Re: Tutorial of sorts
- Posted by John Worthington <woodmage at EARTHLINK.NET>
Oct 26, 1998
-
Last edited Oct 27, 1998
Irv Mullins wrote:
> Some very good points:
> Let's try to develop this as if it were a real-life programming
> project.
> I will supply the main body of code, written so that a client
> could understand it. (They tend to like things like that.)
>
> Anyone who wants to work on the tutorial can supply the functions/
> procedures needed to implement the code. There *MUST* be more than
> one way to implement each of these. Some ways are more Euphoric
> than others. I hope to see some examples! Here goes:
I've been rather busy trying to get my Debian Linux system up and running
correctly and therefore haven't had much time for Euphoria. But I've been
watching this mailing list and this thread in particular is getting more and
more interesting. ;') At first, it seemed to be rather simplistic even to
my poor programming skills. As it has gone on, it has gotten better and
better. Now it looks like it's going to teach me yet another thing: how to
program as part of a team. Now, I'm not sure that's exactly what is
intended, but it sort of looks that way. If so, I'd like to suggest we make
some sort of rules about how the various sections or modules of this program
fit together. The validation part has this criteria, but so far, the rest
doesn't seem to. Well, once again, thanks for giving me some excellant stuff
to look at! ;')
\/\/ood/\/\age
PS: I'm still enjoying the Windoze tutorial too. When I get stuff set up,
I'm gonna be working on a lot of this stuff.
PPS: You know, guys, we need to work on that Euphoric OS in here. There is
excellant back and forth error correction, optimizing, and just general
brainstorming in here. ;')
PPPS: Anybody know how different the Linux brand Euphoria is? (I promise,
that's all the P's I'm gonna put on the PS. <grin>)
16. Re: Tutorial of sorts
On Mon, 26 Oct 1998 23:46:13 -0600, John Worthington <woodmage at EARTHLINK.NET>
wrote:
>Irv Mullins wrote:
>
>> Some very good points:
>> Let's try to develop this as if it were a real-life programming
>> project.
<snip>
>I've been rather busy trying to get my Debian Linux system up and running
>correctly and therefore haven't had much time for Euphoria. But I've been
>watching this mailing list and this thread in particular is getting more and
>more interesting. ;') At first, it seemed to be rather simplistic even to
>my poor programming skills. As it has gone on, it has gotten better and
>better.
Well, there's the problem. Some people on this list have probably
fought to get "Hello World" running in Euphoria, while others
are ...ahem.. a bit more advanced. So where to start?
My guess is that there is a point beyond which programs become
too complex to discuss and learn from on a mail list. So I'm
trying to keep it simple. Also, not every guru on this list has
time to devote to a long program, but perhaps they will comment
on something short.
As an example, see the thread about dates - note how much
shorter and clearer the function became after a few people
contributed ideas.
>Now it looks like it's going to teach me yet another thing: how to
>program as part of a team. Now, I'm not sure that's exactly what is
>intended, but it sort of looks that way. If so, I'd like to suggest we make
>some sort of rules about how the various sections or modules of this program
>fit together.
I intentionally left the implementation of those things open.
There's usually more than one way to do something, and my way
is often not the best. I did not intentionally make it a team
project, but I like the idea. Any largish programming project
would be handled that way.
Regards,
Irv
17. Re: Tutorial of sorts
- Posted by John Worthington <woodmage at EARTHLINK.NET>
Oct 27, 1998
-
Last edited Oct 28, 1998
> >> Some very good points:
> >> Let's try to develop this as if it were a real-life programming
> >> project.
> >more interesting. ;') At first, it seemed to be rather simplistic even to
> >my poor programming skills. As it has gone on, it has gotten better and
> >better.
> Well, there's the problem. Some people on this list have probably
> fought to get "Hello World" running in Euphoria, while others
> are ...ahem.. a bit more advanced. So where to start?
> My guess is that there is a point beyond which programs become
> too complex to discuss and learn from on a mail list. So I'm
> trying to keep it simple. Also, not every guru on this list has
> time to devote to a long program, but perhaps they will comment
> on something short.
> As an example, see the thread about dates - note how much
> shorter and clearer the function became after a few people
> contributed ideas.
True, that's one thing I do like about this list. The way functions sorta get
bounced
around until they are tiny and effective as can be. ;') I think I may have
learned
quite a bit just watching people working on these little functions (which
usually do not
matter to me at the time but the TECHNIQUE does). But, yes, I think you are
doing a
pretty good job. Almost any tutorial should probably start off as simplistic as
possible so as to catch everybody. Its just unfortunate that so many never seem
to get
beyond that stage! <g>
> >intended, but it sort of looks that way. If so, I'd like to suggest we make
> >some sort of rules about how the various sections or modules of this program
> >fit together.
> I intentionally left the implementation of those things open.
> There's usually more than one way to do something, and my way
> is often not the best. I did not intentionally make it a team
> project, but I like the idea. Any largish programming project
> would be handled that way.
Hmm, yes, I see. Well, I do like what has come so far. I suppose I'm clamoring
for the
rules thingies because I am not sure I know how to function with such stuff. In
other
words, trying to add a personal deficit to the tutorial. <g> Anyways, great
work,
Irv. Keep it up. Laters,
\/\/ood/\/\age
