Functional paradigm taking over

Ruby
21

On 03.04.2011 09:48, Phillip G. wrote:

On Sun, Apr 3, 2011 at 7:29 AM, Mike S.[email protected] wrote:

But the other point is why does everybody make languages so difficult
these days?

I am not sure I fully agree to this observation. First, I believe
languages are rather becoming simpler than more complex these days. On
the other hand with increased power of hardware and increased volume of
library code the problems that we tackle today are becoming increasingly
complex. Also, the mere fact that we need to utilize concurrency to
solve problems (because single CPU isn’t going to grow that much in the
near future) does make applications more complex.

And really, if you have problems with recursiveness, I dare say that
you didn’t enjoy college, considering the importance of maths in the
natural sciences. Just plain ol’ acceleration is a recursive function:
changes of velocity over time are easiest calculated by recursion,
wouldn’t you say?

Functional programming requires a particularly, let’s say
anal-retentive, mindset, given the importance of type safety, and that
variables, usually, aren’t variables. On the flipside, it makes
concurrency easier, and is a boon for critical code (you know,
robotics, MRI scanners,&c.).

Personally what I find most difficult to grasp about functional
programming is not the paradigm itself but rather the feature of Lisp
that macros and functions are syntactically indistinguishable. While
this makes for elegant solutions on one hand it can be confusing to read
on the other (and just think about the various quoting mechanisms of
Lisp). YMMV though.

Of course, you have to encourage people to invent Lambda Calculus and
then turn it into a computing language but such university thesis ideas
shouldn’t be seen as the model for real world products.

Yet there were ~7000 LISP machines sold (at, say, 100 000 per unit,
that’s still quite a bit of revenue):

Lisp machine - Wikipedia

Even if there weren’t where’s the argument? All engineering is based on
results of science of one form or another (and math is often one of
them). If research turns up something which can be used to model real
world phenomena of a particular class more efficiently than other
approaches then it should (and will) be used. There’s still enough room
to apply other approaches and nobody forces Mike to go functional, does
he?

Kind regards

robert

22

I guess my little bit of tinkering with this leads me to ask "Why
should I have to instruct the computer how to navigate data
structures and code my own error capturing?

Gee if only you had strong typing you wouldn’t get those errors. And
if only the compiler could generate the code for your specific use case
on a specific data structure, given that you could prove it held
certain properties…

…but wait, that sounds like that horrible functional school! SHUN
THOSE TECHNIQUES, SHUN THEM MY PRETTIES!

You would need a web server to launch each Excel ‘program’, and you
would need a module that converts formatted Excel pages into HTML.
Some functions like calling web services and HTML formatting might
practically have to be implemented as non-Excel code (eg VBA or Ruby)
but as these would require only simple configuration they could be
viewed as extensions to the inbuilt functions and would not require
programming ability on the part of the user.

Assuming our developers are possessed of sound mind, they
may instead choose to achieve your aims in this manner:

  1. Data is generated from the spreadsheet and inserted into a
    database.

  2. Then a dynamic website (not written in Excel) reads from the
    database.

This is an example of how different software tools, each specialized
for a different task, work together to perform a cohesive action.
Everything has its place.

IMO that is the way of the Tao. Choosing Excel above all
else does not lead to the Tao. Instead it leads down the path of Rube
Goldberd, that you illustrate above.

Cheers
Johnny

23

*Let’s not pay too much attention to the code snobs on here. I’ve yet to
see a recursive function that is more efficient than a more linearly
coded function that accomplishes the same thing, and there is always the
problem of curtailing recursion. People often mistake shortest code for
the most efficient or effective, and that is seldom true. In addition,
there are a whole host more people who can write acceptable programs in
Excel than there are who can do so in Ruby or probably the sum of all
the languages that are in that category. Most of them are not as pretty
to the mind of someone who programs for a living, but I have seen a
whole lot more things written in Excel…repeat…repeat. That does not
mean that it is desirable to write highly complex and detailed projects
in Excel, largely because of the distribution cost. If Excel were free,
you would see even more stuff written in it. The other main defects in
Excel are that it is hard to control a product written in it because you
are dependent on Microsoft-ian whims. The latter is the least of the
problems. You also have to have a lot more financial muscle to get into
the Excel game at the commercial level. And last, there is the question
of portability/compatibility across various environments. If you are
after the 80-90% of intel x86 compatible machines that run Windows, that
is not an issue. I won’t even say that maintenance is a bigger problem
in Excel, though the issue can be argued in many different ways.

Once you have made up your mind to use a tool like Ruby, you have to
pick a flavor, and you really need to know C/C++ as well as Ruby to
really be able to use Ruby. If you intend to have cross-platform
support, you need to understand the subtleties of the various platforms
you intend to support, which is a problem in almost any language. Perl
and Python and especially java should also be considered, especially if
there is a history of coding in one of those languages within your
organization. All that aside, Ruby is an excellent and well supported
tool, well worth your time and effort, but something that should be
considered is that the simplest tool that is effective should usually be
used. Good luck.

Everett L.(Rett) Williams II

24

On Sun, Apr 3, 2011 at 1:00 PM, Robert K.
[email protected] wrote:

I am not sure I fully agree to this observation. First, I believe languages
are rather becoming simpler than more complex these days. On the other hand
with increased power of hardware and increased volume of library code the
problems that we tackle today are becoming increasingly complex. Also, the
mere fact that we need to utilize concurrency to solve problems (because
single CPU isn’t going to grow that much in the near future) does make
applications more complex.

Further, if anyone thinks that using a modern language is complex and
/ or difficult, I recommend some quality time with x86 assembly.

I still have nightmares from IT class back in school, and it’s been
years. :wink:

Personally what I find most difficult to grasp about functional programming
is not the paradigm itself but rather the feature of Lisp that macros and
functions are syntactically indistinguishable. While this makes for elegant
solutions on one hand it can be confusing to read on the other (and just
think about the various quoting mechanisms of Lisp). YMMV though.

Though, I’d be careful in calling LISP a functional programming
language. While it does use the lambda calculus, it doesn’t
guarantee that functions are free from side effects. And its raison de
entre is that data and code are mutable, which is antithetical to
pure-bred functional programming languages.

Though, considering that LISP was one of, if not the, first language
to use the lambda calculus as basis for a programming language, it is
certainly a forefather of today’s crop of functional programming
languages, like Scheme, ML, Erlang, Haskell, or F#.

Even if there weren’t where’s the argument? All engineering is based on
results of science of one form or another (and math is often one of them).
If research turns up something which can be used to model real world
phenomena of a particular class more efficiently than other approaches then
it should (and will) be used. There’s still enough room to apply other
approaches and nobody forces Mike to go functional, does he?

Speaking of engineering and functional programming:

http://www.erlang.org/faq/introduction.html#id49899

Functional programming and the lambda calculus are far from academic
topics, but have some real implications and solve engineering
problems.

Personally, I wouldn’t want to program a CRUD app using functional
programming, but if I had to deal with an industrial robot, I’d hope
that some sort of functional programming is possible. Nor would I want
to write a financial statement using functional programming tools or
pradigms (mathematically speaking, it’s only addition; the rule set is
what makes bookkeeping difficult).

–
Phillip G.

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.

25

On Sun, Apr 3, 2011 at 2:17 PM, Everett L Williams II
[email protected] wrote:

*Let’s not pay too much attention to the code snobs on here. I’ve yet to see
a recursive function that is more efficient than a more linearly coded
function that accomplishes the same thing, and there is always the problem
of curtailing recursion. People often mistake shortest code for the most
efficient or effective, and that is seldom true.

Which you are doing at the moment, it appears. It’s a straw man,
anyway: nobody was talking about performance.

In addition, there are a whole host more people who can write acceptable
programs in Excel than there
are who can do so in Ruby or probably the sum of all the languages that are
in that category.

Extraordinary claims require extraordinary evidence. So, show the
evidence, please. Also: define “acceptable”.

If you are after the 80-90% of intel x86 compatible machines
that run Windows, that is not an issue. I won’t even say that maintenance is
a bigger problem in Excel, though the issue can be argued in many different
ways.

How many of these machines run Excel, and in a compatible flavour to
whatever you want to sell based off of Excel?

If we are arguing market segments, we all should be writing software
in ActionScript, and distribute Flash files (95% or so market
penetration across all x86 machines installed world-wide, and a major
chunk of the Android market in smart phones).

Once you have made up your mind to use a tool like Ruby, you have to pick a
flavor, and you really need to know C/C++ as well as Ruby to really be able
to use Ruby. If you intend to have cross-platform support, you need to
understand the subtleties of the various platforms you intend to support,
which is a problem in almost any language. Perl and Python and especially
java should also be considered, especially if there is a history of coding
in one of those languages within your organization. All that aside, Ruby is
an excellent and well supported tool, well worth your time and effort, but
something that should be considered is that the simplest tool that is
effective should usually be used. Good luck.

Yeah, and I doubt that in 99% of all cases that aren’t spreadsheets or
statistics, Excel is the tool one should use.

Anecdote:
My EE prof used Excel to invert a matrix. Took about 30 minutes, and
was far from obvious (I forgot how it was done, since it was
definitely something Excel wasn’t designed to do), when a specialized
tool (Maple in this case), did the same job in one line of code,
following the mathematical notation (M_inverse := M^-1).

Thus, I wouldn’t use Excel to write a tool to analyse an electrical
network.

–
Phillip G.

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.

26

On Sun, Apr 3, 2011 at 1:18 PM, Phillip G.
[email protected] wrote:

On Sun, Apr 3, 2011 at 7:29 AM, Mike S. [email protected] wrote:

However, since you ask: Excel is by far the World’s most widely used
programming language.

As Carl Sagan once said: Extraordinary claims require extraordinary evidence.

Excel is an automation tool, certainly, but I wouldn’t call a finance
sheet, sales report, or statistical analysis of data in a diagram
“programming”.

No less a person than Simon Peyton Jones has called Excel “the world’s
most popular functional language”.

http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/

martin

27

Phillip G. wrote in post #990664:

Anecdote:
My EE prof used Excel to invert a matrix. Took about 30 minutes, and
was far from obvious (I forgot how it was done, since it was
definitely something Excel wasn’t designed to do), when a specialized
tool (Maple in this case), did the same job in one line of code,
following the mathematical notation (M_inverse := M^-1).

Would that remark still apply if Excel had - let’s say - a function
MINVERSE() - a similar single line of code?

Well, interestingly, I do believe it does.

Have a look at eg

I suspect people don’t realise what power Excel has, because hardly
anyone talks about it. They either talk about everyday corporate number
crunching or conventional programming lnaguages. Few people think about
taking Excel’s components and mixing them together to solve
simultanaeous linear equations.

28

On Sun, Apr 03, 2011 at 02:29:27PM +0900, Mike S. wrote:

to build an application to compare performance of schools. Something
like Rails is a huge jump for a newby. Leveraging Excel knowledge could
make this kind of thing so much more accessible.

Correction: it is (probably) the world’s most widely macro system.

I’m also not sure that Excel would be any more accessible to the
“newbie”
than Rails. The only reason many people find it “easier” is that they
have already invested the time to learn to use its most basic
capabilities, whereas they have not done so with Ruby and/or Rails.

But the other point is why does everybody make languages so difficult
these days? I have a degree in Physics but couldn’t face trying to
unravel F# or Haskell. Don’t tell me trying to fathom out complex
recursive functions is a good way to spend your day.

They aren’t all “so difficult”. They just reward a different approach
to
automation than Excel – an approach that does not overconsume resources
so much, that scales better, that allows for easier composition of
complex algorithms from simple algorithms, and that supports greater
productivity for the expert.

Of course, you have to encourage people to invent Lambda Calculus and
then turn it into a computing language but such university thesis ideas
shouldn’t be seen as the model for real world products.

Actually, the consequences of that kind of thinking results in
programming languages that allow us to leverage our capabilities much
more efficiently (and I’m not just talking about clock cycles, here), so
that we can build upon past advances to produce more substantial and
amazing advances in the future. Giving up on the cutting edge just
because you don’t understand it yet only limits you.

29

On Sun, Apr 3, 2011 at 6:50 AM, Phillip G. <
[email protected]> wrote:

Though, considering that LISP was one of, if not the, first language
to use the lambda calculus as basis for a programming language, it is
certainly a forefather of today’s crop of functional programming
languages, like Scheme, ML, Erlang, Haskell, or F#.

I’m not particularly familiar with its history, but I don’t think Common
Lisp was the original dialect of Lisp.

