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


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

[OT] functional paradigm taking over

Started byRobert Klemme <shortcutter@googlemail.com>
First post2011-03-30 02:29 -0500
Last post2011-04-14 05:01 -0500
Articles 20 on this page of 92 — 19 participants

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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →


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

FromJosh Cheek <josh.cheek@gmail.com>
Date2011-04-03 15:21 -0500
SubjectRe: Why should I be a programmer, to program?
Message-ID<BANLkTincwvtAjiJCmKfwiG234ier63W7fw@mail.gmail.com>
In reply to#2201
[Note:  parts of this message were removed to make it a legal post.]

On Sun, Apr 3, 2011 at 1:44 PM, Mike Stephens <rubfor@recitel.net> wrote:

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

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

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


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

Fromserialhex <serialhex@gmail.com>
Date2011-04-03 15:34 -0500
SubjectRe: Why should I be a programmer, to program?
Message-ID<BANLkTimyG9fY4whPe3EaSnztqS-Q+o6m_w@mail.gmail.com>
In reply to#2210
[Note:  parts of this message were removed to make it a legal post.]

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



On Sun, Apr 3, 2011 at 4:21 PM, Josh Cheek <josh.cheek@gmail.com> wrote:

> On Sun, Apr 3, 2011 at 1:44 PM, Mike Stephens <rubfor@recitel.net> wrote:
>
> > 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/.
> >
> >
>
> 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.)
>

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


#2218 — Re: Why should I be a programmer, to program? - OT

FromChris <chris@s-4-u.net>
Date2011-04-03 15:53 -0500
SubjectRe: Why should I be a programmer, to program? - OT
Message-ID<4D98DE46.9030801@s-4-u.net>
In reply to#2215
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: <BANLkTimyG9fY4whPe3EaSnztqS-Q+o6m_w@mail.gmail.com>
In-Reply-To: <BANLkTincwvtAjiJCmKfwiG234ier63W7fw@mail.gmail.com>
References: <BANLkTimKuriDuVMQRFSTs_=7W_iyKMr4kQ@mail.gmail.com>
	<3ab1912e670b08219714322dad0a1ebe@ruby-forum.com>
	<20110330143723.GA75718@guilt.hydra>
	<BANLkTin=+Bo2dnUKeyXGHX2ZEWGaOt36Ag@mail.gmail.com>
	<20110330192538.GA76517@guilt.hydra>
	<AANLkTinFH7qX=vyRr8qMQMbbXgHOO5UCtFkhssMezWfK@mail.gmail.com>
	<20110331053229.GB78145@guilt.hydra>
	<7631a84ea921373c09e25b83d0742e6e@ruby-forum.com>
	<AANLkTinN-VCZ-L=kvPq0Rme489QDx3-u_R2B_Mj1F1Fq@mail.gmail.com>
	<f15449f5b9c44881ca8aa9a431299278@ruby-forum.com>
	<BANLkTikT8Vqz6rJGOZz91_58-8g=FQXVyQ@mail.gmail.com>
	<4D986551.70802@classicnet.net>
	<BANLkTik5iY7z3JaN4VzkL8OzpQnGJey2bQ@mail.gmail.com>
	<121ff4897c1b5f723f96d80c224270f1@ruby-forum.com>
	<BANLkTincwvtAjiJCmKfwiG234ier63W7fw@mail.gmail.com>

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



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


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

FromPetite Abeille <petite.abeille@gmail.com>
Date2011-04-03 16:01 -0500
SubjectRe: Why should I be a programmer, to program?
Message-ID<59CD1C2D-2B1C-4C9C-9B81-4F474494BB70@gmail.com>
In reply to#2215
On Apr 3, 2011, at 10:34 PM, serialhex wrote:

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

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

http://tools.ietf.org/html/rfc2822#section-3.6.4

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

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



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


#2227 — Re: Why should I be a programmer, to program? - OT

FromChris <chris@s-4-u.net>
Date2011-04-03 16:42 -0500
SubjectRe: Why should I be a programmer, to program? - OT
Message-ID<4D98E9DB.1000704@s-4-u.net>
In reply to#2221
On 04/03/2011 11:01 PM, Petite Abeille wrote:
>
> More on the subject of message threading, courtesy of Jamie Zawinski:
>
> http://www.jwz.org/doc/threading.html
>

+1 for this one, well written (but sad) and the uber-cool menu ;)
http://www.jwz.org


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


#2247 — Re: Lambda Shambda

FromEverett L Williams II <rett@classicnet.net>
Date2011-04-04 04:23 -0500
SubjectRe: Lambda Shambda
Message-ID<4D998E09.8060507@classicnet.net>
In reply to#2193
[Note:  parts of this message were removed to make it a legal post.]

Phillip Gawlowski wrote:
> 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.
>    
*And, of course, since we were talking about making a practical decision 
about which tool to use, performance cannot possibly matter. There is 
also this overriding compulsion amongst coders to produce the most 
abbreviated code possible, assuming that such demonstrates their special 
skills and that such code is the most desirable. Any study of 
algorithmic efficiency will show clearly that the shortest code is 
almost never the fastest code, especially in unoptimized code.*
>    
>> 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 this were an extraordinary claim, your comment would hold true, but 
only exceptional arrogance would cause any other claim to be made. 
"Acceptable" means satisfactory to the person doing the programming, who 
is usually some grunt just trying to get his job done, rather than 
someone who is a proponent of any particular thing. I'll try not talk 
about "fanboys" here.*
>> 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?
>    
*When I am responsible for something, unless some feature in the current 
version is absolutely necessary, I tend to drop back one or two versions 
to cover most of my market, not to mention to avoid the hazards of being 
on the bleeding edge.*
> 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).
>    
*You said it. I didn't. Remember what I said about using the simplest 
tool that will get the job done.*
>    
>> 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.
>    
*Having made the progression from Assembler to COBOL and FORTRAN and on 
to dozens of other languages, I would have agreed with you until I 
started seeing people write all sorts of stuff in Excel. Again, I would 
never have recommended those uses, but they seemed to do the job.*
> 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.
>
>    
*No, if I were going to do a lot of work with matrices, I would use 
Mathlab or one of the various libraries that specialize in that kind of 
work. Actually, "I" would probably use APL or one of the variants, 
because it is flatly designed for work with matrices and can do in one 
line what would take a whole page of equations. Of course, I wouldn't 
really recommend APL, because it is one of those languages that is 
almost impossible to maintain if you did not write it yourself. APL is 
famous for having working code that no one can figure out. On the other 
hand, matrices are not the only method for working such problems. From 
what I know of it, I wouldn't use Excel for huge classes of problems, 
but some people seem to be able to twist it to do things that I would 
never have guessed. "To the man with a hammer, everything looks like a 
nail."...even when a screw or glue might do a better job. The point is 
that he knows how to use the hammer and can get prodigious amounts of 
work done with it, so he has to think very carefully when someone tells 
him he has to learn this new and completely different tool while the 
work gets behind.

About 50% of the real newbies to programming who come on this site with 
a complex project that requires unstable parts of the Ruby pantheon, 
should be told to use another tool, one that is simpler, more mature, 
and that does a better job of handholding, but people who spend most of 
their time on Ruby tend to think with their hammer, so to speak, or 
maybe, they don't really know anything else.

Everett L.(Rett) Williams II

Everett L
*

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


#2250 — Re: Lambda Shambda

FromPhillip Gawlowski <cmdjackryan@googlemail.com>
Date2011-04-04 04:52 -0500
SubjectRe: Lambda Shambda
Message-ID<BANLkTikw7VndkCkzCCSTyQD-h9n=wOCFZA@mail.gmail.com>
In reply to#2247
On Mon, Apr 4, 2011 at 11:23 AM, Everett L Williams II
<rett@classicnet.net> wrote:
>
> *And, of course, since we were talking about making a practical decision
> about which tool to use, performance cannot possibly matter. There is also
> this overriding compulsion amongst coders to produce the most abbreviated
> code possible, assuming that such demonstrates their special skills and that
> such code is the most desirable. Any study of algorithmic efficiency will
> show clearly that the shortest code is almost never the fastest code,
> especially in unoptimized code.*

Strawman, again.

