473,581 Members | 2,670 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Python from Wise Guy's Viewpoint

THE GOOD:

1. pickle

2. simplicity and uniformity

3. big library (bigger would be even better)

THE BAD:

1. f(x,y,z) sucks. f x y z would be much easier to type (see Haskell)
90% of the code is function applictions. Why not make it convenient?

2. Statements vs Expressions business is very dumb. Try writing
a = if x :
y
else: z

3. no multimethods (why? Guido did not know Lisp, so he did not know
about them) You now have to suffer from visitor patterns, etc. like
lowly Java monkeys.

4. splintering of the language: you have the inefficient main language,
and you have a different dialect being developed that needs type
declarations. Why not allow type declarations in the main language
instead as an option (Lisp does it)

5. Why do you need "def" ? In Haskell, you'd write
square x = x * x

6. Requiring "return" is also dumb (see #5)

7. Syntax and semantics of "lambda" should be identical to
function definitions (for simplicity and uniformity)

8. Can you undefine a function, value, class or unimport a module?
(If the answer is no to any of these questions, Python is simply
not interactive enough)

9. Syntax for arrays is also bad [a (b c d) e f] would be better
than [a, b(c,d), e, f]

420

P.S. If someone can forward this to python-dev, you can probably save some
people a lot of soul-searching
Jul 18 '05
467 21361
William Lovas <wl****@force.s twing.upenn.edu > writes:
[...] Static typing is a luxury!


Very well put!
Jul 18 '05 #81
Garry Hodgson <ga***@sage.att .com> writes:
Pascal Bourguignon <sp**@thalassa. informatimago.c om> wrote:
You're right, I did not answer. I think that what is missing in
classic software, and that ought to be present in AI software, is some
introspective control: having a process checking that the other
processes are live and progressing, and able to act to correct any
infinite loop, break down or dead-lock.


so assume this AI software was running on Ariane 5, and the same
condition occurs. based on the previously referenced design
assumptions, it is told that there's been a hardware failure, and that
numerical calculations can no longer be trusted. how does it cope
with this?


I just read yesterday an old paper by Sussman about how they designed
a Lisp on a chip, including the garbage collector and the eval
function. Strangely enough that did not included any ALU (only a test
for zero and an incrementer, for address scanning).

You can implement an eval without arithmetic and you can implement
theorem prover above it still without arithmetic. You can still do a
great deal of thinking without any arithmetic...

Some hardware may help in
controling this controling software, like on the latest Macintosh:
they automatically restart when the system is hung.


in this case, a restart would cause the same calculations to occur,
and the same failure to be reported.


In this case, since the problem was not in the supposed AI controlling
agent, there would have been no restart.

And purely at the
hardware level, for a real life system, you can't rely on only one
processor.


absolutely right. though, in this case, this wouldn't have helped either.
the fatal error was a process error, and it occurred long before launch.


I think it would have been helped. For example, an architecture like
the Shuttle's where there are five computer differently programmed
would have helped, because at least one of the computers would not
have had the Ariane-4 module.

--
__Pascal_Bourgu ignon__
http://www.informatimago.com/
Jul 18 '05 #82
William Lovas wrote:
In article <bn**********@f 1node01.rhrz.un i-bonn.de>, Pascal Costanza wrote:
Marshall Spight wrote:
But why should more regression testing mean less static type checking?
Both are useful. Both catch bugs. Why ditch one for the other?
...because static type systems work by reducing the expressive power of
a language. It can't be any different for a strict static type system.
You can't solve the halting problem in a general-purpose language.


What do you mean by "reducing the expressive power of the language"? There
are many general purpose statically typed programming languages that are
Turing complete, so it's not a theoretical consideration, as you allude.


For example, static type systems are incompatible with dynamic
metaprogramming . This is objectively a reduction of expressive power,
because programs that don't allow for dynamic metaprogramming can't be
extended in certain ways at runtime, by definition.
This means that eventually you might need to work around language
restriction s, and this introduces new potential sources for bugs.

(Now you could argue that current sophisticated type systems cover 90%
of all cases and that this is good enough, but then I would ask you for
empirical studies that back this claim. ;)


Empirically, i write a lot of O'Caml code, and i never have to write
something in a non-intuitive manner to work around the type system. On the
contrary, every type error the compiler catches in my code indicates code
that *doesn't make sense*. I'd hate to imagine code that doesn't make
sense passing into regression testing. What if i forget to test a
non-sensical condition?


You need some testing discipline, which is supported well by unit
testing frameworks.
On the flip-side of the coin, i've also written large chunks of Scheme
code, and I *did* find myself making lots of nonsense errors that weren't
caught until run time, which significantly increased development time
and difficulty.

Furthermore, thinking about types during the development process keeps me
honest: i'm much more likely to write code that works if i've spent some
time understanding the problem and the types involved. This sort of
pre-development thinking helps to *eliminate* potential sources for bugs,
not introduce them. Even Scheme advocates encourage this (as in Essentials
of Programming Languages by Friedman, Wand, and Haynes).


Yes, thinking about a problem to understand it better occasionally helps
to write better code. This has nothing to do with static typing. This
could also be achieved by placing some other arbitrary restrictions on
your coding style.
I think soft typing is a good compromise, because it is a mere add-on to
an otherwise dynamically typed language, and it allows programmers to
override the decisions of the static type system when they know better.


When do programmers know better? An int is an int and a string is a
string, and nary the twain shall be treated the same. I would rather
``1 + "bar"'' signal an error at compile time than at run time.


Such code would easily be caught very soon in your unit tests.
Pascal

Jul 18 '05 #83
Pascal Bourguignon wrote:
[...] For example, an architecture like
the Shuttle's where there are five computer differently programmed
would have helped, because at least one of the computers would not
have had the Ariane-4 module.


Even the Ariane team is working under budget constraints. Obviously, in
this case, the budget didn't allow a re-check of the SRI design wrt.
Ariane-5 specifications, much less programming the same software five(!)
times over.

Besides, programming the same software multiple times would have helped
regardless of whether you're doing it with an AI or traditionally. I
still don't see how AI could have helped prevent the Ariane-5 crash. As
far as I have seen, any advances in making chips or programs smarter
have consistently been offset by higher testing efforts: you still have
to formally specify what the system is supposed to do, and then test
against that specification.
Actually, AI wouldn't have helped in the least bit here: the
specification was wrong, so even an AI module, at whatever
sophistication level, wouldn't have worked.

The only difference is that AI might allow people to write higher-level
specifications. I.e. something like "the rocket must be stable" instead
of "the rocket must not deviate more than 12.4 degrees from the
vertical"... but even "the rocket must be stable" would have to be
broken down into much more technical terms, with leeway for much the
same design and specification errors as those that caused the Ariane-5
software to lose control.

Regards,
Jo

Jul 18 '05 #84
Andrew Dalke wrote:
Pascal Costanza:
...because static type systems work by reducing the expressive power of
a language. It can't be any different for a strict static type system.
You can't solve the halting problem in a general-purpose language.

This means that eventually you might need to work around language
restriction s, and this introduces new potential sources for bugs.

Given what I know of embedded systems, I can effectively
guarantee you that all the code on the rocket was proven
to halt in not only a finite amount of time but a fixed amount of
time.


Yes, this is a useful restriction for a certian scenario. I don't have
anything against restrictions put on code, provided these restrictions
are justified.

Static type systems are claimed to generally improve your code. I don't
see that.
Pascal

Jul 18 '05 #85
Pascal Costanza <co******@web.d e> writes:
Marshall Spight wrote:
But why should more regression testing mean less static type checking?
Both are useful. Both catch bugs. Why ditch one for the other?
...because static type systems work by reducing the expressive power of
a language. It can't be any different for a strict static type system.
You can't solve the halting problem in a general-purpose language.


Most modern "statically typed" languages (e.g. Mercury, Glasgow Haskell,
OCaml, C++, Java, C#, etc.) aren't *strictly* statically typed anyway.
They generally have some support for *optional* dynamic typing.

This is IMHO a good trade-off. Most of the time, you want static typing;
it helps in the design process, with documentation, error checking, and
efficiency. Sometimes you need a bit more flexibility than the
static type system allows, and then in those few cases, you can make use
of dynamic typing ("univ" in Mercury, "Dynamic" in ghc,
"System.Obj ect" in C#, etc.). The need to do this is not uncommon
in languages like C# and Java that don't support parametric polymorphism,
but pretty rare in languages that do.
I think soft typing is a good compromise, because it is a mere add-on to
an otherwise dynamically typed language, and it allows programmers to
override the decisions of the static type system when they know better.


Soft typing systems give you dynamic typing unless you explicitly ask
for static typing. That is the wrong default, IMHO. It works much
better to add dynamic typing to a statically typed language than the
other way around.

--
Fergus Henderson <fj*@cs.mu.oz.a u> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Jul 18 '05 #86
Matthias Blume wrote:
Pascal Costanza <co******@web.d e> writes:

...because static type systems work by reducing the expressive power
of a language.

It depends a whole lot on what you consider "expressive ". In my book,
static type systems (at least some of them) work by increasing the
expressive power of the language because they let me express certain
intended invariants in a way that a compiler can check (and enforce!)
statically, thereby expediting the discovery of problems by shortening
the edit-compile-run-debug cycle.


The set of programs that are useful but cannot be checked by a static
type system is by definition bigger than the set of useful programs that
can be statically checked. So dynamically typed languages allow me to
express more useful programs than statically typed languages.
(Now you could argue that current sophisticated type systems cover 90%
of all cases and that this is good enough, but then I would ask you
for empirical studies that back this claim. ;)


In my own experience they seem to cover at least 99%.


I don't question that. If this works well for you, keep it up. ;)
(And where are _your_ empirical studies which show that "working around
language restrictions increases the potential for bugs"?)


I don't need a study for that statement because it's a simple argument:
if the language doesn't allow me to express something in a direct way,
but requires me to write considerably more code then I have considerably
more opportunities for making mistakes.
Pascal

Jul 18 '05 #87
Pascal Costanza wrote:
....because static type systems work by reducing the expressive power of
a language. It can't be any different for a strict static type system.
You can't solve the halting problem in a general-purpose language.
The final statement is correct, but you don't need to solve the halting
problem: it's enough to allow the specification of some easy-to-prove
properties, without hindering the programmer too much.

Most functional languages with a static type system don't require that
the programmer writes down the types, they are inferred from usage. And
the type checker will complain as soon as the usage of some data item is
inconsistent.
IOW if you write
a = b + "asdf"
the type checker will infer that both a and b are strings; however, if
you continue with
c = a + b + 3
it will report a type error because 3 and "adsf" don't have a common
supertype with a "+" operation.

It's the best of both worlds: no fuss with type declarations (which is
one of the less interesting things one spends time with) while getting
good static checking.
(Nothing is as good in practice as it sounds in theory, and type
inference is no exception. Interpreting type error messages requires
some getting used to - just like interpreting syntax error messages is a
bit of an art, leaving one confounded for a while until one "gets it".)
(Now you could argue that current sophisticated type systems cover 90%
of all cases and that this is good enough, but then I would ask you for
empirical studies that back this claim. ;)


My 100% subjective private study reveals not a single complaint about
over-restrictive type systems in comp.lang.funct ional in the last 12 months.

Regards,
Jo

Jul 18 '05 #88
Fergus Henderson wrote:
Pascal Costanza <co******@web.d e> writes:

Marshall Spight wrote:
But why should more regression testing mean less static type checking?
Both are useful. Both catch bugs. Why ditch one for the other?
...because static type systems work by reducing the expressive power of
a language. It can't be any different for a strict static type system.
You can't solve the halting problem in a general-purpose language.

Most modern "statically typed" languages (e.g. Mercury, Glasgow Haskell,
OCaml, C++, Java, C#, etc.) aren't *strictly* statically typed anyway.
They generally have some support for *optional* dynamic typing.

This is IMHO a good trade-off. Most of the time, you want static typing;
it helps in the design process, with documentation, error checking, and
efficiency.


+ Design process: There are clear indications that processes like
extreme programming work better than processes that require some kind of
specification stage. Dynamic typing works better with XP than static
typing because with dynamic typing you can write unit tests without
having the need to immediately write appropriate target code.

+ Documentation: Comments are usually better for handling documentation.
;) If you want your "comments" checked, you can add assertions.

+ Error checking: I can only guess what you mean by this. If you mean
something like Java's checked exceptions, there are clear signs that
this is a very bad feature.

+ Efficiency: As Paul Graham puts it, efficiency comes from profiling.
In order to achieve efficiency, you need to identify the bottle-necks of
your program. No amount of static checks can identify bottle-necks, you
have to actually run the program to determine them.
Sometimes you need a bit more flexibility than the
static type system allows, and then in those few cases, you can make use
of dynamic typing ("univ" in Mercury, "Dynamic" in ghc,
"System.Obj ect" in C#, etc.). The need to do this is not uncommon
in languages like C# and Java that don't support parametric polymorphism,
but pretty rare in languages that do.


I wouldn't count the use of java.lang.Objec t as a case of dynamic
typing. You need to explicitly cast objects of this type to some class
in order to make useful method calls. You only do this to satisfy the
static type system. (BTW, this is one of the sources for potential bugs
that you don't have in a decent dynamically typed language.)
I think soft typing is a good compromise, because it is a mere add-on to
an otherwise dynamically typed language, and it allows programmers to
override the decisions of the static type system when they know better.


Soft typing systems give you dynamic typing unless you explicitly ask
for static typing. That is the wrong default, IMHO. It works much
better to add dynamic typing to a statically typed language than the
other way around.


I don't think so.
Pascal

Jul 18 '05 #89
Joachim Durchholz wrote:
Most functional languages with a static type system don't require that
the programmer writes down the types, they are inferred from usage. And
the type checker will complain as soon as the usage of some data item is
inconsistent.
I know about type inference. The set of programs that can be checked
with type inference is still a subset of all useful programs.
My 100% subjective private study reveals not a single complaint about
over-restrictive type systems in comp.lang.funct ional in the last 12
months.


I am not surprised. :)
Pascal

Jul 18 '05 #90

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

75
4622
by: Xah Lee | last post by:
http://python.org/doc/2.4.1/lib/module-re.html http://python.org/doc/2.4.1/lib/node114.html --------- QUOTE The module defines several functions, constants, and an exception. Some of the functions are simplified versions of the full featured methods for compiled regular expressions. Most non-trivial applications always use the compiled...
6
2365
by: Juha S. | last post by:
Hi, I'm writing a small text editor type application with Python 2.5 and Tkinter. I'm using the Tk text widget for input and output, and the problem is that when I try to save its contents to a .txt file, any Scandinavian letters such as "äöå ÄÖÅ" are saved incorrectly and show up as a mess when I open the .txt file in Windows Notepad. ...
4
2453
by: Berco Beute | last post by:
I wonder what it would take to implement Python in JavaScript so it can run on those fancy new JavaScript VM's such as Chrome's V8 or Firefox' tracemonkey. Much the same as Python implementations in C# (IronPython) and Java (Jython). It would certainly bring back the fun in web application development. Is there anything done in that...
0
1160
by: Luke Kenneth Casson Leighton | last post by:
On Sep 3, 10:02 pm, bearophileH...@lycos.com wrote: 1200 lines of code for the compiler, and about... 800 for a basic suite of builtin types (Dict, List, set, string). http://pyjamas.sf.net so it's been done.
0
7869
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
8151
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
0
8306
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
0
6555
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5677
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
5365
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3806
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
1
2302
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
0
1139
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.