473,599 Members | 3,118 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 21377
Joachim Durchholz <jo************ ***@web.de> writes:
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.


While I tend to agree that such complaints are rare, such complaints also
tend to be language-specific, and thus get posted to language-specific
forums, e.g. the Haskell mailing list, the Clean mailing list, the OCaml
mailing list, etc., rather than to more general forums like
comp.lang.funct ional.

--
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 #91
On Thu, Oct 23, 2003 at 12:38:50AM +0000, 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. 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.


The trouble with these `dynamic' extensions is that they are `dynamic
type systems' from a statically typed viewpoint. A person who uses
truly dynamically typed languages would not consider them to be the
same thing.

In SML, for example, such an extension might be implemented using a sum
type, even using an `exn' type so that it can be extended in separate
places. The moment this system fails (and when a true dynamic system
carries on) is when such a type is redefined. The reason is because the
new type is not considered to be the same as the old type, due to
generativity of type names, and old code requires recompilation.

I'm told Haskell has extensions that will work around even this, but the
last time I tried to play with those, it failed miserably because
Haskell doesn't really support an interactive REPL so there was no way
to test it. (Maybe this was ghc's fault?)

As for Java/C#, downcasting is more of an example of static type systems
getting in the way of OOP rather than of a dynamic type system. (It's
because those languages are the result of an unholy union between the
totally dynamic Smalltalk and the awkwardly static C++).
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 view static typing as an added analysis stage. In that light, it
makes no sense to `add' dynamic typing to it. Also, I think that static
typing should be part of a more comprehensive static analysis phase
which itself is part of a greater suite of tests.

--
; Matthew Danish <md*****@andrew .cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian. org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Jul 18 '05 #92
Pascal Costanza <co******@web.d e> writes:
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.
By whose definition? What *is* your definition of "useful"? It is
clear to me that static typing improves maintainability , scalability,
and helps with the overall design of software. (At least that's my
personal experience, and as others can attest, I do have reasonably
extensive experience either way.)

A 100,000 line program in an untyped language is useless to me if I am
trying to make modifications -- unless it is written in a highly
stylized way which is extensively documented (and which usually means
that you could have captured this style in static types). So under
this definition of "useful" it may very well be that there are fewer
programs which are useful under dynamic typing than there are under
(modern) static typing.
So dynamically typed languages allow
me to express more useful programs than statically typed languages.
There are also programs which I cannot express at all in a purely
dynamically typed language. (By "program" I mean not only the executable
code itself but also the things that I know about this code.)
Those are the programs which are protected against certain bad things
from happening without having to do dynamic tests to that effect
themselves. (Some of these "bad things" are, in fact, not dynamically
testable at all.)
I don't question that. If this works well for you, keep it up. ;)


Don't fear. I will.
(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.


This assumes that there is a monotone function which maps token count
to error-proneness and that the latter depends on nothing else. This
is a highly dubious assumption. In many cases the few extra tokens
you write are exactly the ones that let the compiler verify that your
thinking process was accurate (to the degree that this fact is
captured by types). If you get them wrong *or* if you got the
original code wrong, then the compiler can tell you. Without the
extra tokens, the compiler is helpless in this regard.

To make a (not so far-fetched, btw :) analogy: Consider logical
statements and formal proofs. Making a logical statement is easy and
can be very short. It is also easy to make mistakes without noticing;
after all saying something that is false while still believing it to
be true is extremely easy. Just by looking at the statement it is
also often hard to tell whether the statement is right. In fact,
computers have a hard time with this task, too. Theorem-proving is
hard.
On the other hand, writing down the statement with a formal proof is
impossible to get wrong without anyone noticing because checking the
proof for validity is trivial compared to coming up with it in the
first place. So even though writing the statement with a proof seems
harder, once you have done it and it passes the proof checker you can
rest assured that you got it right. The longer "program" will have fewer
"bugs" on average.

Matthias
Jul 18 '05 #93
Pascal Bourguignon:
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...
But theorem proving and arithmetic are isomorphic. TP-> arithmetic
is obvious. Arithmetic -> TP is through Godel.
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.


Manned space projects get a lot more money for safety checks.
If a few rockets blow up for testing then it's still cheaper than
quintupling the development costs.

Andrew
da***@dalkescie ntific.com
Jul 18 '05 #94
Pascal Costanza:
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.
Ummm, both are infinite and both are countably infinite, so those sets
are the same size. You're falling for Hilbert's Paradox.

Also, while I don't know a proof, I'm pretty sure that type inferencing
can do addition (and theorem proving) so is equal in power to
programming.
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.


The size comparisons I've seen (like the great programming language
shootout) suggest that Ocaml and Scheme require about the same amount
of code to solve small problems. Yet last I saw, Ocaml is strongly typed
at compile time. How do you assume then that strongly&static ally typed
languages require "considerab le more code"?

Andrew
da***@dalkescie ntific.com
Jul 18 '05 #95
"Pascal Costanza" <co******@web.d e> wrote in message news:bn******** **@newsreader2. netcologne.de.. .

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.


Provided you think to write such a test, and expend the effort
to do so. Contrast to what happens in a statically typed language,
where this is done for you automatically.

Unit tests are great; I heartily endorse them. But they *cannot*
do everything that static type checking can do. Likewise,
static type checking *cannot* do everything unit testing
can do.

So again I ask, why is it either/or? Why not both? I've had
*great* success building systems with comprehensive unit
test suites in statically typed languages. The unit tests catch
some bugs, and the static type checking catches other bugs.
Marshall
Jul 18 '05 #96
Joachim Durchholz <jo************ ***@web.de> writes:
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 also read c.l.functional (albeit only lightly). In the last 12
months, I have encountered dozens of complaints about over-restrictive
type sytems in Haskell, OCaml, SML, etc.

The trick is that these complaints are not phrased in precisely that
way. Rather, someone is trying to do some specific task, and has
difficulty arriving at a usable type needed in the task. Often posters
provide good answers--Durchholz included. But the underlying complaint
-really was- about the restrictiveness of the type system.

That's not even to say that the overall advantages of a strong type
system are not worthwhile--even perhaps better than more dynamic
languages. But it's quite disingenuous to claim that no one ever
complains about it. Obviously, no one who finds a strong static type
system unacceptable is going to be committed to using, e.g.
Haskell--the complaint doesn't take the form of "I'm taking my marbles
and going home".

Yours, Lulu...

--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.

Jul 18 '05 #97
Pascal Bourguignon fed this fish to the penguins on Wednesday 22
October 2003 13:44 pm:


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.

Are you sure? What if all the variants reused code from variants of
the A-4... They could all have had different versions of the same
problem...

Merely comparing the A-4 requirements to the A-5 requirements and then
testing the code associated with different performance limits would
also have found the problem...

There isn't much you can do, as a programmer, if the bean counters up
above decree: Use this module -- unchanged -- since it works on the
previous generation... No, you don't need to test it -- we said it
works...

-- =============== =============== =============== =============== == <
wl*****@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
=============== =============== =============== =============== == <
Bestiaria Home Page: http://www.beastie.dm.net/ <
Home Page: http://www.dm.net/~wulfraed/ <


Jul 18 '05 #98
Quoth Lulu of the Lotus-Eaters <me***@gnosis.c x>:
| Joachim Durchholz <jo************ ***@web.de> writes:
|> 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 also read c.l.functional (albeit only lightly). In the last 12
| months, I have encountered dozens of complaints about over-restrictive
| type sytems in Haskell, OCaml, SML, etc.
|
| The trick is that these complaints are not phrased in precisely that
| way. Rather, someone is trying to do some specific task, and has
| difficulty arriving at a usable type needed in the task. Often posters
| provide good answers--Durchholz included. But the underlying complaint
| -really was- about the restrictiveness of the type system.
|
| That's not even to say that the overall advantages of a strong type
| system are not worthwhile--even perhaps better than more dynamic
| languages. But it's quite disingenuous to claim that no one ever
| complains about it. Obviously, no one who finds a strong static type
| system unacceptable is going to be committed to using, e.g.
| Haskell--the complaint doesn't take the form of "I'm taking my marbles
| and going home".

No one said that strict typing is free, requires no effort or learning
from the programmer. That would be ridiculous - of course a type system
is naturally restrictive, that's its nature. A restrictive system that
imposes a constraint on the programmer, who needs to learn about that
in order to use the language effectively. `Over-restrictive' is
different. If there are questions about static typing, it does not
follow that it's over-restrictive, nor that the questions constitute
a complaint to that effect.

Donn Cave, do**@drizzle.co m
Jul 18 '05 #99
"Pascal Costanza" <co******@web.d e> wrote in message news:bn******** **@newsreader2. netcologne.de.. .

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.)


Huh? The explicit-downcast construct present in Java is the
programmer saying to the compiler: "trust me; you can accept
this type of parameter." In a dynamically-typed language, *every*
call is like this! So if this is a source of errors (which I believe it
is) then dynamically-typed languages have this potential source
of errors with every function call, vs. statically-typed languages
which have them only in those few cases where the programmer
explicitly puts them in.
Marshall
Jul 18 '05 #100

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

Similar topics

75
4627
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 form UNQUOTE
6
2367
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. It seems that the characters will only get mixed if the user has typed them into the widget, but if...
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 direction? 2B
0
1162
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
7904
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
8400
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 captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
8051
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
8267
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
6725
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 launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
5438
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 into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
3940
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2414
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
1
1505
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

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.