We were not talking about performance. 'sides, premature optimization
is the root of all evil. Once there's benchmarks and solid data on
load and usage, we can talk about optimizing for performance. Enjoy
making an Excel spreadsheet multi-threaded, though. Excel 2007 isn't
cheap (which introduced multi-threading for spreadsheets).

> *If this were an extraordinary claim, your comment would hold true, but only
> exceptional arrogance would cause any other claim to be made. "Acceptable"
> means satisfactory to the person doing the programming, who is usually some
> grunt just trying to get his job done, rather than someone who is a
> proponent of any particular thing. I'll try not talk about "fanboys" here.*

It's called burden of proof. You make a claim, you go prove it.

Further: given your definition of acceptable, any code at all,
qualifies as "acceptable", no matter its performance (you brought it
up), maintainability (the comptroller will bring *that* up), or
buggyness (So what if the application crashes and burns if a variable
isn't formatted as expected?).

> *When I am responsible for something, unless some feature in the current
> version is absolutely necessary, I tend to drop back one or two versions to
> cover most of my market, not to mention to avoid the hazards of being on the
> bleeding edge.*

How many of all machines running Windows run Excel as well, and in
which versions?

What you tend to do is irrelevant, I want to know if a tool based off
of Excel has a viable market.

> *Having made the progression from Assembler to COBOL and FORTRAN and on to
> dozens of other languages, I would have agreed with you until I started
> seeing people write all sorts of stuff in Excel. Again, I would never have
> recommended those uses, but they seemed to do the job.*

Well, then you can provide a non-trivial example of an Excel
spreadsheet that doesn't use VBA, right?

> On the other hand, matrices are not the only method
> for working such problems.

In EE, it's the fastest, least error-prone method to analyze networks,
since you can use Kirchhoff's circuit laws.

> From what I know of it, I wouldn't use Excel for
> huge classes of problems, but some people seem to be able to twist it to do
> things that I would never have guessed. "To the man with a hammer,
> everything looks like a nail."...even when a screw or glue might do a better
> job. The point is that he knows how to use the hammer and can get prodigious
> amounts of work done with it, so he has to think very carefully when someone
> tells him he has to learn this new and completely different tool while the
> work gets behind.

And that is the rub: People don't know better. The reasons are
multiple, but that's what it comes down. If all I know is how to drive
a car with automatic transmission, I won't be able to get the best out
of a car with manual transmission.

> About 50% of the real newbies to programming who come on this site with a
> complex project that requires unstable parts of the Ruby pantheon, should be
> told to use another tool, one that is simpler, more mature, and that does a
> better job of handholding, but people who spend most of their time on Ruby
> tend to think with their hammer, so to speak, or maybe, they don't really
> know anything else.

Take a look at the archives of ruby-talk, then. You'll be surprised.

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


#2257 — Re: Lambda Shambda

FromRobert Klemme <shortcutter@googlemail.com>
Date2011-04-04 06:19 -0500
SubjectRe: Lambda Shambda
Message-ID<BANLkTinwNA=30iizb3C=D2tZJ4+HwW8XNA@mail.gmail.com>
In reply to#2250
On Mon, Apr 4, 2011 at 11:52 AM, Phillip Gawlowski
<cmdjackryan@googlemail.com> wrote:
> On Mon, Apr 4, 2011 at 11:23 AM, Everett L Williams II
> <rett@classicnet.net> wrote:
>>
>> *And, of course, since we were talking about making a practical decision
>> about which tool to use, performance cannot possibly matter. There is also
>> this overriding compulsion amongst coders to produce the most abbreviated
>> code possible, assuming that such demonstrates their special skills and that
>> such code is the most desirable. Any study of algorithmic efficiency will
>> show clearly that the shortest code is almost never the fastest code,
>> especially in unoptimized code.*

I'm not sure how you want to prove that given that the number of
algorithms is potentially unlimited, but anyway: the discussion has
digressed so far from the original topic that I don't find it useful
to dive further.  I also wonder what you are trying to accomplish by
suggesting that most people here strive for shortest code over fast or
even correct code.  I don't think this is the case - at all.

>> About 50% of the real newbies to programming who come on this site with a
>> complex project that requires unstable parts of the Ruby pantheon, should be
>> told to use another tool, one that is simpler, more mature, and that does a
>> better job of handholding, but people who spend most of their time on Ruby
>> tend to think with their hammer, so to speak, or maybe, they don't really
>> know anything else.
>
> Take a look at the archives of ruby-talk, then. You'll be surprised.

I disagree as well.  Everett, you'll find plenty of postings

- suggesting a different tool,
- showing that the poster is fluent in at other languages.

in here.  In fact, discussions comparing features of Ruby with other
programming languages' features (boy, did I get the plural right?) and
how one or the other can be better utilized to solve a given problem
are among the most interesting and insightful ones.

Cheers

robert

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

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


#2194 — Re: Lambda Shambda

FromMartin DeMello <martindemello@gmail.com>
Date2011-04-03 08:13 -0500
SubjectRe: Lambda Shambda
Message-ID<BANLkTinb1T3HMRYrQSzfxbbKCKBV6HvZ3w@mail.gmail.com>
In reply to#2184
On Sun, Apr 3, 2011 at 1:18 PM, Phillip Gawlowski
<cmdjackryan@googlemail.com> 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".

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

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


#2238 — Re: Lambda Shambda

FromPhillip Gawlowski <cmdjackryan@googlemail.com>
Date2011-04-04 00:55 -0500
SubjectRe: Lambda Shambda
Message-ID<BANLkTi=JSzyca1MTo3s=zAYNaB1YdszEYg@mail.gmail.com>
In reply to#2194
On Mon, Apr 4, 2011 at 1:30 AM, Chad Perrin <code@apotheon.net> wrote:
>
> 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.

Though, Microsoft Research is a different beast than MS proper (as
much as a "MS proper" can exist with such a corporation), and doesn't
have to toe the party line as much as the Office Business Unit would
have to, for example.

> Excel is a *spreadsheet* -- which happens to have a programming language
> embedded in it (and not a very good one, at that).

That's a bit harsh. After all, Excel doesn't have to *be* a language VM.

Thus, it only needs a DSL, and Excel's DSL is a damned good one, and
thorough in tackling its problem space. Further, Excel doesn't need to
be Turing-complete: Spreadsheets have many areas that they can be used
in, and in pretty much all of them the business rules are too complex,
or too much of a moving target, to make programming in the more
traditional sense feasible.

And that's why MS provides OLE Automation, and makes it relatively
easy to develop Office add-ins for specific needs.

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


#2269 — Re: Lambda Shambda

FromPhillip Gawlowski <cmdjackryan@googlemail.com>
Date2011-04-04 10:16 -0500
SubjectRe: Lambda Shambda
Message-ID<BANLkTi=sf7bUepF0AXxy5eCo7YYK=iHOgQ@mail.gmail.com>
In reply to#2238
On Mon, Apr 4, 2011 at 4:51 PM, Chad Perrin <code@apotheon.net> wrote:
>
> This is true, of course -- but there is still an influence there where
> research publications will surely be expected to serve some end Microsoft
> executive policy finds worth of approval.  After all, if Microsoft
> Research consistently failed to serve Microsoft's bottom line in some
> way, it would be shut down.

There's more to the bottom line than, well, the bottom line. That can
be, for example, public relations, or staying on the cutting edge of a
market. I doubt that something like Microsoft Surface will ever be
produced. OTOH, MS research created .NET, PhotoSynth, and Kinect.

But that doesn't matter: The paper linked in this thread credits two
researcher from non-MS institutions.

> You're not making the same claim here that was originally made.

That could be because I'm not making the same the claim. OTOH, your
statement was drifting too much into the opposite direction (i.e.
spreadsheets being useless without a proper programmer, to exaggerate
a bit).

> Sure.  That doesn't change what was actually said prior to this, however.
> Reorienting the pro-Excel argument so that it agrees with things others
> (including me) have already said does not make the preceding pro-Excel
> arguments any less wrong.

Considering that I am making the same argument I always have in this
threat (that Excel isn't the best choice of tool, and is highly
specialized), that isn't all that surprising. ;)

I'm not, nor have I ever been, a member of the Commu^W^W^W^Wproponent
of Excel as a language VM.

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


#2282 — Re: Lambda Shambda

FromIain Barnett <iainspeed@gmail.com>
Date2011-04-04 15:50 -0500
SubjectRe: Lambda Shambda
Message-ID<83D4A1CD-93D4-4E07-B6EA-EEA8F94C9B13@gmail.com>
In reply to#2184
> On 3 Apr 2011, at 08: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 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.

Argument by authority is not an absolute fallacy and would only apply if he was using that authority to overrule any other view than his, and regardless, the point being made was by comparison/contrast. Having studied physics at that level does show a certain ability in concentration, mathematics, and abstract thought, and would (hopefully) mean that you'd be able to pick up things in fields where those abilities are useful.

I liked using Haskell for a while, and I found producing code that looked beautiful and dealt with things that were (usually) hard in other languages was easy. Getting it to do anything easy was (sometimes) very difficult though.

YMMV, I dropped out of my physics degree (partially) because it was too difficult :)

And I like recursion! (Though Ruby's recursion too often fails me to bother with it for anything that shouldn't fail*)


Regards,
Iain

* which is almost everything

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


#2209 — Re: Lambda Shambda

FromPhillip Gawlowski <cmdjackryan@googlemail.com>
Date2011-04-03 15:07 -0500
SubjectRe: Lambda Shambda
Message-ID<BANLkTimkNPkabu6oHdDx6aXsS3fXSO2=_A@mail.gmail.com>
In reply to#2178
On Sun, Apr 3, 2011 at 9:03 PM, Chad Perrin <code@apotheon.net> 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 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]


#2190 — Re: Lambda Shambda

FromJohnny Morrice <spoon@killersmurf.com>
Date2011-04-03 06:05 -0500
SubjectRe: Lambda Shambda
Message-ID<20110403120555.0046e326@fractal>
In reply to#2036
> 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

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


#2061 — Re: Lambda Shambda

FromPhillip Gawlowski <cmdjackryan@googlemail.com>
Date2011-03-31 13:56 -0500
SubjectRe: Lambda Shambda
Message-ID<AANLkTikcikDY7fEA_YUR-=UAS_PSWthtvvfaXUBmkGNG@mail.gmail.com>
In reply to#2021
On Thu, Mar 31, 2011 at 7:44 AM, Chad Perrin <code@apotheon.net> wrote:
>
>> Authentication and authorization, and table/row/cell locking.
>
> Err . . . are you saying this is some kind of feature Excel has and
> DBMSes that do stored functions/procedures, like PostgreSQL and Oracle,
> do not?

The opposite. Definitely the opposite!

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


#1991

FromMartin DeMello <martindemello@gmail.com>
Date2011-03-30 15:46 -0500
Message-ID<AANLkTindTKTLBWR-YDoc78VoxSBkdxA61dxss9h=-438@mail.gmail.com>
In reply to#1942
On Wed, Mar 30, 2011 at 12:59 PM, Robert Klemme
<shortcutter@googlemail.com> wrote:
>
> 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. :-)

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

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

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


#2244 — Re: functional paradigm taking over

FromMike Stephens <rubfor@recitel.net>
Date2011-04-04 04:05 -0500
SubjectRe: functional paradigm taking over
Message-ID<6aeb13eb26b5656ca2247601ed369bcf@ruby-forum.com>
In reply to#1942
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/.

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


#2246 — Re: functional paradigm taking over

FromJohnny Morrice <spoon@killersmurf.com>
Date2011-04-04 04:21 -0500
SubjectRe: functional paradigm taking over
Message-ID<20110404102004.2fda5d35@fractal>
In reply to#2244
> 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

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


#2248 — Re: functional paradigm taking over

FromJohnny Morrice <spoon@killersmurf.com>
Date2011-04-04 04:25 -0500
SubjectRe: functional paradigm taking over
Message-ID<20110404102531.3450db23@fractal>
In reply to#2244
E.g. which language in particular do you have beef with?  Why?

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


#2249 — Re: functional paradigm taking over

FromStu <stu@rubyprogrammer.net>
Date2011-04-04 04:28 -0500
SubjectRe: functional paradigm taking over
Message-ID<BANLkTikJrkUmPmDRDqamHJpm20C0PE5fRQ@mail.gmail.com>
In reply to#2244
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/.
>

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


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

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


csiph-web