Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.ruby > #1942 > unrolled thread

[OT] functional paradigm taking over

Back to article view | Back to comp.lang.ruby

Contents

  [OT] functional paradigm taking over Robert Klemme <shortcutter@googlemail.com> - 2011-03-30 02:29 -0500
    Lambda Shambda Mike Stephens <rubfor@recitel.net> - 2011-03-30 04:38 -0500
      Re: Lambda Shambda Robert Klemme <shortcutter@googlemail.com> - 2011-03-30 10:19 -0500
        Re: Lambda Shambda Mike Stephens <rubfor@recitel.net> - 2011-03-30 12:27 -0500
        Re: Lambda Shambda 7stud -- <bbxx789_05ss@yahoo.com> - 2011-03-30 20:49 -0500
        Re: Lambda Shambda Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-03-30 22:30 -0500
          Re: Lambda Shambda Mike Stephens <rubfor@recitel.net> - 2011-03-31 05:08 -0500
            Re: Lambda Shambda Josh Cheek <josh.cheek@gmail.com> - 2011-04-02 15:07 -0500
              Re: Lambda Shambda Mike Stephens <rubfor@recitel.net> - 2011-04-03 00:29 -0500
                Re: Lambda Shambda Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-03 02:48 -0500
                  Re: Lambda Shambda Robert Klemme <shortcutter@googlemail.com> - 2011-04-03 12:58 +0200
                    Re: Lambda Shambda Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-03 06:50 -0500
                      Re: Lambda Shambda Josh Cheek <josh.cheek@gmail.com> - 2011-04-03 13:59 -0500
                        Re: Lambda Shambda Johnny Morrice <spoon@killersmurf.com> - 2011-04-03 15:06 -0500
                          Re: Lambda Shambda Josh Cheek <josh.cheek@gmail.com> - 2011-04-03 15:56 -0500
                  Re: Lambda Shambda Everett L Williams II <rett@classicnet.net> - 2011-04-03 07:17 -0500
                    Re: Lambda Shambda Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-03 07:47 -0500
                      Why should I be a programmer, to program? Mike Stephens <rubfor@recitel.net> - 2011-04-03 13:44 -0500
                        Re: Why should I be a programmer, to program? Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-03 14:45 -0500
                          Re: Why should I be a programmer, to program? Johnny Morrice <spoon@killersmurf.com> - 2011-04-03 15:58 -0500
                        Re: Why should I be a programmer, to program? Josh Cheek <josh.cheek@gmail.com> - 2011-04-03 15:21 -0500
                          Re: Why should I be a programmer, to program? serialhex <serialhex@gmail.com> - 2011-04-03 15:34 -0500
                            Re: Why should I be a programmer, to program? - OT Chris <chris@s-4-u.net> - 2011-04-03 15:53 -0500
                            Re: Why should I be a programmer, to program? Petite Abeille <petite.abeille@gmail.com> - 2011-04-03 16:01 -0500
                              Re: Why should I be a programmer, to program? - OT Chris <chris@s-4-u.net> - 2011-04-03 16:42 -0500
                      Re: Lambda Shambda Everett L Williams II <rett@classicnet.net> - 2011-04-04 04:23 -0500
                        Re: Lambda Shambda Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-04 04:52 -0500
                          Re: Lambda Shambda Robert Klemme <shortcutter@googlemail.com> - 2011-04-04 06:19 -0500
                  Re: Lambda Shambda Martin DeMello <martindemello@gmail.com> - 2011-04-03 08:13 -0500
                    Re: Lambda Shambda Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-04 00:55 -0500
                      Re: Lambda Shambda Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-04 10:16 -0500
                  Re: Lambda Shambda Iain Barnett <iainspeed@gmail.com> - 2011-04-04 15:50 -0500
                Re: Lambda Shambda Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-03 15:07 -0500
            Re: Lambda Shambda Johnny Morrice <spoon@killersmurf.com> - 2011-04-03 06:05 -0500
          Re: Lambda Shambda Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-03-31 13:56 -0500
    Re: [OT] functional paradigm taking over Martin DeMello <martindemello@gmail.com> - 2011-03-30 15:46 -0500
    Re: functional paradigm taking over Mike Stephens <rubfor@recitel.net> - 2011-04-04 04:05 -0500
      Re: functional paradigm taking over Johnny Morrice <spoon@killersmurf.com> - 2011-04-04 04:21 -0500
      Re: functional paradigm taking over Johnny Morrice <spoon@killersmurf.com> - 2011-04-04 04:25 -0500
      Re: functional paradigm taking over Stu <stu@rubyprogrammer.net> - 2011-04-04 04:28 -0500
        Re: functional paradigm taking over Robert Dober <robert.dober@gmail.com> - 2011-04-04 06:49 -0500
      Re: functional paradigm taking over Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-04 05:00 -0500
        Re: functional paradigm taking over Johnny Morrice <spoon@killersmurf.com> - 2011-04-04 05:15 -0500
          Re: functional paradigm taking over Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-04 05:18 -0500
      Re: functional paradigm taking over Everett L Williams II <rett@classicnet.net> - 2011-04-04 06:31 -0500
        Re: functional paradigm taking over Johnny Morrice <spoon@killersmurf.com> - 2011-04-04 07:17 -0500
          Re: functional paradigm taking over Johnny Morrice <spoon@killersmurf.com> - 2011-04-04 07:29 -0500
            Re: functional paradigm taking over Johnny Morrice <spoon@killersmurf.com> - 2011-04-04 10:42 -0500
              Re: functional paradigm taking over Michal Suchanek <hramrach@centrum.cz> - 2011-04-04 12:43 -0500
              Re: functional paradigm taking over Robert Dober <robert.dober@gmail.com> - 2011-04-10 11:59 -0500
                Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-12 01:18 -0500
                  Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-12 01:22 -0500
                    Re: functional paradigm taking over Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-12 02:09 -0500
                  Re: functional paradigm taking over Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-12 02:11 -0500
                    Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-12 02:47 -0500
                      Re: functional paradigm taking over Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-12 03:40 -0500
                      Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-13 00:53 -0500
                        Re: functional paradigm taking over Josh Cheek <josh.cheek@gmail.com> - 2011-04-13 01:02 -0500
                          Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-13 01:38 -0500
                            Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-13 01:46 -0500
                            Re: functional paradigm taking over Josh Cheek <josh.cheek@gmail.com> - 2011-04-13 02:46 -0500
                            Re: functional paradigm taking over Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-13 03:52 -0500
                              Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-13 09:59 -0500
                                Re: functional paradigm taking over Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-13 10:16 -0500
                                  Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-13 11:18 -0500
                                    Re: functional paradigm taking over serialhex <serialhex@gmail.com> - 2011-04-13 14:41 -0500
                                      Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-13 15:34 -0500
                                Re: functional paradigm taking over Peter Hickman <peterhickman386@googlemail.com> - 2011-04-13 10:17 -0500
                            Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-13 18:44 -0500
                              Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-14 00:32 -0500
                              Re: functional paradigm taking over Michal Suchanek <hramrach@centrum.cz> - 2011-04-14 05:06 -0500
                                Re: functional paradigm taking over Mike Stephens <rubfor@recitel.net> - 2011-04-15 01:25 -0500
        Re: functional paradigm taking over Josh Cheek <josh.cheek@gmail.com> - 2011-04-04 07:41 -0500
          Re: functional paradigm taking over Michal Suchanek <hramrach@centrum.cz> - 2011-04-04 07:56 -0500
          Re: functional paradigm taking over Stu <stu@rubyprogrammer.net> - 2011-04-05 03:58 -0500
            Re: functional paradigm taking over Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-05 04:12 -0500
              Re: functional paradigm taking over Stu <stu@rubyprogrammer.net> - 2011-04-05 16:57 -0500
        Re: functional paradigm taking over Everett L Williams II <rett@classicnet.net> - 2011-04-07 10:51 -0500
          Re: functional paradigm taking over Josh Cheek <josh.cheek@gmail.com> - 2011-04-07 18:42 -0500
            Re: functional paradigm taking over Alex Stahl <astahl@hi5.com> - 2011-04-07 20:26 -0500
          Re: functional paradigm taking over Mike Stephens <rubfor@recitel.net> - 2011-04-07 22:14 -0500
            Re: functional paradigm taking over Johnny Morrice <spoon@killersmurf.com> - 2011-04-08 06:10 -0500
            Re: functional paradigm taking over Everett L Williams II <rett@classicnet.net> - 2011-04-08 13:58 -0500
    Re: functional paradigm taking over Mike Stephens <rubfor@recitel.net> - 2011-04-08 16:04 -0500
      Re: functional paradigm taking over Josh Cheek <josh.cheek@gmail.com> - 2011-04-08 19:12 -0500
    Re: functional paradigm taking over Mike Stephens <rubfor@recitel.net> - 2011-04-12 07:31 -0500
      Re: functional paradigm taking over Phillip Gawlowski <cmdjackryan@googlemail.com> - 2011-04-12 11:22 -0500
    Re: functional paradigm taking over Gregory Vella <gregory_vella@yahoo.com> - 2011-04-13 14:49 -0500
      Re: functional paradigm taking over Kevin <darkintent@gmail.com> - 2011-04-13 15:59 -0500
    Re: functional paradigm taking over Mike Stephens <rubfor@recitel.net> - 2011-04-14 02:28 -0500
      Re: functional paradigm taking over Robert Klemme <shortcutter@googlemail.com> - 2011-04-14 03:29 -0500
        Re: functional paradigm taking over Josh Cheek <josh.cheek@gmail.com> - 2011-04-14 05:01 -0500

