On Wed, Mar 30, 2011 at 4:49 PM, Chad Perrin <code / apotheon.net> wrote:
> On Wed, Mar 30, 2011 at 06:38:19PM +0900, Mike Stephens wrote:
>>
>> 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#.
>>
>> 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 . . .

That's usually where the intellectual fun begins. :-)

> 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)?  §   
> 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.

I believe he means that Excel is a processor for dependent formulas
which, by virtue of update event propagation, gives you instantaneous
value updates in all relevant places.

> If you want a simple, nominally-functional language, try Scheme.  > 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.  
> 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.

I'd like to throw in Scala here.  Although it's not complete yet as a
language there are some interesting concepts (including functional) -
and you can use the wealth of libraries available for the JVM.

http://www.scala-lang.org/

>> 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.

I don't know how Excel works internally but it is completely possible
that evaluation updates are calculated in parallel.  This is possible
because Excel knows all the value dependencies between cells.  Which
brings me to something I have been wanting to ask: is there something
like a gem containing a DSL for such descriptions?  I imagine building
dependency graphs (trees for the start) of tasks where output of
several other tasks can be fed into a task.  That then would make
parallel execution pretty easy.

>> 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.
>>
>> 2) Excel is innately efficient. It can run millions of calculations per
>> second.
>>
>> 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.
>>
>> 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:
>
>  𺯯

Hmm, I think I disagree.  In parts you can use Excel (or any other
spreadsheet like OpenOffice, LibreOffice...) like a relational
database.  But organizing and filtering data is just one part of
Excel's functionality - and one where it doesn't shine (once you get
into the 10,000 range of rows at least).  But a spreadsheet
application is mostly something different: a smart way to lay out
formulas in 2D to get instant calculations; basically it is a event
processor with user friendly user interface. (Note: in my observation
despite Excel's amazing capabilities many people seem to feel more at
home with stuffing tons of macros in their sheets where a few smartly
connected cell functions or a pivot table would have sufficed).

>> 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.        > 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.

And funnily enough I just posted my observation today, that more and
more languages incorporate functional features. :-)
-> "[OT] functional paradigm taking over"

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/