From: Ben A. <ben...@gm...> - 2008-05-14 15:29:11
|
hi (Disclaimer: I've asked similar questions on the IronPython list but with a bit a different background. Additionaly it would be interesting for me to see how you and the IronPython-team response on these similar question) I have two questions on two different subjects that are anyhow connected. Also I have to admit that I could probably find the answers myself. But I'm quite new to all that things and I have a lot to catch up to... If I understand correctly the are 2 main advantages when it comes to dynamic languages: + Objects doesn't have to be typed be the developer (saves time, makes code shorter and better readable code) + Code is interpreted (no compilation step during development, source dont have to be compiled for the target machines before deployment) which implies the 2 following disadvantages - Writing a lot of tests to catch potential runtime errors (no compile time) - Slower than native code Questions: 1. Why belong the terms "untyped" and "interpreted" somehow together? Why can't the type inference that has to be done at runtime not be done at compiletime. I think the runtime interpreter has to compile the python bytecode to native code somehow - no? Why isn't there a possibility to *compile* python/ruby/perl/... code to native code at the first place? 2. I've read about, that it is possible to compile Python code to a class file with jythonc. Unfortunately I'm not yet at the point where this run on my machine (macosx). So I do have to ask you: Is such a jar the same as I would compile it from java? Does similar language constructs (eg. for loop, class object creation) the same performance? Is it true that the development jythonc is going to be stopped. 3. Could somebody describe me in a few steps how jython work? Does it also generete java source code in the first place? Or does the compiler produce byte-code directly? Thanks in advance. Ben |
From: Michael C. <chi...@mi...> - 2008-05-14 19:40:13
|
Ben Aurel wrote: > hi > (Disclaimer: I've asked similar questions on the IronPython list but > with a bit a different background. Additionaly it would be interesting > for me to see how you and the IronPython-team response on these similar > question) > > I have two questions on two different subjects that are anyhow > connected. Also I have to admit that I could probably find the answers > myself. But I'm quite new to all that things and I have a lot to catch > up to... > > If I understand correctly the are 2 main advantages when it comes to > dynamic languages: > + Objects doesn't have to be typed be the developer > (saves time, makes code shorter and better readable code) > I'll comment just on this point. It is put perhaps too vaguely--I would interpret it as wrong. First, by "dynamic language" you probably mean "dynamically typed language", which does not mean there is no notion of type. Objects to me are values, and values always have type (otherwise, what good are they?). The difference between statically typed and dynamically typed languages is in how type is used. In a statically typed language, both variables and values have type (and if a given variable refers to/contains a particular value, both types typically must be related). In a dynamically typed language, only values have type. The former style allows the compiler to make certain inferences about the code just by "looking", therefore it can find some types of errors for you (this is "static" analysis, i.e. analysis of the code itself, not its runtime behavior). I would not say this necessarily makes code more readable. If by "readable" you mean "understandable", I think the more important consideration is the quality of the code and how well it is documented. There are obfuscated code contests which use C (a statically typed language) to make code that's practically impossible to understand, and a well written, well documented program in a dynamically typed language can be easy to understand. I tend to think code in a dynamically typed language contains handicaps as far as understandability, since variable typing is a form of documentation. E.g. if you want to know what sort of value a function parameter contains in a poorly written program in a dynamically typed language, you might have to trace backward through the code to figure out where the value was constructed, or trace forward to figure out where the value is used... Given that programmers can be very lazy with regards to documentation, and hasty in their designs, if I had to understand someone else's code, I would prefer it were written in a statically typed language. Andy |
From: David H. <dav...@gm...> - 2008-05-14 20:42:47
|
On Wed, May 14, 2008 at 11:34 AM, Michael Chisholm <chi...@mi...> wrote: > a well written, well documented program in a dynamically typed language > can be easy to understand. I tend to think code in a dynamically typed > language contains handicaps as far as understandability, since variable > typing is a form of documentation. E.g. if you want to know what sort > of value a function parameter contains in a poorly written program in a > dynamically typed language, you might have to trace backward through the > code to figure out where the value was constructed, or trace forward to > figure out where the value is used... Documentation does not necessarily solve this. In the following code, imagine that internalWidget is an instance of a class from some large library or framework you are using. You need to do something that you vaguely recall is accomplished through a method on internalWidget, and you need to figure out its type so you can look up the API: ark = this.frobulate() ... blag = Blag(a).proxy() ... conifer = a.flimflam(b).toExternalTree() ... internalWidget = h.getInternal() The fact that frobulate() and Blag and so forth are all precisely documented does not make this a trivial exercise :-) You can even roughly known the role and functionality of every object referenced in the code above without being able to recall the exact types and their APIs. > Given that programmers can be very > lazy with regards to documentation, and hasty in their designs, if I had > to understand someone else's code, I would prefer it were written in a > statically typed language. When prototyping, documentation must be retrospective, or it will hold you back just as much as oppressively verbose static typing does. So, at some point you have to decide that code has stabilized enough to be documented. Unfortunately, I usually realize this when I go to look at some code and realize I haven't touched it for weeks, so I don't remember how it works. I do find that Python code is *much* more readable than Java code for most purposes. Usually the variable and method names will be familiar and/or evocative enough that you can very quickly figure out what a given section of Python code does. 95% of the time, when I look at code like the code I fabricated above, I can get everything I want. It is that last 5% of the time when Python is frustrating. Usually that is when I need to know precise type information because I am making changes in code that has been stable for a long time. I have made a practice of rewriting Python classes in Java when this pain is acute. Sometimes I regret it; sometimes it's a relief. I wish I had a Java editor with a "casual reading" mode that hid all the type declarations and used Python syntax. -David |
From: David H. <dav...@gm...> - 2008-05-14 19:49:32
|
On Wed, May 14, 2008 at 10:28 AM, Ben Aurel <ben...@gm...> wrote: > Questions: > > 1. Why belong the terms "untyped" and "interpreted" somehow together? History. Some Lisp systems contain no interpreter and compile every expression, even those typed in at an interactive prompt. There's no reason Python couldn't be implemented the same way, and that's the way it appears to be heading. Using current technology, it takes much more work to create a compiled dynamic language than it takes to create a working interpreter that is fast enough for many practical purposes. And, of course, the popularity of virtual machines makes it somewhat complicated to decide what is compiled and what is not. Also, a language that is "compiled" might still depend on an elaborate runtime system that is separately compiled and linked and which makes decisions based on inspection of the runtime state of the compiled code. Does such a runtime system count as an interpreter? So, in the end the distinction becomes philosophical, unless you are planning on implementing your own language. If you aren't, my attitude is, why second-guess the strategy of the language implementers? Just tell them if you need it faster, and they will decide how and whether to make it faster for you :-) (If you are planning on implementing your own language, don't bother with this mailing list: jump into some heavy books and start lurking on mailing lists focused on language implementation.) > Why can't the type inference that has to be done at runtime not be done > at compiletime. It can, in the right language -- OCaml and Haskell are examples. One language feature that can kill this idea is untyped function calls across compilation unit boundaries. In Python, for example, I can load a module at the interactive prompt and call functions defined in that module. I can pass any objects I want to those functions, so the types of the arguments to those functions cannot be determined when compiling that module. -David |
From: Petr G. <pet...@gm...> - 2008-05-15 07:41:58
|
On Wed, May 14, 2008 at 10:28 PM, Ben Aurel <ben...@gm...> wrote: > 1. Why belong the terms "untyped" and "interpreted" somehow together? > Why can't the type inference that has to be done at runtime not be done > at compiletime. I think the runtime interpreter has to compile the > python bytecode to native code somehow - no? PyPy project heads toward high quality universal Python compiler. And it already does type inference to the extent Python allows it. -- Petr Gladkikh |
From: Matej C. <mc...@re...> - 2008-05-17 11:26:20
|
On Wed, 14 May 2008 14:49:29 -0500, David Huebel scripst: >> 1. Why belong the terms "untyped" and "interpreted" somehow together? > > History. Some Lisp systems contain no interpreter and compile every > expression, even those typed in at an interactive prompt. Note, that there *ARE* even C-language interpreters available -- not that anybyody would use them (or they are not complete), because who wants interpreter for the assembler preprocessor ;-), but they do exist. Matej -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ |