[OT] functional paradigm taking over

ruby-talk
1

Hi,

just notice there seems to be a trend in industry to include
functional language features everywhere - now it's even in the new
C++:
http://www2.research.att.com/~bs/C++0xFAQ.html#lambda

JDK 8 will also include lambda support:
http://blogs.oracle.com/henrik/2010/10/java_roadmap_from_javaone_2010.html

It seems that in times of excessive CPU capacity and multiple cores
people turn to features which give more dynamic as well as easier
implementation of concurrent applications (no synchronization needed
when going strict functional). Amazing that Lisp is one of the oldest
languages around still in use and its family seems to be prepared to
finally reach mainstream. :slight_smile:

Cheers

robert

···

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

2

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.

People talk about the parallel programming advantages but what I like is

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.

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.

My other feeling is that typical functional languages (like typical
imperative languages) are unnecessily complicated. People struggle to
develop the most terse solution and gain great pleasure from doing so,
but as an old fashioned programmer, I don't immediately see what they
gain, apart from the sort of pointless satisfaction you get from
finishing a cryptic crossword. It would be nice if any move towards
functional approaches didn't ignore opportunities to make things easier
as well.

···

--
Posted via http://www.ruby-forum.com/.

3

It seems that in times of excessive CPU capacity and multiple cores
people turn to features which give more dynamic as well as easier
implementation of concurrent applications (no synchronization needed
when going strict functional). Amazing that Lisp is one of the oldest
languages around still in use and its family seems to be prepared to
finally reach mainstream. :slight_smile:

I think the same thing is happening with closures, but we haven't
gotten as far. It's still possible to promulgate a language like Java
that doesn't have practical closures. At the time I started writing,
Python didn't have closures at all and I heard Guido van Rossum say
that they weren't important. I think that's wrong, and that in another
thirty years people will laugh at anyone who tries to invent a
language without closures, just as they'll laugh now at anyone who
tries to invent a language without recursion.

-- Mark Jason Dominus, in an interview on "Higher Order Perl"

http://www.theperlreview.com/Interviews/mjd-hop-20050407.html

martin

···

On Wed, Mar 30, 2011 at 12:59 PM, Robert Klemme <shortcutter@googlemail.com> wrote:

Cheers

robert

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

4

This thread has been touching upon three issues - functional languages
as a way of expressing problems, Excel as a language environment, and
the programmer.

Today, relational databases are widely accepted. However Ted Codd did
not invent the relational model because he thought relations were neat.
If you look at what he said at the time, his motivation was to make
corporate data more accessible to non-programmers. Forty years ago he
thought there were less programmers than there were programs to be
written. Arguably the same is true today.

When I was a boy, I would see IDMS recordsets like this:

200
300
150
200
230
etc

What this represented was

2011/Q1 Sales = £200
2011/Q2 Sales = £300
2011/Q2 Sales = £150

Worse still you would have:

12
200
27
300
etc

which meant:
2011/Q1 Sales = £200
2011/Q1 Units = 12
2011/Q2 Sales = £300
2011/Q2 Units = 27
etc

Tedd said you must use relations. Relations are unordered so you can't
hide information in the order of data. Also you must have a field name
for each field (and it should be on the same domain, so Sales shouldn't
be in the same 'column' as Units).

You would therefore have to have:

Period Sales Units
2011/Q1 200 12
2011/Q2 300 27
etc

Whilst- as we all know - that typically doesn't tell you everything you
need to know when you come across a recordset, it makes it much easier
for someone not deeply involved in the system concerned, to work out
what is going on.

Put it another way, using relations makes it less likely you will make a
mistake because you didn't know the subtleties of the behaviour of the
programs generating that data.

Then, relations are amenable to first order predicate calculus. This
resticts the complexity of the operations you need to carry out.

When you consider the merits of functional languages, I believe you
should take into account not only the elegance with which you can
express what you want to do, or how amenable it is to eg parallel
processing. You should also consider whether it strikes a better balance
between such issues and accessibility. Does all your terseness and
'elegance' give you a justifiable advantage over something simpler which
could be more easily handled by a person of less capability?

···

--
Posted via http://www.ruby-forum.com/.

5

Everett

Generally speaking it's a calm, friendly, rational community, so don't
leave Ruby behind just because of tbis thread.

I've just learnt that with strangers - don't get into discussions about
sex, religion, politics or programming languages :slight_smile:

···

--
Posted via http://www.ruby-forum.com/.

6

What we've seen here is some people - but not all - have a fixed frame
of reference about what qualifies as a language.

If you are religious the terms 'good' and 'evil' have a very clear and
self-evident meaning. If you are an atheist they seem to be two sets of
rather similar things that appear to be rather arbitrary. The Christian
Old Testament said 'evil' was marrying people from other ethnic groups,
whereas killing them and their animals was 'good'. The Christian New
Testament changed those set memberships a bit.

Ruby is a very powerful language that also has the merit of being able
to express complexity in an elegant way. However if you don't
particularly need all that power then you shouldn't write off languages
which do some things easily but become contorted when you try and
replicate complex Ruby capabilities.

'Domain Specific Language' is a perjorative term. It's just saying I
can't conveniently do certain things I'm used to doing in the way I
prefer. To say that matters, you need to show that typical domains
definitely require such capabilities. My point earlier was not that I
was a superior being (I don't know where that came from) but that from
my experience in the oil, banking, insurance, corflakes and fragances
business, most programming is using quite basic features. OK, that might
not extend to nuclear fission reactors, but let's keep a sense of
proportion here.

There certainly is an argument that functional languages are more easily
mapped to multi-core computers. If I buy one of those S-word platforms,
I get sophisticated parallel processing built in for free. For Ruby, I
would have to carefully program that as Ruby has no general purpose
model/vocabulary/semantics for conveying or deducing dependancies.

Or has it?

···

--
Posted via http://www.ruby-forum.com/.

7

Phillip makes the assertion that Excel is not Turing-complete,
beginning the flame war:
http://groups.google.com/group/comp.lang.ruby/msg/27cebe32ec304c83

Anyone with a passing knowledge of the field would know that Excel is
Turing-complete because it can model Turing-complete cellular automata
(for instance the Game of Life). Also see Wolfram's NKS (though
Wolfram has become crank-like in other respects, he certainly knows CA).

History shows that Phillip will persist despite being factually
disputed. No doubt he will attempt to twist his way out of this one.
See him get refuted here:
http://groups.google.com/group/ruby-talk-google/msg/abb343631960cdad

Note his bizarre cockiness despite being totally wrong:
http://groups.google.com/group/ruby-talk-google/msg/da8cbb09529977d1

In order to understand who you're dealing with here, read Philip's
messages in that thread regarding IEEE infinity.

···

--
Posted via http://www.ruby-forum.com/.

8

Longest post for at least a year.

It would appear people are comfortable with discussing details but once
you stray into challenging their worldviews, you see quite different
behaviour patterns.

A reminder of why we have to have our bags searched at the airport.

···

--
Posted via http://www.ruby-forum.com/.

9

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

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.

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.

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:

    Fisher Price Toys & Baby Gear | Mattel

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.

···

On Wed, Mar 30, 2011 at 06:38:19PM +0900, Mike Stephens wrote:

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

10

I think thirty years is unrealistic. We're probably looking at something
more like fifteen, at this point. Since it has been six years since that
quote was made, by my estimation I think he overshot his guess by about a
decade. I suppose I could be mistaken.

···

On Thu, Mar 31, 2011 at 05:46:05AM +0900, Martin DeMello wrote:

I think the same thing is happening with closures, but we haven't
gotten as far. It's still possible to promulgate a language like Java
that doesn't have practical closures. At the time I started writing,
Python didn't have closures at all and I heard Guido van Rossum say
that they weren't important. I think that's wrong, and that in another
thirty years people will laugh at anyone who tries to invent a
language without closures, just as they'll laugh now at anyone who
tries to invent a language without recursion.

-- Mark Jason Dominus, in an interview on "Higher Order Perl"

http://www.theperlreview.com/Interviews/mjd-hop-20050407.html

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

11

When you consider the merits of functional languages, I believe you
should take into account not only the elegance with which you can
express what you want to do, or how amenable it is to eg parallel
processing. You should also consider whether it strikes a better
balance between such issues and accessibility. Does all your
terseness and 'elegance' give you a justifiable advantage over
something simpler which could be more easily handled by a person of
less capability?

Your argument is fap: programming isn't an abstract philosophy.
Meaningful debate is impossible without evidence.

Please provide specific examples. Show us something you don't
understand.

Cheers
Johnny

12

E.g. which language in particular do you have beef with? Why?

13

is this a good book to read to grok functional programming,
http://mitpress.mit.edu/sicp/full-text/book/book.html

I have done some lisp but interested in gaining the skillset with ruby,

any nice thick comp sci books for recommendation?

···

On Mon, Apr 4, 2011 at 4:05 AM, Mike Stephens <rubfor@recitel.net> wrote:

This thread has been touching upon three issues - functional languages
as a way of expressing problems, Excel as a language environment, and
the programmer.

Today, relational databases are widely accepted. However Ted Codd did
not invent the relational model because he thought relations were neat.
If you look at what he said at the time, his motivation was to make
corporate data more accessible to non-programmers. Forty years ago he
thought there were less programmers than there were programs to be
written. Arguably the same is true today.

When I was a boy, I would see IDMS recordsets like this:

200
300
150
200
230
etc

What this represented was

2011/Q1 Sales = £200
2011/Q2 Sales = £300
2011/Q2 Sales = £150

Worse still you would have:

12
200
27
300
etc

which meant:
2011/Q1 Sales = £200
2011/Q1 Units = 12
2011/Q2 Sales = £300
2011/Q2 Units = 27
etc

Tedd said you must use relations. Relations are unordered so you can't
hide information in the order of data. Also you must have a field name
for each field (and it should be on the same domain, so Sales shouldn't
be in the same 'column' as Units).

You would therefore have to have:

Period Sales Units
2011/Q1 200 12
2011/Q2 300 27
etc

Whilst- as we all know - that typically doesn't tell you everything you
need to know when you come across a recordset, it makes it much easier
for someone not deeply involved in the system concerned, to work out
what is going on.

Put it another way, using relations makes it less likely you will make a
mistake because you didn't know the subtleties of the behaviour of the
programs generating that data.

Then, relations are amenable to first order predicate calculus. This
resticts the complexity of the operations you need to carry out.

When you consider the merits of functional languages, I believe you
should take into account not only the elegance with which you can
express what you want to do, or how amenable it is to eg parallel
processing. You should also consider whether it strikes a better balance
between such issues and accessibility. Does all your terseness and
'elegance' give you a justifiable advantage over something simpler which
could be more easily handled by a person of less capability?

--
Posted via http://www.ruby-forum.com/\.

14

A) Provide examples that functional programming leads to "terseness"
(BTW, the Laconians of old Greece preferred to say as much as possible
in as few words as possible; one man's virtue is one man's sin, it
seems).

B) Define "accessibility". Surely you aren't saying that the UI of a
program is related to which language it was written in. If you mean
issues like maintainable code, isn't a strictly logical, mathematical
structure preferable, especially if it can be analyzed (tooling is our
friend) with the help of other programs? If, indeed, the code can be
*proven* to be correct (proven in the mathematical sense)?

C) Why should someone with less capability be taken care off by going
onto their levels, instead of helping them to reach new heights (we
could call such an effort "No Coder Left Behind")? Maths isn't hard,
nor is programming. So this smells like the plot of "Harrison
Bergeron" to me.

D) Wouldn't a person with less capability be aided by code that
follows simple, logical rules?

*sigh* This'll be the ORM debate all over again, I bet.

···

On Mon, Apr 4, 2011 at 11:05 AM, Mike Stephens <rubfor@recitel.net> wrote:

When you consider the merits of functional languages, I believe you
should take into account not only the elegance with which you can
express what you want to do, or how amenable it is to eg parallel
processing. You should also consider whether it strikes a better balance
between such issues and accessibility. Does all your terseness and
'elegance' give you a justifiable advantage over something simpler which
could be more easily handled by a person of less capability?

--
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.

15

*Mike,*

Mike Stephens wrote:

This thread has been touching upon three issues - functional languages
as a way of expressing problems, Excel as a language environment, and
the programmer.

When you consider the merits of functional languages, I believe you
should take into account not only the elegance with which you can
express what you want to do, or how amenable it is to eg parallel
processing. You should also consider whether it strikes a better balance
between such issues and accessibility. Does all your terseness and
'elegance' give you a justifiable advantage over something simpler which
could be more easily handled by a person of less capability?
   

*You have restated my point in much more pleasant language, and with commendable precision. The average person who wishes to program a solution to a problem cares not one whit whether the tool they find most accessible qualifies as a programming language by another person's definition. They just want to get their problem solved. Personally, though I have been arguning the side of Excel here, I hate spreadsheets. It is arguable that almost anything that can be accomplished with a database and implementing language such as SQL can be accomplished with a spreadsheet. I just happen to prefer the DB way of describing and thinking about data. But, as I have said, I have seen some absolutely amazing things doen with spreadsheets. My particular crutch for dealing with DB's is Alpha 5, but there are dozens of such solutions out there.

I happen to be a person with 45 years in the computing field, with specific knowledge of lambda calculus, Turing completeness, object orientation, structured programming, relational databases, and an host of other such things, but I have also learned that the real purpose of computer programs is to get work done unless I am specifically researching computing as a science. "Turing completeness" is a term of art that could be replaced in the minds of 99.9% of even fairly technically competent programmers with any other reference for which they have poor understanding. If being TC means that the tool can get the job done accurately and efficiently, including the time that it takes to create a program, then they are all for it. Most could not even accurately describe a Turing machine in the original sense of that definition.

Denigrating another person's choice of tools will certainly not make that person likely to seek your advice again, nor consider you helpful. If you have confused your switchblade with a Swiss Army knife, then you are more foolish than the person you are denigrating. Since this is a Ruby forum, sometimes the best answer is to refer a person to docs and/or books for deeper learning rather than try to answer the first problem that they run into as if that will really help them make efficient use of Ruby. Help with installing and making Ruby work properly are always appropriate, but only time and study and practice will actually allow people to program with any confidence. When people come from other programming disciplines, comparison of modalities and techniques are usually helpful, but fanboy expressions of "mine is bigger and/or better than yours" are not.

Eveerett L.(Rett) Williams II

···

*

16

Or spreadsheets ;)~

···

On Fri, Apr 8, 2011 at 4:04 PM, Mike Stephens <rubfor@recitel.net> wrote:

I've just learnt that with strangers - don't get into discussions about
sex, religion, politics or programming languages :slight_smile:

17

What we've seen here is some people - but not all - have a fixed frame
of reference about what qualifies as a language.

That "fixed frame of reference" is called a "definition" -- and
definitions are of critical importance to language. Without such
definitions, there would be no language; we would just be making
inarticulate noises at each other, without any communication or
understanding.

'Domain Specific Language' is a perjorative term.

No -- it's a descriptive term. A pejorative term would be something like
"blub language". The term "domain specific language" describes a
narrower focus, which makes it more suitable to certain tasks than a
domain nonspecific language, and less suitable to other tasks.

You act as though "domain specific" is a synonym for "crippled", but
that's not the case at all. It is, in some respects, more like saying
"chef" when referring to a knife. A chef knife is not "crippled" because
it is a poor choice for spreading butter on bread, opening an envelope,
or scaling a fish; it's just really good at certain cooking tasks, and
worse for other tasks, because it is specially designed for that
particular task at the cost of having features suitable to other tasks
neglected.

The fact that people say MS Excel is not a programming language is not
some kind of insult to MS Excel or personal slight aimed at its users.
It just means that Excel's design is better suited to use as a
spreadsheet than as a programming language. I wouldn't use Object Pascal
as a spreadsheet, either, but that doesn't mean it's useless or that
people who use it (like my father's use of its Delphi flavor) are idiots.

···

On Tue, Apr 12, 2011 at 09:31:34PM +0900, Mike Stephens wrote:

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

18

Thank you for that. I personally find language construction interesting.
It's a shame that people are just plugging their ears in this particular
topic. Though I think part of the problem is this topic is that some people
seem to think that a program is not a system. The problem with that idea is
what do you say when you start talking about languages built expressly for
designing what we are used to calling programming languages. Is the thing
output by an Antlr grammar spec a single unit that is not expressive, or is
it a system that is expressive? If one considers all programs systems that
express a subset of human thoughts the definitions of what these things are
remains consistent even at the level of language design.

···

On Wed, Apr 13, 2011 at 3:49 PM, Gregory Vella <gregory_vella@yahoo.com>wrote:

Phillip makes the assertion that Excel is not Turing-complete,
beginning the flame war:
http://groups.google.com/group/comp.lang.ruby/msg/27cebe32ec304c83

Anyone with a passing knowledge of the field would know that Excel is
Turing-complete because it can model Turing-complete cellular automata
(for instance the Game of Life). Also see Wolfram's NKS (though
Wolfram has become crank-like in other respects, he certainly knows CA).

History shows that Phillip will persist despite being factually
disputed. No doubt he will attempt to twist his way out of this one.
See him get refuted here:
http://groups.google.com/group/ruby-talk-google/msg/abb343631960cdad

Note his bizarre cockiness despite being totally wrong:
http://groups.google.com/group/ruby-talk-google/msg/da8cbb09529977d1

In order to understand who you're dealing with here, read Philip's
messages in that thread regarding IEEE infinity.

--
Posted via http://www.ruby-forum.com/\.

19

Nicely put. As the originator of this thread I am sorry where all
this went. My intent was to hear how other people view the tendency
to include functional features in other programming languages or
create hybrids from the start. Or hear whether they disagree that
such a tendency exists.

Unfortunately I am myself guilty of following that "Excel is (not) a
(functional) language" branch of the discussion that you lured us
into. :slight_smile: That is an interesting topic in itself but not what I had
in mind originally.

If there's still anybody out there who wishes to comment along the
original line of thought, please let's hear it.

Kind regards

robert

···

On Thu, Apr 14, 2011 at 9:28 AM, Mike Stephens <rubfor@recitel.net> wrote:

Longest post for at least a year.

It would appear people are comfortable with discussing details but once
you stray into challenging their worldviews, you see quite different
behaviour patterns.

A reminder of why we have to have our bags searched at the airport.

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

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

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

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.

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

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.

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:

Fisher Price Toys & Baby Gear | Mattel

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

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

Kind regards

robert

···

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:

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