>> On 6/04/16, Linda McIver wrote:
> A couple of reasons. 1. It is widely used in real data science.
"It is widely used by experts" does not mean
"it is suitable for beginners." All sorts of things are used
in real data science, including the seriously weird SQL.
> 2. nice clean human-readable syntax
> (this is where R seems to hit the wall)
Python has, um, quirks of its own. Which is why Python 3
exists, but Python 2 isn't going away like it was supposed
to. So we have the unfortunate case of "Python" programs
that don't work in "Python" (both ways around).
The sadly amusing thing here is that R syntax is a straight
steal from S, and S syntax was largely adapted from C
*in order to have something programmers would be comfortable
with*. And I must say that compared with GLIM, GenStat, and
SAS, it was a success. R syntax really isn't as bad as it
seems. You could call it "C: the good bits" + keyword
parameters. I think the main barrier for experienced
programmers is the heavy used of "vectorised" forms with
subscripting overloaded in a number of very useful ways,
and the whole-object thinking you have to do. So maybe
the semantics is the key issue.
Which has me wondering if you evaluated Octave?
(I have a copy of Octave, but almost never used it, so I
have no idea of the quality of its error messages.)
> 3. We
> will do some spreadsheet stuff, but they won't all have access to Excel,
They COULD all have access to LibreOffice.
Spreadsheets are interesting because of Ray Panko's
work on errors and work on spreadsheets.
"What we know about spreadsheet errors."
"there has long been ample evidence that errors in spreadsheets are
pandemic. Spreadsheets, even after careful development, contain errors in
one percent or more of all formula cells. In large spreadsheets with
thousands of formulas, there will be dozens of undetected errors. Even
significant errors may go undetected because formal testing in spreadsheet
development is rare and because even serious errors may not be apparent."
So there's something worse than poor error messages,
and that's *missing* error messages.
This is one reason why I wish DrRacket included a a statistics
Scheme, like Python and R, is a dynamically typed language, but
DrRacket works hard to try to detect some type errors at
compile time. (This was one of the strengths of ABC. It did
not require or even allow the programmer to provide type
annotations, but it did do quite strong type inference/checking,
and this was because it was meant for beginner use. It's a real
pity that Guido van Rossum abandoned that for Python.) The
problem with run-time errors is that they are reported a long
time after you wrote the mistake that caused them.
Which leads me to F#.
F# is an interesting candidate for doing data science
- it is an interactive programming language
- that runs under .NET and Mono
- which compiles via the .NET intermediate language to
tolerably good native code, making it practical for
large amounts of data
- which has kit available for "data science"
(search for F# for data science) e.g. http://fslab.org/
- having an indentation-based syntax these days
- and is as concise as Python or more so
- but is strongly typed so more errors are caught early.
I don't know how well novices would cope with its error
messages. What I'm suggesting here is that the question
of WHEN an error is reported may be as important as HOW
it is reported, and that F#-for-data-science vs Python-
for-data-science might be one way of exploring that.
(The F# compiler is open source, so it should be possible
to reword its error messages.)
There's another issue, which is that syntax-colouring
editors (which I personally hate with a visceral hatred)
may help novices. For example, Squeak and Pharo have
editors where when you type an identifier, it is red if
the compiler doesn't recognise it, black if it does, so
most spelling mistakes are instantly reported. Bracket
matching is another way of unobtrusively reporting some
errors very early.
So how are your students writing Python?
Inside IDLE? Notepad? Some other way?
> and I want them to learn some basic programming as well, in particular for
> data extraction/cleaning type tasks that rather stretch excel's
> capabilities. I know you can program macros to do most of this stuff, but
> hey presto we are suddenly teaching programming in a
> less-than-beginner-friendly syntax and system.
> The main thing is that I want to teach them real skills that they can
> continue to lose.
> Even worse, many of them
> are outright frightened by computation.
There is something worse than a scientist frightened by
computation, and that's one who isn't. It's OK when it's
an MSc or PhD student, but any project with serious
funding that has nontrivial coding to do would do well to
hire someone who is good at it. I've got some climate models
on my machine, and I honestly don't know whether to laugh or
scream. Generally, I end up doing a bit of both.
For what it's worth, there's a Python e-book for schools
that was written here. Would you like me to have a word
with the people who wrote it to see if they would like to
talk about Python error messages?
You received this message because you are subscribed to the Google Groups "PPIG
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.