On Sat, 17 Feb 2018 15:25:15 +1100, Chris Angelico wrote:
> 1) Type safety.
>
> This is often touted as a necessity for industrial-grade software. It
> isn't. There are many things that a type system, no matter how
> sophisticated, cannot catch;
The usual response to that is to make ever-finer-grained types, until the
type-system can prove the code is correct.
integers
positive integers
positive integers greater than 10
positive integers greater than 10 but less than 15003
positive odd integers greater than 10 but less than 15003
positive odd integers greater than 10 but less than 15003 divisible by 17
Of course, this has a few minor (ha!) difficulties... starting with the
hardest problem in computer science, naming things.
Even if you can come up with unique, concise names for these types that
won't overwhelm the reader, it isn't clear that the type system will
always be capable of representing such fine distinctions. How would you
specify two string types, one for personal names and one for family
names, so that the compiler can detect any attempt to assign a family
name to a personal name, or vise versa?
And of course, there are certain errors which *even in principle* cannot
be detected at compile-time:
- bad user input;
- memory exhaustion;
- out of disk space;
- I/O errors when reading or writing data;
- network failures;
- logic errors (your code does what told it to do perfectly,
it's just not what you wanted...)
etc.
> for some reason, though, we don't hear
> people saying "C is useless for industrial-grade software because it
> doesn't have function contracts".
You obviously don't speak to Eiffel programmers then :-)
> Anyway, if you want some system of type checking, you can use static
> analysis (eg tools like MyPy) to go over your code the same way a
> compiler might.
Indeed. Despite our criticisms of the *attitude* that static typing is a
panacea, it must be recognised that it is useful, and the bigger the
project, the more useful it is. And some type checkers are *very*
impressive. Google for "compiler found my infinite loop" for a classic
example of a compiler detecting at compile-time than a while loop would
never terminate.
(The language was ML, not C. The C type system isn't that good. In fact,
ironically proponents of languages in the ML family consider C and its
family to be weakly-typed.)
I can understand people saying that for sufficiently large projects, they
consider it indispensable to have the assistance of a type checker. That
in and of itself is no worse than saying that, as a writer, I find a
spell checker to be indispensable.
> "The first glaring issue is that I have no guarantee that is_valid()
> returns a bool type." -- huh? It's being used in a boolean context, and
> it has a name that starts "is_". How much guarantee are you looking for?
> *ANY* object can be used in an 'if', so it doesn't even matter. This is
> a stupidly contrived criticism.
I don't think so -- I think a lot of people really have difficulty coming
to terms with Python's duck-typing of bools. They just don't like, or
possibly even grok, the idea of truthy and falsey values, and want the
comfort of knowing that the value "really is" a True or False.
We can come up with some contrived justifications for this... what if
is_valid() contains a bug:
def is_valid(arg):
if some condition:
return arg # oops I meant True
return False
then static analysis would detect this. With truthiness, you can't tell:
what if *nearly* all the input args just happen to be truthy? Then the
code will nearly always work, and the errors will be perplexing.
But I consider that a fairly contrived scenario, and one with at least
two alternate solutions: code review, and unit tests.
But still, I do see the point that a static analyser could have picked up
that error even if you didn't have code review, even if the person
writing the unit tests never imagined this failure mode.
[...]
> Totally not true. The GIL does not stop other threads from running.
> Also, Python has existed for multiple CPU systems pretty much since its
> inception, I believe. (Summoning the D'Aprano for history lesson?)
If you're talking about common desktop computers, I think you're
forgetting how recent multicore machines actually are. I'm having
difficulty finding when multicore machines first hit the market, but it
seems to have been well into the 21st century -- perhaps as late as 2006
with the AMD Athelon 64 X2:
https://www.computerhope.com/history/processor.htm
The first public release of Python was 1991, so I'm not sure what sort of
support it had for multiple CPUs or multiple cores. Perhaps none.
By the way, multiple CPU machines are different from CPUs with multiple
cores:
http://smallbusiness.chron.com/multiple-cpu-vs-multicore-33195.html
One of the more interesting (although perhaps not cost-effective) uses
for multiple CPUs is a machine with two distinct hardware architectures,
running two distinct OSes, well before the days of virtualisation
technology. Back in the 1980s (1989, perhaps?) TI and Apple developed a
NuBus card containing a TI Lisp Machine CPU. For a mere $10,000 or so
($20K in today's money) you could simultaneously run a Lisp Machine in
your Macintosh II.
http://lemonodor.com/archives/2002/10/ti_microexplore.html
Certainly though there have been versions of Python without a GIL for a
long time:
Jython started as JPython, in 1997; IronPython was started around 2003 or
so, and reached the 1.0 milestone in 2006.
Fun fact: (then) Microsoft engineer Jim Hugunin created both JPython and
IronPython!
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
