[nSLUG] perl and web sites
George N. White III
gnwiii at gmail.com
Sun Mar 2 14:57:21 AST 2014
On Sun, Mar 2, 2014 at 12:04 PM, Robin Murray <nibor.yarrum at gmail.com>wrote:
> I have to agree. Reflecting on this over the last couple of days, I've
> realized that you could get 100 rails people to say that moving to rails
> would be the best solution. And you could turn around and get 100 php
> people to say that moving to php would be the best solution. And 100 perl
> people to say that staying with perl would be best. There are just so many
> tech options out there it boggles the mind, and people will tout their own
> famiiar/comfortable solution over others because, well, that's human nature.
"Best" is a tricky thing. For many projects, rails, php, perl, and others
can all provide
satisfactory results, so "best" may boil down things like personalities
will get along with the rest of the team or can bring insight into the
client base, etc.?).
My personal preference is to "never do something the same way twice"
because I find it
more fun trying new approaches. That works in well science but often
(e.g., unless you are Apple) isn't the way to run a business.
The distinction between people who are expert in a particular tool and
those who are willing and able to choose the tools that fit the problem has
parallels in the dispute over how maths should be taught in schools. On
one hand you have the people who want schools to focus on times tables and
rote approaches to solving problems. At the other end of the spectrum are
those who want to focus on basic concepts and let students find ways to
solve arithmetic problems, allowing multiple ways to getting the answer.
Both sides seem to agree that students should be able to do solve basic
problems without a calculator.
Yesterday's Globe and Mail has an article about the dispute. The example
given was 25*44, which you could work out longhand or recognize as
(25*4)*11=1100. One objection to the concepts approach is that schools
should only teach the most efficient method (one of the experts answered
that the most efficient way to do arithmetic is with a calculator). In
practice, teachers faced with an approach that allows multiple solution
methods would have to be able to help a student who tries an oddball
approach but runs into difficulties. Ideally a teacher could either point
out a mistake or explain why the approach can't work. In practice, few
teachers can do that and probably nobody can do it with a large class and
I went to elementary school in the 1950's (a time when every adult had
vivid memories of a) the depression, and b) WWII), in a small town where
many elementary school teachers never got past adding 2+2. We the students
took that as a challenge and worked out long division and trig. among
ourselves. Many of the students were 4H members (where the kids run their
program and adults' roles are to provide advice) we knew that adults
weren't necessary to get stuff done. I remember one teacher who had a
"solutions" manual in which many of the answers were wrong, but lacked the
self-confidence and knowledge to sort that out on her own. I think we
eventually succeeded in teaching her long division, but she quit teaching
at the end of the year.
More recently I've taught in workshops for students from developing
countries who also had experiences of early education where students were
forced to take responsibility for much of their learning, while teachers
spent their time finding supplies (food, water, paper, pencils, etc) and
The real world functions on the efforts many people who follow recipes well
and avoid innovation. The trick for a business is to anticipate when the
old recipe is about to fail and
find a new recipe before the business falls apart. One way to do this is
to hire "an expert" to write the new recipe, but that doesn't always work.
Another approach is to generate change
internally by exposing the recipe followers to new approaches, having them
teach the recipe to
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG