--WIyZ46R2i8wDzkSu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 30, 2011 at 06:38:19PM +0900, Mike Stephens wrote:
>=20
> Although a Ruby fan, I must say I'm spending all my time looking at
> functional programming at the moment. Not, by the way, deeply
> mathematical languages like F#, Haskell etc but a new very simple
> easy-to-use language called S#.
>=20
> Well it's not new at all. It's just Excel but you can't say that at
> parties so I had to make up a new name.

Wait, I'm confused . . .

Are you saying that you're creating some kind of stand-alone variant of
VBA (which is what Excel uses for macros), or are you saying that you use
a spreadsheet application to write "programs" and call it S# to confuse
people (in which case it worked on me)?  I'm frankly appalled at the idea
of people writing "programs" in Excel; it's three metric tons of VM-like
overhead to produce "software" that is necessarily far too limited to
even have bothered.

If you want a simple, nominally-functional language, try Scheme.  Just
don't expect getting "real world" work done to be very easy as long as
the community's internal differences of opinion over what constitutes
good language design or how to define "compatible" continue.  Scheme is
in effect a great learning language, for now, but not very useful in the
real world unless you're willing to write your own libraries -- but you
seem interested in experimenting with functional programming from what
you said, rather than having an industrial-strength, practical
programming tool, so maybe that's okay.


>=20
> People talk about the parallel programming advantages but what I like

I'm pretty sure nobody is talking about the parallel programming
advantages of VBA, either inside Excel or outside of it.


>=20
> 1) You can easily see what's going on. Every time you write a line of
> code, you immediately see the consequences of what you've written. You
> don't need to run anything, debug anything. That's of course a feature
> of Excel in its role as an IDE that autocalculates.
>=20
> 2) Excel is innately efficient. It can run millions of calculations per
> second.
>=20
> 3) It's good fun devising new algorithms. You've spent all your life
> thinking in terms of iterations. Now you have to think of evaluating
> variable length data structures and picking out the outcomes after
> they've all 'run'. For example, if you want to service a web request,
> you have to generate both the normal and error pages at the same time,
> as you only have one shot in functional programming.
>=20
> I got into this accidentally. I was working on using Ruby to script a
> spreadsheet to provide insurance quotes. The more I looked at it the
> more I could see Excel doing the logic until I wondered whether I could
> virtually eliminate Ruby apart from web server handling - capturing the
> incoming parameters and translating the output pages into HTML.

Maybe you'd like working with a database management system that offers
some kind of stored procedures or triggered functions capabilities more.
Excel is to DBMSes as those old Power Wheels toys are to actual cars,
after all:

    http://www.fisher-price.com/us/powerwheels/


>=20
> Most people would not want to pursue this line of thinking but I
> mention it because it seems to me that you should either do functional
> or imperative. Languages like Ruby which let you mix paradigms are
> going to lead you into difficult decisions about what you use where.

I disagree.  I find myself doing a fair bit of functional style
programming in small pieces within the larger object oriented style
structure of code that I write in Ruby, and my code is better for it.

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

--WIyZ46R2i8wDzkSu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk2TQCMACgkQ9mn/Pj01uKX3SgCg0+SpcSJztUF5PnLz/cjSkoKY
fH4AnRnyFWPeGZwovFo+Zc1PpnbxBpXw
=kvKR
-----END PGP SIGNATURE-----

--WIyZ46R2i8wDzkSu--

On Wed, Mar 30, 2011 at 06:38:19PM +0900, Mike Stephens wrote:
>=20
> Although a Ruby fan, I must say I'm spending all my time looking at
> functional programming at the moment. Not, by the way, deeply
> mathematical languages like F#, Haskell etc but a new very simple
> easy-to-use language called S#.
>=20
> Well it's not new at all. It's just Excel but you can't say that at
> parties so I had to make up a new name.

Wait, I'm confused . . .

Are you saying that you're creating some kind of stand-alone variant of
VBA (which is what Excel uses for macros), or are you saying that you use
a spreadsheet application to write "programs" and call it S# to confuse
people (in which case it worked on me)?  I'm frankly appalled at the idea
of people writing "programs" in Excel; it's three metric tons of VM-like
overhead to produce "software" that is necessarily far too limited to
even have bothered.

If you want a simple, nominally-functional language, try Scheme.  Just
don't expect getting "real world" work done to be very easy as long as
the community's internal differences of opinion over what constitutes
good language design or how to define "compatible" continue.  Scheme is
in effect a great learning language, for now, but not very useful in the
real world unless you're willing to write your own libraries -- but you
seem interested in experimenting with functional programming from what
you said, rather than having an industrial-strength, practical
programming tool, so maybe that's okay.


>=20
> People talk about the parallel programming advantages but what I like

I'm pretty sure nobody is talking about the parallel programming
advantages of VBA, either inside Excel or outside of it.


>=20
> 1) You can easily see what's going on. Every time you write a line of
> code, you immediately see the consequences of what you've written. You
> don't need to run anything, debug anything. That's of course a feature
> of Excel in its role as an IDE that autocalculates.
>=20
> 2) Excel is innately efficient. It can run millions of calculations per
> second.
>=20
> 3) It's good fun devising new algorithms. You've spent all your life
> thinking in terms of iterations. Now you have to think of evaluating
> variable length data structures and picking out the outcomes after
> they've all 'run'. For example, if you want to service a web request,
> you have to generate both the normal and error pages at the same time,
> as you only have one shot in functional programming.
>=20
> I got into this accidentally. I was working on using Ruby to script a
> spreadsheet to provide insurance quotes. The more I looked at it the
> more I could see Excel doing the logic until I wondered whether I could
> virtually eliminate Ruby apart from web server handling - capturing the
> incoming parameters and translating the output pages into HTML.

Maybe you'd like working with a database management system that offers
some kind of stored procedures or triggered functions capabilities more.
Excel is to DBMSes as those old Power Wheels toys are to actual cars,
after all:

    http://www.fisher-price.com/us/powerwheels/


>=20
> Most people would not want to pursue this line of thinking but I
> mention it because it seems to me that you should either do functional
> or imperative. Languages like Ruby which let you mix paradigms are
> going to lead you into difficult decisions about what you use where.

I disagree.  I find myself doing a fair bit of functional style
programming in small pieces within the larger object oriented style
structure of code that I write in Ruby, and my code is better for it.

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk2TQCMACgkQ9mn/Pj01uKX3SgCg0+SpcSJztUF5PnLz/cjSkoKY
fH4AnRnyFWPeGZwovFo+Zc1PpnbxBpXw
=kvKR
-----END PGP SIGNATURE-----