On 04/03/2011 11:01 PM, Petite A. wrote:
More on the subject of message threading, courtesy of Jamie Zawinski:
+1 for this one, well written (but sad) and the uber-cool menu 
On Mon, Apr 04, 2011 at 05:21:33AM +0900, Josh C. wrote:
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 [. . .] 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}”
The snarky answer is that the reason it starts a new thread in Gmail is
Gmail’s lack of proper threading support.
(musing: I wonder how ruby-forum knows they are part of the same
thread.)
Check the headers. It is likely the clues to the forum’s magic lie
therein.
On Mon, Apr 04, 2011 at 05:07:39AM +0900, Phillip G. wrote:
On Sun, Apr 3, 2011 at 9:03 PM, Chad P. [email protected] wrote:
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*…
I was referring to programming language design in general, and not
specifically to compilers and LISP capabilitites per se, when I said
“the
cutting edge”. The commentary to which I replied evinced a fairly
Luddite flavored rejection of programming in favor of spreadsheet abuse.
- 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.
My mileage (on this subject) depends somewhat on context.
On Mon, Apr 4, 2011 at 1:30 AM, Chad P. [email protected] 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 G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.
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?
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
Phillip G. wrote:
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 thereare 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.
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
*
E.g. which language in particular do you have beef with? Why?
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 11:23 AM, Everett L Williams II
[email protected] 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 G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.
On Mon, Apr 4, 2011 at 11:05 AM, Mike S. [email protected]
wrote:
When you consider the merits of functional languages, I believe you
should take into account not only the elegance with which you can
express what you want to do, or how amenable it is to eg parallel
processing. You should also consider whether it strikes a better balance
between such issues and accessibility. Does all your terseness and
‘elegance’ give you a justifiable advantage over something simpler which
could be more easily handled by a person of less capability?
A) Provide examples that functional programming leads to “terseness”
(BTW, the Laconians of old Greece preferred to say as much as possible
in as few words as possible; one man’s virtue is one man’s sin, it
seems).
B) Define “accessibility”. Surely you aren’t saying that the UI of a
program is related to which language it was written in. If you mean
issues like maintainable code, isn’t a strictly logical, mathematical
structure preferable, especially if it can be analyzed (tooling is our
friend) with the help of other programs? If, indeed, the code can be
proven to be correct (proven in the mathematical sense)?
C) Why should someone with less capability be taken care off by going
onto their levels, instead of helping them to reach new heights (we
could call such an effort “No Coder Left Behind”)? Maths isn’t hard,
nor is programming. So this smells like the plot of “Harrison
Bergeron” to me.
D) Wouldn’t a person with less capability be aided by code that
follows simple, logical rules?
sigh This’ll be the ORM debate all over again, I bet.
Phillip G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.
Maths isn’t hard
As someone doing his math homework as we speak, I beg to differ 
On Mon, Apr 4, 2011 at 12:15 PM, Johnny M. [email protected]
wrote:
Maths isn’t hard
As someone doing his math homework as we speak, I beg to differ
That’s why it’s homework. 
–
Phillip G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.
On Mon, Apr 4, 2011 at 11:52 AM, Phillip G.
[email protected] wrote:
On Mon, Apr 4, 2011 at 11:23 AM, Everett L Williams II
[email protected] 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
On Mon, Apr 4, 2011 at 11:28 AM, Stu [email protected] wrote:
is this a good book to read to grok functional programming,
http://mitpress.mit.edu/sicp/full-text/book/book.html
It is, almost religously considered as such ;). I do not share this
POV for the simple reason that I am too stupid to understand it.
However, I found the “corresponding” MIT videocasts much more easy to
grasp.
e.g. Lecture 1A | MIT 6.001 Structure and Interpretation, 1986 - YouTube
HTH
Robert
Mike,
Mike S. wrote:
between such issues and accessibility. Does all your terseness and
‘elegance’ give you a justifiable advantage over something simpler which
could be more easily handled by a person of less capability?
*You have restated my point in much more pleasant language, and with
commendable precision. The average person who wishes to program a
solution to a problem cares not one whit whether the tool they find most
accessible qualifies as a programming language by another person’s
definition. They just want to get their problem solved. Personally,
though I have been arguning the side of Excel here, I hate spreadsheets.
It is arguable that almost anything that can be accomplished with a
database and implementing language such as SQL can be accomplished with
a spreadsheet. I just happen to prefer the DB way of describing and
thinking about data. But, as I have said, I have seen some absolutely
amazing things doen with spreadsheets. My particular crutch for dealing
with DB’s is Alpha 5, but there are dozens of such solutions out there.
I happen to be a person with 45 years in the computing field, with
specific knowledge of lambda calculus, Turing completeness, object
orientation, structured programming, relational databases, and an host
of other such things, but I have also learned that the real purpose of
computer programs is to get work done unless I am specifically
researching computing as a science. “Turing completeness” is a term of
art that could be replaced in the minds of 99.9% of even fairly
technically competent programmers with any other reference for which
they have poor understanding. If being TC means that the tool can get
the job done accurately and efficiently, including the time that it
takes to create a program, then they are all for it. Most could not even
accurately describe a Turing machine in the original sense of that
definition.
Denigrating another person’s choice of tools will certainly not make
that person likely to seek your advice again, nor consider you helpful.
If you have confused your switchblade with a Swiss Army knife, then you
are more foolish than the person you are denigrating. Since this is a
Ruby forum, sometimes the best answer is to refer a person to docs
and/or books for deeper learning rather than try to answer the first
problem that they run into as if that will really help them make
efficient use of Ruby. Help with installing and making Ruby work
properly are always appropriate, but only time and study and practice
will actually allow people to program with any confidence. When people
come from other programming disciplines, comparison of modalities and
techniques are usually helpful, but fanboy expressions of “mine is
bigger and/or better than yours” are not.
Eveerett L.(Rett) Williams II
*
But, as I have said, I have seen some absolutely
amazing things doen with spreadsheets.
I’ve seen some absolutely amazing things done with befunge! Networked
programs, even. Which is more than excel can do.
However, I think it would be reasonable for people to disagree with me,
if I were to insist on a public forum that befunge is somehow
preferable to the entire imperative school of programming languages.
When people come from other programming disciplines, comparison of
modalities and techniques are usually helpful, but fanboy expressions
of “mine is bigger and/or better than yours” are not.
Since I am completely awesome*, I offered to attempt dissect a
piece of functional code for him, if he would provide one. This would
definitely involve a comparison of techniques. We may both learn
something!
- Due to the lack evidence or attention to detail in your post, I feel
confident asserting my awesomeness without any display of rigour,
evidence or logic.
I’ve seen some absolutely amazing things done with befunge! Networked
programs, even. Which is more than excel can do.
Sorry, what with all the bullshit I forgot to provide any evidence of
this fact:
http://zem.fi/~fis/fungot.b98.txt
On Mon, Apr 4, 2011 at 4:28 AM, Stu [email protected] wrote:
is this a good book to read to grok functional programming,
http://mitpress.mit.edu/sicp/full-text/book/book.htmlI have done some lisp but interested in gaining the skillset with ruby,
any nice thick comp sci books for recommendation?
I haven’t gone through it yet, but I have a PDF version I can upload if
you
don’t like the html format of that one. It should be understood, though,
that Ruby’s functional support isn’t the same as that of the purely
functional languages. That isn’t to suggest you won’t get insights from
that
book, I know a lot of relevant people who have recommended it (ie Uncle
Bob,
and Rick DeNetale).
On Mon, Apr 4, 2011 at 6:31 AM, Everett L Williams II
[email protected]wrote:
*You have restated my point in much more pleasant language, and with
commendable precision.
Hmm, I thought he deserved to be chastised for making a post almost 90%
of
which was about databases. It fits quite nicely with the hypothesis that
he’s just trolling.
On Mon, Apr 4, 2011 at 7:29 AM, Johnny M.
[email protected]wrote:
I’ve seen some absolutely amazing things done with befunge! Networked
programs, even. Which is more than excel can do.Sorry, what with all the bullshit I forgot to provide any evidence of
this fact:
http://zem.fi/~fis/fungot.b98.txt
Amusingly, you added this on a whim, but it’s more evidence than the
Excel
proponents (sorry, I mean “S# programmers”) have provided, despite
several
explicit requests for clarification and examples.
On Mon, Apr 04, 2011 at 06:23:24PM +0900, Everett L Williams II wrote:
almost never the fastest code, especially in unoptimized code.*
Programming is about automation. The most important things about
automation are:
-
reducing the workload on humans (for lack of a better term for those
whose workload we’re trying to reduce – I wouldn’t want to discriminate
against dolphin programmers or the artificial intelligences of the
future) -
using automation abstractions that can be leveraged to produce
additional, higher level automation abstractions further down the line
While software performance and resource consumption are certainly
factors
to consider here, they are not the only factors to consider. If it
takes me a month of eight-hour days to write a program that saves each
of
thirty people three seconds out of every day, and isn’t interesting
enough code to ever provide measurable leverage for further automation,
that’ll pay off in about twenty-six years of use, no matter how well the
code performs. If it takes me eight minutes to write it because I
didn’t
worry about the performance of my code, though, it’ll only take about
five days to pay off; everything after that is pure automation profit.
Obviously, this is a simplified example, but simplicity often makes a
clearer point than belaboring the minor details.
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.
I don’t know if I would say that the claim there are more people who can
use MS Excel to automate things is extraordinary, in and of itself. I
also think there are people who perform automation tasks in MS Excel
that
are “acceptable” by some reasonable measure. If you combine the two, to
claim that there are more people who can automate tasks in MS Excel that
fall within the strengths of Ruby as a programming language to a level
of
reasonable acceptability that is equivalent to what Ruby programmers
produce, however, I think we’re slipping into the realm of the
extraordinary.
Do you really think it is not extraordinary to claim that MS Excel is
even an acceptable tool by any kind of reasonable criteria to use for
tasks like writing the portupgrade tool for FreeBSD, developing a Web
framework that speeds and organizes the process of developing
applications the way Rails does, or supports code organization that
improves the maintainability of applications the way Ruby’s object
oriented programming facilities do?
I do not think we even need to touch the subject of whether there are
more people who can do such things in MS Excel than can do them in Ruby;
it is sufficient to examine the potential for doing such things in a
reasonable, practical, “acceptable” manner in MS Excel, as compared with
that potential in Ruby. That simple examination alone makes me think MS
Excel falls well short of the mark. As far as I can tell at the moment,
the only way we can define the challenge set before us so that there
are more people who can write “acceptable programs” in MS Excel than in
Ruby is by defining “acceptable programs” in such a limited manner that
it does not require anyone to actually do any programming to speak of.
Filling in a spreadsheet, assigning formulae to cells, and writing a
couple of macros hardly compares to what the vast majority of even
mediocre Rubyists can do – and, frankly, the same data manipulation
tasks that MS Excel supports via filling in the spreadsheet, assigning
formulae to cells, and writing a couple of macros can be done much more
quickly and easily in Ruby by a mediocre Rubyist than in MS Excel by a
competent Excel user.
So . . . I suppose you could answer the request to define “acceptable”
in
a manner that makes it a less extraordinary claim, but I am skeptical
that doing so would provide a response that looks remotely reasonable.
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.
That you do not recognize the absurdity of the suggestion that we write
everything in ActionScript and distribute it in Flash files seems
indicative of your unwillingness to consider the impracticality of using
the wrong tool for the job – which would explain this dogged attachment
to the idea of using MS Excel to do “programming”.
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.
By the same token, a hammer can be used to drive screws into wood, but I
wouldn’t recommend it – even if it seems to be doing the job for
someone
who clearly does not know any better.
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.
. . . or maybe he should get someone willing and able to use a better
tool to do the job.
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.
Telling people “You can’t handle Ruby – go back to Excel!” is hardly a
good way to encourage people to learn and enjoy the use of new tools.
If
people want to learn new things, I think discouraging them from doing so
just because you think they should stick to VBA macros is nigh-evil.