Page 1 of 5  [1] 2 3 4 5  Next page →

#1942 — [OT] functional paradigm taking over

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

Cheers

robert

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

[toc] | [next] | [standalone]

#1951 — Lambda Shambda

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

[toc] | [prev] | [next] | [standalone]

#1974 — Re: Lambda Shambda

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

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:
>
>    http://www.fisher-price.com/us/powerwheels/

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. :-)
-> "[OT] functional paradigm taking over"

Kind regards

robert

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

[toc] | [prev] | [next] | [standalone]

#1979 — Re: Lambda Shambda

>> Are you saying that you're creating some kind of stand-alone variant of
>> VBA?

Unfortunately most people think the words 'Excel' and 'programming' must
equal VBA. I spent a lot on a book called Professional Excel Development
which hardly mentions Excel itself. I think however in ome circumstances
VBA functions may have to be used eg to call realistic SOAP services.
The key is to keep them as functions ie no calling and waiting. They
should look exactly like in-built functions. Also the accomplished S#
programmer only uses them as a last resort.

>> it's three metric tons of VM-like overhead

but seems to load faster than Ruby

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

Succinctly put


>> Maybe you'd like working with a database management system that offers
>> some kind of stored procedures or triggered functions capabilities more.

Your remark is highly relevant. Tedd Codd deliberately designed the
relational model to eliminate the requirement to describe process. SQL
is a very powerful functional programming system. Stored procedures
however are usually...procedural.

>> Excel is to DBMSes as those old Power Wheels toys are to actual cars,
>> after all.

I suspect you can do a lot of real world 'database' processing in
Excel -just like some folks use ActiveRecord (no - don't start me off on
ORMs...). On that basis, I guess a simple web site could use a lot of
functional programming functions without resorting to DBMS facilties.

As I said earlier, one of the attractions is you have to think
differently.

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

[toc] | [prev] | [next] | [standalone]

#2008 — Re: Lambda Shambda

Chad Perrin wrote in post #990079:
> On Thu, Mar 31, 2011 at 12:19:25AM +0900, Robert Klemme wrote:
>> 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.
>
> Option 2, then.
>
>
>> > 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/
>
> I have heard good things about both Scala and Clojure, though they both
> suffer the limitation of requiring the JVM.  I plan to give them both a
> look this year, as well as Haskell, but have not gotten around to it
> yet.
>

I don't know if you've seen the Pragmatic Programmer's book "Seven 
Languages in Seven weeks".  It gives brief overviews of Ruby, Io, 
Prolog, Clojure, Scala, Erlang, and Haskell.

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

[toc] | [prev] | [next] | [standalone]

#2021 — Re: Lambda Shambda

On Thu, Mar 31, 2011 at 1:24 AM, Chad Perrin <code@apotheon.net> wrote:
>
> Oh, I'm sure it does -- but Excel is not a programming language, so I'm
> not sure it's meaningful to say that Excel's features as a functional
> programming language provide any parallelism benefits.

Not a Turing-complete language, anyway.

It's basically a(n econ) math and statistics library lacking a decent
programming language.

> That pretty much amounts to utilizing a minimal subset of the
> capabilities of a proper DBMS plus some code that maps to the contents of
> a DB table -- or, in DBMSes, plus some stored procedures (or stored
> functions, or whatever).  Is there something I'm missing?

Authentication and authorization, and table/row/cell locking.

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

[toc] | [prev] | [next] | [standalone]

#2036 — Re: Lambda Shambda

Chad Perrin wrote in post #990130:

> I don't think it really qualifies as a language at all.  It's more like
> an extensible set of cupboards with (non-graphing) calculators from the
> early '90s built into them.

You may be interested in this
http://www.programmingforums.org/thread15823.html which shows Excel
solving Dijkstra's Algorithm.

Excel is probably Turing complete (opinions differ) if you exclude the
notion of infinite sets.

If you consider a web site that collects user details, generates an
insurance quote and takes payment, then my initial assessment (I've not
built it yet) is Excel has the required features, including
authentication, logging, cookies etc. 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.

The issue (sometimes called the Turing Tarpit) is that Excel is a
programming alnguage but without many of the sophistications you see in
the likes of Ruby, and therefore may be unnecessarily awkward to program
in.

Nevertheless I think it is instructive. If you can imagine solving
practical problems in Excel then you should be able to solve the same
problems in the more accepted functional languages without being tempted
to slip back into imperative habits.

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? Why can't I just define what I want to see, and
then look at whether it turns out as I expected?"

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

[toc] | [prev] | [next] | [standalone]

#2165 — Re: Lambda Shambda

[Note:  parts of this message were removed to make it a legal post.]

On Thu, Mar 31, 2011 at 5:08 AM, Mike Stephens <rubfor@recitel.net> wrote:

> Chad Perrin wrote in post #990130:
>
> > I don't think it really qualifies as a language at all.  It's more like
> > an extensible set of cupboards with (non-graphing) calculators from the
> > early '90s built into them.
>
> You may be interested in this
> http://www.programmingforums.org/thread15823.html which shows Excel
> solving Dijkstra's Algorithm.
>
> Excel is probably Turing complete (opinions differ) if you exclude the
> notion of infinite sets.
>
> If you consider a web site that collects user details, generates an
> insurance quote and takes payment, then my initial assessment (I've not
> built it yet) is Excel has the required features, including
> authentication, logging, cookies etc. 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.
>
> The issue (sometimes called the Turing Tarpit) is that Excel is a
> programming alnguage but without many of the sophistications you see in
> the likes of Ruby, and therefore may be unnecessarily awkward to program
> in.
>
> Nevertheless I think it is instructive. If you can imagine solving
> practical problems in Excel then you should be able to solve the same
> problems in the more accepted functional languages without being tempted
> to slip back into imperative habits.
>
> 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? Why can't I just define what I want to see, and
> then look at whether it turns out as I expected?"
>
> --
> Posted via http://www.ruby-forum.com/.
>
>
Coding everything in Excel might be an interesting paradigm to play with. It
might even reveal new ways of looking at problems that you hadn't previously
considered. But does it really warrant a title like "lambda shambda" and the
suggestion that it is easier than real languages like Haskell? It might be
possible (I'm skeptical) to write a web app in Excel, but is this really
something you'd want to do for anything other than an exercise?

I'm having a hard time telling whether you're just a little too excited
about this idea, trolling, or legitimately serious.

[toc] | [prev] | [next] | [standalone]

#2178 — Re: Lambda Shambda

Josh Cheek wrote in post #990579:
> is this really something you'd want to do for anything other than an
> exercise?

Excel is somewhat incidental to this discussion. It is not like
functional languages people normally think of. What I was saying is it
is interesting to think of new algorithms/patterns.

However, since you ask: Excel is by far the World's most widely used
programming language. We recently had someone on this channel asking how
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.

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.

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.

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

[toc] | [prev] | [next] | [standalone]

#2184 — Re: Lambda Shambda

On Sun, Apr 3, 2011 at 7:29 AM, Mike Stephens <rubfor@recitel.net> 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".

> We recently had someone on this channel asking how
> 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.

But is the resulting product of similar quality as one done in an
actual programming language?

Across the metrics of code maintenance, compatibility (just hope that
MS doesn't ever change the behavior of a function your spreadsheet
happens to rely on, and that your spreadsheet works on all Excel
variants your clients might be running, since shelling out for a new
Excel version ain't cheap, nor is a corporate roll out easy to do),
and speed of development?

What about non-trivial applications, like a stock trading agent?

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

Argument from authority. That you have a physics degree doesn't make
you a programmer. Nor does it make you particularly smart nor stupid,
or gives you the mindset a programmer should have. It makes you a
physicist, nothing more. That's kind of like saying that a bookkeeper
is a programmer because (s)he uses spreadsheets.

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

> 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):

http://en.wikipedia.org/wiki/Lisp_machine

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

[toc] | [prev] | [next] | [standalone]

#2189 — Re: Lambda Shambda

On 03.04.2011 09:48, Phillip Gawlowski wrote:
> On Sun, Apr 3, 2011 at 7:29 AM, Mike Stephens<rubfor@recitel.net>  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.

>> 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.
>
> Argument from authority. That you have a physics degree doesn't make
> you a programmer. Nor does it make you particularly smart nor stupid,
> or gives you the mindset a programmer should have. It makes you a
> physicist, nothing more. That's kind of like saying that a bookkeeper
> is a programmer because (s)he uses spreadsheets.
>
> 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):
>
> http://en.wikipedia.org/wiki/Lisp_machine

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


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

[toc] | [prev] | [next] | [standalone]

#2191 — Re: Lambda Shambda

On Sun, Apr 3, 2011 at 1:00 PM, Robert Klemme
<shortcutter@googlemail.com> 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* ;)

> 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
entrée 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)

[toc] | [prev] | [next] | [standalone]

#2204 — Re: Lambda Shambda

[Note:  parts of this message were removed to make it a legal post.]

On Sun, Apr 3, 2011 at 6:50 AM, Phillip Gawlowski <
cmdjackryan@googlemail.com> 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
<rett@classicnet.net>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 <martindemello@gmail.com>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 (
http://vimeo.com/21594165)

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.

[toc] | [prev] | [next] | [standalone]

#2208 — Re: Lambda Shambda

> 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
http://www.cpearson.com/excel/games.htm

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)

> * A program to create Conway's game of life videos (
> http://vimeo.com/21594165)

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 :)

Cheers
Johnny

[toc] | [prev] | [next] | [standalone]

#2219 — Re: Lambda Shambda

[Note:  parts of this message were removed to make it a legal post.]

On Sun, Apr 3, 2011 at 3:06 PM, Johnny Morrice <spoon@killersmurf.com>wrote:

>
> > 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
> http://www.cpearson.com/excel/games.htm
>
> 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)
>
>
Yeah, I don't have Excel, either :/

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



> > * A program to create Conway's game of life videos (
> > http://vimeo.com/21594165)
>
> 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 :)
>
>
Thanks ^_^

On Sun, Apr 3, 2011 at 3:07 PM, Phillip Gawlowski <
cmdjackryan@googlemail.com> 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 :/ 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.

[toc] | [prev] | [next] | [standalone]

#2192 — Re: Lambda Shambda

[Note:  parts of this message were removed to make it a legal post.]

*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

*

Phillip Gawlowski wrote:
> On Sun, Apr 3, 2011 at 7:29 AM, Mike Stephens<rubfor@recitel.net>  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".
>
>    

[toc] | [prev] | [next] | [standalone]

#2193 — Re: Lambda Shambda

On Sun, Apr 3, 2011 at 2:17 PM, Everett L Williams II
<rett@classicnet.net> 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 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.

[toc] | [prev] | [next] | [standalone]

#2201 — Why should I be a programmer, to program?

Phillip Gawlowski 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
http://www.chem.mtu.edu/~tbco/cm3450/Excel_Array_Formulas.pdf

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.

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

[toc] | [prev] | [next] | [standalone]

#2206 — Re: Why should I be a programmer, to program?

On Sun, Apr 3, 2011 at 8:44 PM, Mike Stephens <rubfor@recitel.net> wrote:
> Phillip Gawlowski 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**.

<code>

with(LinearAlgebra):
M := Matrix([ [1, 2, 3], [4, 5, 6], [7, 8, 9] ]);
M_inverted := M^(-1);

</code>

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

[toc] | [prev] | [next] | [standalone]

#2220 — Re: Why should I be a programmer, to program?

> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.ruby

csiph-web