On Sun, Apr 3, 2011 at 7:17 AM, Everett L Williams II
[email protected]wrote:

*Let’s not pay too much attention to the code snobs on here. I’ve yet to
see a recursive function that is more efficient than a more linearly coded
function that accomplishes the same thing,

There are many types of efficiency, there is also efficiency of
comprehension, and implementation, and it is much easier to comprehend
and
implement recursion in many situations.

Here is an example of a Binary Search Tree with a recursive_print method
and
a “linearly coded function that that accomplishes the same thing” (I
assume
by “linear” you mean “imperative”). I can barely comprehend the linear
version, and I wrote it. If you can come up with a better version,
please
post it.

class BST

attr_accessor :left , :right , :data

def << new_data
if !data
self.data = new_data
elsif new_data <= data
( self.left ||= BST.new ) << new_data
else
( self.right ||= BST.new ) << new_data
end
self
end

this is for simplicity of the exercise, in reality it

would be an each method and the code using it

would make it print

def recursive_print
left && left.recursive_print
data && puts(data)
right && right.recursive_print
end

def iterative_print
todo = []
crnt = self
loop do
if crnt && crnt.left
todo.push crnt
crnt = crnt.left
elsif crnt && crnt.right
puts crnt.data
crnt = crnt.right
else
puts crnt.data if crnt && crnt.data
crnt = todo.pop
break unless crnt
puts crnt.data if crnt.data
crnt = crnt.right
end
end
end
end

root = BST.new << 7 << 3 << 1 << 0 << 2 << 5 << 4
<< 6 << 11 << 9 << 8 << 10 << 13 << 12 << 14

root.recursive_print
puts
root.iterative_print

I decided to benchmark it, just to see how much faster it really is. And
it
actually turns out to be slower. In this case, the recursive version is
not
only elegant, easier to read, write, and comprehend, but it is also
faster.

def no_output
stdout = Object.new
def stdout.write(*params) end
def stdout.puts(param) end
$stdout = stdout
yield
ensure
$stdout = STDOUT
end

require ‘benchmark’
Benchmark.bm 10 do |b|
b.report “recursive” do
no_output do
100_000.times { root.recursive_print }
end
end
b.report “linear” do
no_output do
100_000.times { root.iterative_print }
end
end
end

RESULTS

user system total real

recursive 0.840000 0.000000 0.840000 ( 0.843655)

linear 1.040000 0.010000 1.050000 ( 1.059313)

On Sun, Apr 3, 2011 at 8:13 AM, Martin DeMello
[email protected]wrote:

No less a person than Simon Peyton Jones has called Excel “the world’s
most popular functional language”.

http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/

martin

It might be easier if you guys could show how one writes a program in
excel.
OP was talking about a web app, complete with authentication,
authorization,
cookies, “etc”. I can’t even conceive of how one would go about doing
such a
thing. I wouldn’t even know how to execute an Excel program (do you make
an
executable? do you invoke it on the command line? is there an
interpreter?
compiler?). Here are some examples of programs I’ve written this
semester in
Ruby:

  • A Shoes app to help me in my Chem lab by watching the time and telling
    me
    to take a measurement every n seconds. (
    http://img209.imageshack.us/img209/2602/93593675.png)
  • A program to go through my music and rename all my mp3s to
    “#{mp3.tag[‘artist’]} - #{mp3.tag[‘title’]}”, it is invoked on the
    command
    line, you pass it the directory with the mp3s that it should rename.
  • A program to create Conway’s game of life videos (
    Conway's Game of Life in Ruby on Vimeo)

Is it even possible (let alone viable) to do any of this in Excel? And
if
so, then why do they bother bundling VBA with Excel? Seems redundant.

30

It might be easier if you guys could show how one writes a program in
excel. OP was talking about a web app, complete with authentication,
authorization, cookies, “etc”. I can’t even conceive of how one would
go about doing such a thing.

There are some fun looking Excel games

Don’t have excel to hand so I haven’t tried them
(Note that I wouldn’t have this problem if they were written in pretty
much any other language)

That’s pretty cool! I made something similar, it rendered wireworld
cellular automatons to animated gifs with smalltalk and gnu plotter.
Great fun that sort of thing :slight_smile:

Cheers
Johnny

31

On Sun, Apr 3, 2011 at 9:03 PM, Chad P. [email protected] wrote:

They aren’t all “so difficult”. They just reward a different approach to
automation than Excel – an approach that does not overconsume resources
so much, that scales better, that allows for easier composition of
complex algorithms from simple algorithms, and that supports greater
productivity for the expert.

And provides a certain beauty in clarity and logic, that only maths
can provide, IME.

Actually, the consequences of that kind of thinking results in
programming languages that allow us to leverage our capabilities much
more efficiently (and I’m not just talking about clock cycles, here), so
that we can build upon past advances to produce more substantial and
amazing advances in the future.

Like concurrency being a “free by” of functional languages, thanks to
immutable data, and lambda calculus allows for easy parallelization,
since the algorithm is already broken down into its simplest pieces.

Giving up on the cutting edge just
because you don’t understand it yet only limits you.

Considering that the idea of a “compiler” appeared around 1952 (with
the first complete compiler appearing in '57, called FORTRAN,
apparently), and LISP was formalized in 1958, it’s not really that
cutting edge, either. Nor is functional programming, if we consider
APL from 1957*…

It’s just that compilers moved into the mainstream relatively fast,
and only now that Moore’s Law is breaking down, and we are thus using
multiple cores even in the cheapest hardware (there’s dual-core phones
now, ferchrissakes), that the issues of concurrency and
parallelization come to the fore, and with them functional
programming.

  • I consider immutable data to be key to functional programming, and
    LISP doesn’t work that way, so I don’t see it as a functional
    language. YMMV, of course.

–
Phillip G.

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.

32

On Sun, Apr 3, 2011 at 8:44 PM, Mike S. [email protected]
wrote:

Phillip G. wrote in post #990664:

Would that remark still apply if Excel had - let’s say - a function
MINVERSE() - a similar single line of code?

Well, interestingly, I do believe it does.

Just for giggles, let’s compare Maple and Excel. Since you nicely
provided the Excel 2007/2010 example, I’ll provide a real-world
example* of matrix inversion in Maple**.

with(LinearAlgebra):
M := Matrix([ [1, 2, 3], [4, 5, 6], [7, 8, 9] ]);
M_inverted := M^(-1);
  • Modified a bit, since I doubt anyone cares about the exact details
    of what the matrix contains.
    ** I have Maple 14, but AFAIK, the package LinearAlgebra/linalg usage
    hasn’t changed between versions, though LinearAlgebra is the New and
    Improved flavour.

The worksheet version is nicer, since it provides proper formatting,
but is difficult to show off when sticking to plain text email.

I suspect people don’t realise what power Excel has, because hardly
anyone talks about it. They either talk about everyday corporate number
crunching or conventional programming lnaguages. Few people think about
taking Excel’s components and mixing them together to solve
simultanaeous linear equations.

Considering the hoops I have to jump through to pull the same thing in
Excel, I’ll stick with picking the right tool for the job.

Sure, I can get a sledgehammer and make the square peg fit the round
hole, but what, aside from a broken hole, do I gain?

For other operations, like polynominal division, Excel becomes pretty
useless, since it can’t add up numbers properly (resulting in
fantastically large results, when the excepted result is something
like “y = 4” for a singularity on the x-axis). Nor does it support
polar form representation of complex numbers (very, very, very nice to
have to do a network analysis with alternating current, especially if
you want to minimize rounding errors).

All that makes Excel a rather bad choice when it comes to engineering.

That doesn’t even touch on programming yet: Excel can’t deal with a
problem space outside of statistics and finance.

TL;DR: You don’t need to be a programmer to program, but the tool of
choice needs to be able to support what you want to do, and do so
efficiently (in time spent by the user, not CPU cycles).

BTW: “matrix” and “linear system of equations” are not synonymous.

–
Phillip G.

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.

33

@Josh
ruby == magic
therefore:
ruby-talk magically knows where your posts are supposed to be :stuck_out_tongue:
hex

34

On Sun, Apr 3, 2011 at 1:44 PM, Mike S. [email protected]
wrote:

MINVERSE() - a similar single line of code?
simultanaeous linear equations.

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

Hmm, when you post, it fragments into a new thread in my gmail. I assume
because you change the subject. I’m trying to figure out how to fix it (
http://www.google.com/support/forum/p/gmail/thread?tid=63a2a74c9f70e02d)
but
doesn’t look like it will happen any time soon. Meanwhile, I’d be
appreciative if you could just make the new subject be “Re:
#{original_subject}”

(musing: I wonder how ruby-forum knows they are part of the same
thread.)

35

On 04/03/2011 10:34 PM, serialhex wrote:

(musing: I wonder how ruby-forum knows they are part of the same thread.)
mail headers

Message-Id: [email protected]
In-Reply-To: [email protected]
References: [email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
BANLkTikT8Vqz6rJGOZz91_58-8g=removed_email_address@domain.invalid
[email protected]
[email protected]
[email protected]
[email protected]

36

BTW: “matrix” and “linear system of equations” are not synonymous.

Perhaps he was thinking of the matrix of coefficients used when solving
such systems.

I’m rather astounded this debate could last so long, it seems so silly.
Anyway, here are some points of non-issue I feel have emerged.

  • Excel isn’t a proper programming language

  • But if you do consider it a language, then it would be a functional
    language.

  • Functional programming, despite its faults, isn’t particularly weird
    or difficult at all. Which isn’t so strange Mike, when you consider
    the last point.

  • Please Mike, go write us something cool in Excel and send it back to
    the list, to show us how awesome it is when compared to other
    languages. Josh has some suggestions!

Cheers
Johnny

37

On Sun, Apr 3, 2011 at 3:06 PM, Johnny M.
[email protected]wrote:

(Note that I wouldn’t have this problem if they were written in pretty
much any other language)

Yeah, I don’t have Excel, either :confused:

The page says “All of the VBA code is unprotected, so you are free to
see
how it works.” So that implies to me that this is not what we are
talking
about, though, because it was Chad P.'s initial assumption that
programming in Excel meant VBA, but Mike responded with “Unfortunately
most
people think the words ‘Excel’ and ‘programming’ must equal VBA. […]
the
accomplished S# programmer only uses [VBA] as a last resort.” (“S#”
seems to
be a name Mike made up for programming in Excel).

I did try loading it up in Open Office, but it uses VBA macros, which I
couldn’t get to work. I was surprised to see that it looked decent (
https://s3.amazonaws.com/josh.cheek/scratch/excel-game.png) so
apparently
Excel has more powerful formatting capabilities than I realized. But,
web
browsers have powerful formatting, and that doesn’t make them
programming
languages.

That’s pretty cool! I made something similar, it rendered wireworld
cellular automatons to animated gifs with smalltalk and gnu plotter.
Great fun that sort of thing :slight_smile:

Thanks :slight_smile:

On Sun, Apr 3, 2011 at 3:07 PM, Phillip G. <
[email protected]> wrote:

  • I consider immutable data to be key to functional programming, and
    LISP doesn’t work that way, so I don’t see it as a functional
    language. YMMV, of course.

Common Lisp doesn’t, but other Lisp dialects do (Scheme, Clojure).

I’ve noticed several different uses of “functional” though, some mean
purely
functional (no side effects) like you are saying, ie Haskell and
Clojure.
And others just mean that you basically have support for closures and
first
order functions (Common Lisp, Ruby, JavaScript).

So it is sometimes difficult to talk about :confused: I typically tell people
that
Ruby “supports a functional paradigm”, but that maybe doesn’t identify
important nuances, and as Robert pointed out, most languages are headed
in
that direction.

38

On Apr 3, 2011, at 10:34 PM, serialhex wrote:

ruby-talk magically knows where your posts are supposed to be :stuck_out_tongue:

Not quite magic, just the ‘In-Reply-To’ and ‘References’ email header.

More on the subject of message threading, courtesy of Jamie Zawinski:

http://www.jwz.org/doc/threading.html

39

On Sun, Apr 03, 2011 at 10:13:29PM +0900, Martin DeMello wrote:

Excel is an automation tool, certainly, but I wouldn’t call a finance
sheet, sales report, or statistical analysis of data in a diagram
“programming”.

No less a person than Simon Peyton Jones has called Excel “the world’s
most popular functional language”.

Oscar Wilde said “Everything popular is wrong.” Abraham Lincoln said
“Avoid popularity if you would have peace.”

Immanuel Kant said “Seek not the favor of the multitude; it is seldom
got
by honest and lawful means. But seek the testimony of few, and number
not voices, but weigh them.”

(Apologies if I misremember some detail in those.)

I don’t really give a crap what’s popular, nor who has said it was
popular, when choosing something for merit. I’m also not entirely
convinced he thinks popularity is any kind of sign of quality (given his
involvement in GHC development, which is nothing at all like Excel), nor
that his statement of popularity of Excel as a functional “language” is
unbiased, given his employment at Microsoft employee for a dozen years
or
so. Where are his independently verifiable statistics? What are his
methodologies for collection and comparison of that data? The truth of
the matter is that he was just one of a few people who contributed to a
paper that has a sensational title – a title that, by the way, strongly
suggests Excel is not a very good programming tool (to say nothing of
the contents of the paper).

From the beginning, where it is stated that their efforts to improve the
suitability of spreadsheets to support “programming-like” tasks, it is
quite evident to anyone not prejudicially invested in seeing Excel as a
“programming language” that the authors are not strong in any conviction
that a spreadsheet constitutes a “programming language”. In the
conclusion, they very nearly say outright that spreadsheets have their
uses, but that as a general programming paradigm spreadsheets damned
well
suck:

We have presented a design process in which we started from a
popular, but limited, end-user programming paradigm (the
spreadsheet), and extended it to provide some of the capabilities of
general purpose programming languages (user defined functions and
matrices). We have not approached our work as a generic language
design exercise.

In short, they’re not trying to design a functional programming
language.
Rather, they’re trying to improve the capabilities of Excel for
providing
the support needed to give people a pseudo-functional paradigm for
accomplishing “programming-like” tasks when those people are so heavily
invested in using Excel to accomplish such tasks that they are unwilling
to learn the right tool for the job.

Excel is a spreadsheet – which happens to have a programming language
embedded in it (and not a very good one, at that). It may technically
be
Turing-complete, but so are the GIMP, Firefox, and Conway’s Game of Life
(two of them for much the same reason as Excel). The Turing
completeness
status of only one of these is, to me, even remotely impressive.

If you can find a way to usefully embed a Turing complete general
purpose programming language into a graphical user application without
the application being definable by people with an axe to grind as
“Turing
complete”, I’ll give you a cookie. If you choose to reject that as
meaningful criteria for defining something as a programming language,
thus rejecting the GIMP and Firefox as programming “languages”, you also
reject MS Excel.

The fact of the matter is that Excel is not a language at all.

40

On Mon, Apr 04, 2011 at 05:56:19AM +0900, Josh C. wrote:

The page says “All of the VBA code is unprotected, so you are free to
see how it works.” So that implies to me that this is not what we are
talking about, though, because it was Chad P.'s initial assumption
that programming in Excel meant VBA, but Mike responded with
“Unfortunately most people think the words ‘Excel’ and ‘programming’
must equal VBA. […] the accomplished S# programmer only uses [VBA] as
a last resort.” (“S#” seems to be a name Mike made up for programming
in Excel).

I didn’t quite make the statement that “programming” in Excel
necessarily
means VBA – but trying to do anything nontrivial in Excel without using
either VBA or some other language that can manipulate Excel from the
outside is an exercise in either a mildly perverse spirit of tinkering
fun or purely masochistic insanity. I suspect Mike’s statement that
“the
accomplished [Excel] [user] only uses [VBA] as a last resort” was
related
more to the fact that one should use the simplest functionality of Excel
unless one really needs more than that people should be writing Web
frameworks in Excel without ever using a macro language. I don’t think
even Mike is that crazed in support of Excel as a programming
“language”.

I did try loading it up in Open Office, but it uses VBA macros, which I
couldn’t get to work. I was surprised to see that it looked decent (
https://s3.amazonaws.com/josh.cheek/scratch/excel-game.png) so
apparently Excel has more powerful formatting capabilities than I
realized. But, web browsers have powerful formatting, and that doesn’t
make them programming languages.

As I commented elsewhere, Firefox is every bit a Turing complete
programming language as MS Excel – which is to say, it isn’t, in my
opinion. It just comes with a Turing complete programming language (or
two) embedded in it, and offers a lot of other capabilities as well.