Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 01/-10/-28163 02:59 PM, Octavian Rasnita wrote: From: geremy condradebat...@gmail.com On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnitaorasn...@gmail.com wrote: snip Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? Octavian The iron law of cryptography: there is no cryptographic solution to a problem in which the attacker and intended recipient are the same person. Schemes like this are at most an annoyance to people willing to reverse engineer your code. Geremy Condra I don't know how the Python bytecode works... how it is executed. I thought that Python parses the .py file and generates the bytecode that doesn't contain all the necessary information for re-creating the source code. (But that I agree, that might mean real compilation which is not the case...) Octavian It's not hard to experiment with. I've written disassemblers for other byte-code formats, but not for Python's. The following is pasted together, so it may not be completely correct. But it's close. Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. def test(arg1, arg2): ... if arg1 65: ... print arg2 ... import dis dis.dis(test) 2 0 LOAD_FAST0 (arg1) 3 LOAD_CONST 1 (65) 6 COMPARE_OP 0 () 9 JUMP_IF_FALSE9 (to 21) 12 POP_TOP 3 13 LOAD_FAST1 (arg2) 16 PRINT_ITEM 17 PRINT_NEWLINE 18 JUMP_FORWARD 1 (to 22) 21 POP_TOP 22 LOAD_CONST 0 (None) 25 RETURN_VALUE Now, there are tools which reverse that into something pretty similar to python source. But you can see even from the built-in features that lots of information is there. I'd assume that something very similar is in the byte code files themselves. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Octavian Rasnita, 19.01.2011 07:10: aren't the Pyton bytecode-compiled files considered secure enough? Can they be easily decompiled? Yes. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
From: Stefan Behnel stefan...@behnel.de Octavian Rasnita, 19.01.2011 07:10: aren't the Pyton bytecode-compiled files considered secure enough? Can they be easily decompiled? Yes. Stefan Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Octavian Rasnita, 19.01.2011 11:31: From: Stefan Behnel Octavian Rasnita, 19.01.2011 07:10: aren't the Pyton bytecode-compiled files considered secure enough? Can they be easily decompiled? Yes. FYI, just take a look at the 'dis' module. There are also decompilers available. IIRC, one is called decompyle. Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? You can use an import hook to do anything you like. That includes decrypting a file and extracting a normal .pyc from it that can then be imported. However, that won't prevent users from inspecting the code at runtime if they get a handle at it (which they likely will if they try). Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita orasn...@gmail.com wrote: From: Stefan Behnel stefan...@behnel.de Octavian Rasnita, 19.01.2011 07:10: aren't the Pyton bytecode-compiled files considered secure enough? Can they be easily decompiled? Yes. Stefan Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? Octavian The iron law of cryptography: there is no cryptographic solution to a problem in which the attacker and intended recipient are the same person. Schemes like this are at most an annoyance to people willing to reverse engineer your code. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-19, geremy condra debat...@gmail.com wrote: On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita orasn...@gmail.com wrote: Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? The iron law of cryptography: there is no cryptographic solution to a problem in which the attacker and intended recipient are the same person. Schemes like this are at most an annoyance to people willing to reverse engineer your code. And they somehow usually end up being an annoyance to customers who are not trying to reverse engineer your code but are merely trying to use it legally. -- Grant Edwards grant.b.edwardsYow! I'd like MY data-base at JULIENNED and stir-fried! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 20 January 2011 06:16, Grant Edwards invalid@invalid.invalid wrote: On 2011-01-19, geremy condra debat...@gmail.com wrote: On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita orasn...@gmail.com wrote: Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? The iron law of cryptography: there is no cryptographic solution to a problem in which the attacker and intended recipient are the same person. Schemes like this are at most an annoyance to people willing to reverse engineer your code. And they somehow usually end up being an annoyance to customers who are not trying to reverse engineer your code but are merely trying to use it legally. Absolutely. If you feel you absolutely *must* obfuscate your object code more than the python bytecode, just put it all into a separate module and compile it with Cython http://cython.org/. Then you end up with machine-specific object code which is somewhat harder to reverse engineer for most people (but quite a few people are experts at doing so). As a bonus, Cython might speed it up too. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
From: geremy condra debat...@gmail.com On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita orasn...@gmail.com wrote: From: Stefan Behnel stefan...@behnel.de Octavian Rasnita, 19.01.2011 07:10: aren't the Pyton bytecode-compiled files considered secure enough? Can they be easily decompiled? Yes. Stefan Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? Octavian The iron law of cryptography: there is no cryptographic solution to a problem in which the attacker and intended recipient are the same person. Schemes like this are at most an annoyance to people willing to reverse engineer your code. Geremy Condra I don't know how the Python bytecode works... how it is executed. I thought that Python parses the .py file and generates the bytecode that doesn't contain all the necessary information for re-creating the source code. (But that I agree, that might mean real compilation which is not the case...) Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Tim Harig, 18.01.2011 12:37: On 2011-01-18, Stefan Behnel wrote: Tim Harig, 17.01.2011 20:41: I prefer a single language as opposed to a creolization of two. With the possible exception of Lisp, I find it hard to think of a language that's still alive and not the creolisation of (at least) two other languages. They all inherited from each other, sometimes right from the start (lessons learned) and always during their subsequent life time. I am not talking about language influences. Cython effectively requires two separate languages that interoperate. The end result is a mix of two code written in two separate langauges. That is not a single language solution. I don't really agree with the word separate, and especially not two codes. I think of Cython more as Python with the addition of C data types, integrated by a smart compiler. So the language actually is Python, it's just that you can apply it to a broader set of data representations. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Mon, 17 Jan 2011 19:41:54 +, Tim Harig wrote: One of the arguments for Python has always made is that you can optimize it by writing the most important parts in C. Perhaps that is a crutch that has held the communty back from seeking higher performance solutions in the language itself. Are you aware of PyPy? Yes I have heard of PyPy, RPython, and Cython. If they were sufficient I probably wouldn't have to look around. These alternate Python projects have made some small gains; but, they still have a long way to go. PyPy is now about double the speed of CPython for most things, and they have set themselves the ambitious target of being faster than C. Let me know when they reach that target. When Java started there was hype that the JIT would be able to run faster then native C because the JIT could optimize at runtime based on the actual data that it encountered. That never really panned out either. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, Stefan Behnel stefan...@behnel.de wrote: Tim Harig, 17.01.2011 20:41: One of the arguments for Python has always made is that you can optimize it by writing the most important parts in C. Perhaps that is a crutch that has held the communty back from seeking higher performance solutions in the language itself. The good news with Cython is that you no longer need to write the most important parts in C. Instead, you type them statically and compile them. You don't even need to sacrifice Python source compatibility for that. So you get the best of Python at the speed of C (or 'c', as some would say ;). Well not quite. The fact that you still need a Python interpeter should tell you that the end result is not really just C. Effectively, you get the same thing that you might get from writing C modules for your performance sensitive loops. Cython just makes it a little easier to generate the C modules; but, there is still a lot of Python operating under the hood. I prefer a single language as opposed to a creolization of two. With the possible exception of Lisp, I find it hard to think of a language that's still alive and not the creolisation of (at least) two other languages. They all inherited from each other, sometimes right from the start (lessons learned) and always during their subsequent life time. I am not talking about language influences. Cython effectively requires two separate languages that interoperate. The end result is a mix of two code written in two separate langauges. That is not a single language solution. I certainly don't need to require anybody who wants to use a program I have compiled to install an interpreter. You will be happy to hear that you can link Cython programs against libpython (even statically) to build an executable that embeds the interpreter for you. Besides, on most operating systems, installing a Which means that you effectively end up with a py2exe style frozen binary. While that is a nice hack for solving some problems, it is hardly an elegant solution. It still effectively means that I have to package a redundant Python installation with every binary that I distribute. I just don't have to write installation routines that check for, and potentially install, a compatable version of Python. interpreter for you. Besides, on most operating systems, installing a dependency is done automatically, and Go code doesn't run natively on Windows either, without first installing and running the compiler over it. Go works like C. If I compile my code on Windows, then I can give the binary to another Windows user and they can execute it without having to install any additional software (gcgo currently compiles everything using static binaries. Since the linker only includes the fuctions you actually use, you don't end up with the bloat of embedding entire libraries. I am not sure about gccgo.). The same holds true for Linux, BSD, OS X, and any other supported OS. Every go program includes a runtime componet that provides the garbage collection; but, all of that is included as 100% processor native code. That is quite a bit different from having to include an interpreter to run non-native code. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Tim Harig wrote: You still don't see many companies doing large scale internal development using Python and you definately don't see any doing external developement using a language that gives the customers full access to the source code. What you refered as full access to the source code only goes as far as the license which was imposed by the copyright holders lets it to go. If you distribute the source code along with the binaries but you only license your code if the licencees accept that they may look at the source code but they can't touch it then distributing the source code is essentially meaningless. There is a good reason why open source software is not the same thing as free software. Rui Maciel -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, Rui Maciel rui.mac...@gmail.com wrote: Tim Harig wrote: You still don't see many companies doing large scale internal development using Python and you definately don't see any doing external developement using a language that gives the customers full access to the source code. What you refered as full access to the source code only goes as far as the license which was imposed by the copyright holders lets it to go. If you distribute the source code along with the binaries but you only license your code if the licencees accept that they may look at the source code but they can't touch it then distributing the source code is essentially meaningless. There is a good reason why open source software is not the same thing as free software. That argument is not going to fly with where commericial interests are concerned. The simple fact is that there is legality and then there is reality. People follow licenses like they follow the speed limit: only when they think they might get caught and punished. When people break the licenses, the only recourse is litigation; which is expensive. Even finding and proving license violations is difficult where source is availible. It is therefore in the corporate interest to make breaking licenses as difficult, uneconomical, and tracible as possible; and that is exactly what companies do. Even companies that don't really have any trade secrets to protect are protective about their source keeping it locked out of public view. Access to the source generally means signing an NDA so that if the source is somehow leaked, they know the most likely candidates for the origin [so as not to pun with source] of the leak. Whether or not you actually agree with that economic reality is irrelevant. Those who fund commerical projects do; and, any developement tool which violates the security of the source is going to find itself climbing an uphill battle in trying to gain market penetration with commericial software producers. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Mon, Jan 17, 2011 at 4:02 PM, Tim Harig user...@ilthio.net wrote:
Go is not an ideal language for high-performance code. Despite the
occasional claims of others, Go is consistently outperformed by C,
C++, and Java on a wide variety of benchmarks. Some claim that Ada and
Haskell do as well, and my benchmarks (CPU bound, focused on speed of
I much agree that Go doesn't beat C or C++. I really doubt that it could
with the runtime necessary to do garbage collction. Nevertheless, I find
that Go can be optimized to perform within tolerable limits of C given the
boost it gives in development.
The question isn't whether you will use it; right or wrong, it seems
certain that you will. The question is whether it will see significant
uptake, and this is a big barrier for many.
I really question that you get Java anywhere even close to C performance.
Google reports they get within the same order of magnitude as C for
their long-lived server processes where the JIT has had time to optimize
its results. For shorter term processes such as desktop applications,
Java performance stinks -- even after you discount the JVM starup time.
I'm sorry, but you're wrong on this. Java's performance can be
excellent, particularly when it comes to mathematical functions. I
recall reading a pretty smug paper a few years ago describing how they
managed to beat C on a number of numerical benchmarks.
Ada is capable of C++ like performance *if* you compile it to remove *all*
of runtime checking. Depending what checks you enable, it can run much
slower.
No idea, never used it.
in line with the work of others. You can argue that it's good enough-
it is, for most cases- but taking a 20% performance hit rules it out
of a lot of systems work, and the C-Go gap in many cases is much
larger than that.
I don't work anything that involves and absolute need for performance.
Then don't argue about performance, it makes you look like a hack just
eager to shill for your language.
I could probably accept penalty several times that of C for higher
level functionality; but, sometimes the penalty for Python is just
too much. Many of my programs are very quick lived such that even
loading an interpeter or VM can eclipse the actual runtime. Given less
developmental effort required, I also find that I have more time to look
for ways to optimize Go. There are many things (such as using alternate
data structures rather then the build in slices and immutable strings)
that can be used to accelerate Go when time permits and I suspect many
more will be found as the language matures.
This is inconsistent with your argument about PyPy. See my earlier comment.
Go is also not an ideal language for enterprise development. It
provides no compatibility or support guarantees; in fact, the website
describes it as 'an experiment' and recommends it for 'adventurous
There is no doubt that it is a young project and there are a number of
things that will need to be improved to be effective for some branches
of programming; but, that isn't a language restriction.
It will nevertheless preclude its use in most enterprise software
development. That's most systems software.
Frankly, I am
rather impressed by the sheer number of third party packages that have
already become available. No go isn't going to replace some of the other
top mainstream langauges today; but, I can easily see it starting to see
some market penetration 5 years from now.
I suppose that for some small value of market penetration ('mom uses
it!') you're right. I don't see any evidence of major movement at this
moment though.
users'. There are no independent experts in case something goes wrong,
and if it goes belly up a year from now you will have a one year old
piece of legacy infrastructure on your hands. Maybe you don't think
that this will be the case; in any event, I would not want to try
convincing a CFO of that.
If I was trying to convince a CFO, I would ask if he really thought Google
was likely to simply drop the time and effort that Google has already
placed into the infrastructure.
Hahahaha. You mean like wave?
Furthermore, few dying languages already
have not one, but two, open source compilers available for use.
Two compilers by the same people. Not two active projects. Big difference.
Database bindings are another weak link outside of the more common
open source databases. In both cases, Go readily capable of C library
functions as a stop-gap until a native wrapper is available. Yes it will
be nice once community has filled in the gaps; but, I am rather impressed
at what is already available in less then a years time. There are a few
libraries you may have missed here:
Sounds like a two-language solution, ie, the thing you criticized Python for.
I will point out that Go's libraries are miles ahead of the standard C
library and other minimalistic standard libraries. Many things are
possible with even the
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 1/18/2011 10:30 AM, Tim Harig wrote: Whether or not you actually agree with that economic reality is irrelevant. Those who fund commerical projects do; and, any developement tool which violates the security of the source is going to find itself climbing an uphill battle in trying to gain market penetration with commericial software producers. Of course. When I submit or commit patches, I am doing it mostly for hobby, educational, and scientific users, and maybe website makers (who make site I can visit). If commercial users piggyback on top, ok. I do not know how many developers, if any, are after such market penetration. Shedskin compiles a slowly growing subset of Python to native code. But I do not know that it has gotten any commercial support. Maybe Mark should sell it instead of giving it away for commercial use (if he does now). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, geremy condra debat...@gmail.com wrote: On Mon, Jan 17, 2011 at 4:02 PM, Tim Harig user...@ilthio.net wrote: I really question that you get Java anywhere even close to C performance. Google reports they get within the same order of magnitude as C for their long-lived server processes where the JIT has had time to optimize its results. For shorter term processes such as desktop applications, Java performance stinks -- even after you discount the JVM starup time. I'm sorry, but you're wrong on this. Java's performance can be excellent, particularly when it comes to mathematical functions. I recall reading a pretty smug paper a few years ago describing how they managed to beat C on a number of numerical benchmarks. I have no doubt that Java *can* occasionally beat *some* C for *some* benchmarks; but, overall, Java has a terrible reputation for performance. I worked with a company a few years ago that tried replacing a C VNC client with a Java one so that its technical support contractor's wouldn't need to have the VNC client installed on the agent's workstations. Several of the contracters had to upgrade their systems in order to use the Java version because it slowed down the machines so much that the agents could not perform their jobs effectively; and that is pretty typical from what I have seen with Java overall. Java performs very well with some select tasks. For others, it does exceedingly poor. That kind of hit or miss is pretty typical for JIT compilers in general. That isn't usually the case for fully compiled langauges where you are pretty much guaranteed to get decent, if not always the absolute top, performance. Ada is capable of C++ like performance *if* you compile it to remove *all* of runtime checking. Depending what checks you enable, it can run much slower. No idea, never used it. in line with the work of others. You can argue that it's good enough- it is, for most cases- but taking a 20% performance hit rules it out of a lot of systems work, and the C-Go gap in many cases is much larger than that. I don't work anything that involves and absolute need for performance. Then don't argue about performance, it makes you look like a hack just eager to shill for your language. What you don't seem to realize is there is often a performance level that is good enough. For many things, Python is good enough. Many others, where Python is insufficient, may still be acceptable to use Java. Some things require the absolute best performance and will probably always need C/C++ or equivilantly low level language. I could probably accept penalty several times that of C for higher level functionality; but, sometimes the penalty for Python is just too much. Many of my programs are very quick lived such that even loading an interpeter or VM can eclipse the actual runtime. Given less developmental effort required, I also find that I have more time to look for ways to optimize Go. There are many things (such as using alternate data structures rather then the build in slices and immutable strings) that can be used to accelerate Go when time permits and I suspect many more will be found as the language matures. This is inconsistent with your argument about PyPy. See my earlier comment. I can accept 2 to 3 times the overall performance of C for almost all of the problems that I deal with. When that multiple gets into the double digits, it can start to cause some real headaches for some problems. When that number reaches the upper double digits, it is acceptable for even fewer problems. Python is great for those problems where performance isn't critical and I make extensive use of it. Different methods of mixing Python and C (including manual, PyPy, SWIG, boost, etc) can extend Python's useful range; but, I have not seen the kind of speed improvements that bring it to less then an order of magnitude of C's speed overall. Even assuming that PyPy does actually manage to reach within a magnitude of C with the extra effort required to leverage two languages, why would I bother when I can do it with one? PyPy and similar methods where great when there was no other mid level alternative that supported Python like features. Now it just seems like using Python as a hammer for every problem whether or not it is the right tool for the job. Go is also not an ideal language for enterprise development. It provides no compatibility or support guarantees; in fact, the website describes it as 'an experiment' and recommends it for 'adventurous There is no doubt that it is a young project and there are a number of things that will need to be improved to be effective for some branches of programming; but, that isn't a language restriction. It will nevertheless preclude its use in most enterprise software development. That's most systems software. So you conclude that because it is not quite ready for prime time yet that it never will be? I can
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Tue, Jan 18, 2011 at 11:05 AM, Tim Harig user...@ilthio.net wrote: Even assuming that PyPy does actually manage to reach within a magnitude of C with the extra effort required to leverage two languages, why would I bother when I can do it with one? PyPy and similar methods where great when there was no other mid level alternative that supported Python like features. Now it just seems like using Python as a hammer for every problem whether or not it is the right tool for the job. You clearly have no idea what you're talking about regarding PyPy. You could at least have googled it before speaking about it. Go is also not an ideal language for enterprise development. It provides no compatibility or support guarantees; in fact, the website describes it as 'an experiment' and recommends it for 'adventurous There is no doubt that it is a young project and there are a number of things that will need to be improved to be effective for some branches of programming; but, that isn't a language restriction. It will nevertheless preclude its use in most enterprise software development. That's most systems software. So you conclude that because it is not quite ready for prime time yet that it never will be? I can remember when people said C++ would never amount to anything either. We're a year past the initial announcement that it was ready. It's still 'an experiment'. It doesn't have a ratified standard, committee, or governing body. The company that developed it seems to have no interest in enterprise support. They haven't done any serious marketing for it since the initial release. Five years is, to put it mildly, an overly enthusiastic timeline for the development of broad-based industry support under those conditions. Database bindings are another weak link outside of the more common open source databases. In both cases, Go readily capable of C library functions as a stop-gap until a native wrapper is available. Yes it will be nice once community has filled in the gaps; but, I am rather impressed at what is already available in less then a years time. There are a few libraries you may have missed here: Sounds like a two-language solution, ie, the thing you criticized Python for. Not quite. 1. My arguments for dual language solutions where never directed at Python proper. They were directed at PyPy. I am rather amazed at the number of things that can be accomplished in Python without having to bind to C. Again, you don't know what you're talking about WRT PyPy. 2. There is a difference in binding to a solution that is already written in another language so as to not reinvent a wheel and implementing a *new* library in another language to be used exclusively with Python. Even if that binding is done for performance reasons? Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, Terry Reedy tjre...@udel.edu wrote: On 1/18/2011 10:30 AM, Tim Harig wrote: Whether or not you actually agree with that economic reality is irrelevant. Those who fund commerical projects do; and, any developement tool which violates the security of the source is going to find itself climbing an uphill battle in trying to gain market penetration with commericial software producers. Of course. When I submit or commit patches, I am doing it mostly for hobby, educational, and scientific users, and maybe website makers (who make site I can visit). If commercial users piggyback on top, ok. I do not know how many developers, if any, are after such market penetration. You kind of over-extended the intentions of my comment. It does not apply to open source software in general. I agree that open source authors are not interested in the quantitative value of market penetration. However, I am betting that most authors of developement tools would like to be able to use their tools on the job. I am sure that more software developers would love to develop using Python as part of their job. For some this is a reality; but, many more are stuck using their employer's choice of language. One of the factors that employers consider, when they choose a language, if they produce retail software is that the process of compiling will sufficiently obfiscate their code. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, geremy condra debat...@gmail.com wrote: On Tue, Jan 18, 2011 at 11:05 AM, Tim Harig user...@ilthio.net wrote: Even assuming that PyPy does actually manage to reach within a magnitude of C with the extra effort required to leverage two languages, why would I bother when I can do it with one? PyPy and similar methods where great when there was no other mid level alternative that supported Python like features. Now it just seems like using Python as a hammer for every problem whether or not it is the right tool for the job. You clearly have no idea what you're talking about regarding PyPy. You could at least have googled it before speaking about it. No, I have watched several such projects over the years. Pysco, Unladen Swallow, Cython, PyPy, Shedskin, etc. Source to source translators, JITs, and C language integration all just add to complexity. You can't do this, you can't do that, you have to learn a new way of doing something else, ad nauseum. So when something new that provided Python like capabilities without many of Python's drawbacks came along, I jumped on it. It provides a much cleaner solution to the problem without kludges. I will use Python for what it does well and cleanly. For the rest, there are now better tools. Once again, its about the right tool for the right job. Again, you don't know what you're talking about WRT PyPy. Nor do I really want to. I have found a much simpler solution to the problem. I would recommend it to many others that like the Python language but who occassionaly struggle with its implementation constraints. I would say that I am sorry that it doesn't work for you; but, you seem to prefer Java and Pypy anyway so we are both happy. 2. There is a difference in binding to a solution that is already written in another language so as to not reinvent a wheel and implementing a *new* library in another language to be used exclusively with Python. Even if that binding is done for performance reasons? Yep, that is pretty much the summation of my dual language argument. I don't expect a pure Python implementation of curses since there is a perfectly good C library available to bind to. Why reinvent the wheel. Resorting to writing packages in another language or compiling Python code into another source language is a kludge necessary because of the performance characteristics of the language. I suppose that is an acceptable kludge when that is your only alternative. For me it no longer is. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Cobra seems to similar to python. Or it at least compares itself to python. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Anyone have thoughts on Cobra? On Jan 18, 2011 4:20 PM, Zach taylo...@gmail.com wrote: Cobra seems to similar to python. Or it at least compares itself to python. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
From: Tim Harig user...@ilthio.net On 2011-01-18, Terry Reedy tjre...@udel.edu wrote: On 1/18/2011 10:30 AM, Tim Harig wrote: Whether or not you actually agree with that economic reality is irrelevant. Those who fund commerical projects do; and, any developement tool which violates the security of the source is going to find itself climbing an uphill battle in trying to gain market penetration with commericial software producers. Of course. When I submit or commit patches, I am doing it mostly for hobby, educational, and scientific users, and maybe website makers (who make site I can visit). If commercial users piggyback on top, ok. I do not know how many developers, if any, are after such market penetration. You kind of over-extended the intentions of my comment. It does not apply to open source software in general. I agree that open source authors are not interested in the quantitative value of market penetration. However, I am betting that most authors of developement tools would like to be able to use their tools on the job. I am sure that more software developers would love to develop using Python as part of their job. For some this is a reality; but, many more are stuck using their employer's choice of language. One of the factors that employers consider, when they choose a language, if they produce retail software is that the process of compiling will sufficiently obfiscate their code. -- True. But aren't the Pyton bytecode-compiled files considered secure enough? Can they be easily decompiled? Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-16, geremy condra debat...@gmail.com wrote: On Sun, Jan 16, 2011 at 3:03 AM, Tim Harig user...@ilthio.net wrote: On 2011-01-16, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If the author thinks that Go is a tried and true (his words, not mine) language where programmers can go to look for work, I think he's fooling himself. No I wouldn't say that it has reached market penetration yet; but, it has more momentum then any language I am familiar with. I wouldn't be at all surprised to see it becoming quite common in the next five years. I would be very surprised if this were the case. As you point out, languages typically have very long incubation times before they reach any kind of serious market penetration. This seems doubly true for a relatively narrowly targeted language that is in many ways on the wrong side of history. I wouldn't say Go is narrowly targeted. It's a systems language that can compete in the same domain with scripting languages. It is true that most languages have long incubation periods; but, corporate support can change that quite a bit. C#, being backed by Microsoft, managed to go mainstream pretty quickly. How long has it taken Python to reach its present level of market penetration? And, I still don't see a huge amount of professional Python use outside of web developement. Go has only been public for less then a year. Python's very widely used for scripting and related tasks, and has a pretty big user base in academia and the sciences. Python has been widely used by people like us that happen to like the language and found ways to use it in our workplaces; but, most of the time it is an unofficial use that the company. You still don't see many companies doing large scale internal development using Python and you definately don't see any doing external developement using a language that gives the customers full access to the source code. Personally, I think the time is ripe for a language that bridges the gap between ease of use dynamic languages with the performance and distribution capabilities of a full systems level language. I agree. That does not make Go that language, and many of the choices made during Go's development indicate that they don't think it's that language either. I'm speaking specifically of its non-object model, lack of exceptions, etc. 1. Go has an object model. What it lacks is an object hierarchy where all object are decended from a single root object since it does not support object inheritance as it is used in most languages. In Go we simply adapt an object to meet the needs of the newer object by adding whatever new functionality is needed. 2. Go has a similar mechanism to exceptions, defer/panic/recover. It does downplay This is after all the promise the VM based languages made but never really fulfilled. It is also high time for a fully concurrent language fully capable of taking advantage of multicore processors without having to deal with the inherent dangers of threading. There are several good choices available for both a even a few that fit both bills; but, few of them have the support of a company like Google that is capable of the push required to move the language into the mainstream. You might be right, but I doubt we'll know one way or the other in the next 5 years. Personally, I'm hoping that functional language use continues to grow. I personally doubt that purely functional languages will ever make it mainstream. Functional programming has been around for a long time and never really ever managed to break out of academic research. The current interest in functional programming stems merely because some announced that it would be *the* way to utilize multicore computers. Having looked into the space somewhat, there is more hype then substantiation for purely functional concepts. What the hype did do was return attention to SCP style concurrency using actors and MPI and I think that will be the direction taken for concurrent programming into the future. I believe functional programming will make an impact in the mainstream in the form of functionally enabled multiparadigm but not purely functional languages. I think you will see code that uses more functional concepts as guidelines to better code. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Mon, 17 Jan 2011 09:12:04 +, Tim Harig wrote: Python has been widely used by people like us that happen to like the language and found ways to use it in our workplaces; but, most of the time it is an unofficial use that the company. You still don't see many companies doing large scale internal development using Python and you definately don't see any doing external developement using a language that gives the customers full access to the source code. Careful with the FUD there *wink* http://www.python.org/about/quotes/ Sometimes giving access to the source code is a feature, not a bug. Just ask Red Hat. And for those who think otherwise, you can always ship the .pyc files alone. Or turn your software into a web-app. In any case, most companies, and individuals, follow the crowd. They do what everybody else does. There are good reasons for this, as well as bad reasons, but the end result is that most companies' software development is, quite frankly, crap, using the wrong language and the wrong methodology for the wrong reasons. If you doubt this, then perhaps you would like to explain why most software projects fail and those that don't rarely come in on time or on budget? It would probably be crap regardless of what language they used (Sturgeon's Law), but there are degrees of crap. Being optimized for rapid development, at least with Python the average company will develop their crap software five times as quickly and at a third the cost than if they had chosen C++ or Java. You should also consider Paul Graham's essay: http://www.paulgraham.com/avg.html He's hot for Lisp, which is fine, but the lessons hold for Python too. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Mon, Jan 17, 2011 at 1:12 AM, Tim Harig user...@ilthio.net wrote: On 2011-01-16, geremy condra debat...@gmail.com wrote: On Sun, Jan 16, 2011 at 3:03 AM, Tim Harig user...@ilthio.net wrote: snip Personally, I think the time is ripe for a language that bridges the gap between ease of use dynamic languages with the performance and distribution capabilities of a full systems level language. I agree. That does not make Go that language, and many of the choices made during Go's development indicate that they don't think it's that language either. I'm speaking specifically of its non-object model, lack of exceptions, etc. snip 2. Go has a similar mechanism to exceptions, defer/panic/recover. It does downplay Downplay what exactly? Seems your paragraph got truncated. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-17, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Mon, 17 Jan 2011 09:12:04 +, Tim Harig wrote: Python has been widely used by people like us that happen to like the language and found ways to use it in our workplaces; but, most of the time it is an unofficial use that the company. You still don't see many companies doing large scale internal development using Python and you definately don't see any doing external developement using a language that gives the customers full access to the source code. Careful with the FUD there *wink* This isn't FUD, I am as enthusiastic about Python as anybody here; but, I also have to be realistic about its actual impact in the industry. http://www.python.org/about/quotes/ There are always success stories; although, many of those are web based companies which, if you will look up the thread, I already excuded from the conversation. However from my experience, a small percentage of people make their primary income from writing non-web based Python software. It certainly hasn't displaced, or even encroached on the primary langauge leaders. Sometimes giving access to the source code is a feature, not a bug. Just ask Red Hat. And for those who think otherwise, you can always ship the .pyc files alone. Or turn your software into a web-app. Red Hat is the big example; but, few other companies actually make substantial profits from FOSS. I am not interested in an idealogy debate about whether exposing your source is good or bad; the fact is that those who fund software developement have a strong preference to choosing closed source. Any software that doesn't provide good methods for closed sourced software is going to suffer. 1. Distributing .pyc files still requires the user to have a Python interpreter. 2. My understanding is that Python bytecode is not guaranteed to be compatible between releases? 3. I have already excluded web apps where Python has a large market penetration (were most of the dynamic languages have found their niche). My point pertains to those areas where Python cannot, or doesn't, compete well with systems level languages and that even for its web niche, it didn't arrive here overnight. There was a long period where it was less likely the Perl to be used for server side web scripting. You can see the recent thread about a web based IDE for what I think about many web applications. In any case, most companies, and individuals, follow the crowd. They do what everybody else does. There are good reasons for this, as well as bad reasons, but the end result is that most companies' software development is, quite frankly, crap, using the wrong language and the wrong methodology for the wrong reasons. If you doubt this, then perhaps you People funding software developement really don't care about the quality of the software. They care how much money it will make them. If you really think quality matters, then look at Microsoft's meteoric rise to dominance. Early Microsoft was not known for its superior quality. Only in the last ten years, since they have had to contend with a really poor reputation and competition from their own products have they started to be conserned with writing better software. methodology for the wrong reasons. If you doubt this, then perhaps you would like to explain why most software projects fail and those that don't rarely come in on time or on budget? Yes, lots of projects fail; but, the choice of language is seldom the primary, or even a major contributing reason, for the failure. Python holds the distinction of having had a book written about one such failed project. It would probably be crap regardless of what language they used (Sturgeon's Law), but there are degrees of crap. Being optimized for rapid development, at least with Python the average company will develop their crap software five times as quickly and at a third the cost than if they had chosen C++ or Java. If I didn't think Python was a good language, I wouldn't be here. Nevertheless, it isn't a good fit for many pieces of software where a systems language is better suited. Reasons include ease of distribution without an interpeter, non-necessity of distributing source with the product, ability to leverage multiple CPU and multicore systems, and simple sequential performance. Given that Python does't work well in many areas, we could just give up and accept having to write C++ for our day jobs or we can look for a language which bridges the gap between those tasks that require C++'s level of control and those which work well for dynamic languages. Java attempted to do that, and has the market share to show that the concept works, but I think that it missed the mark for many needs. It is still much lower level then Python for purposes of rapid developement and too slow to be competative for non-long-lived
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-17, Chris Rebert c...@rebertia.com wrote: On Mon, Jan 17, 2011 at 1:12 AM, Tim Harig user...@ilthio.net wrote: On 2011-01-16, geremy condra debat...@gmail.com wrote: On Sun, Jan 16, 2011 at 3:03 AM, Tim Harig user...@ilthio.net wrote: snip Personally, I think the time is ripe for a language that bridges the gap between ease of use dynamic languages with the performance and distribution capabilities of a full systems level language. I agree. That does not make Go that language, and many of the choices made during Go's development indicate that they don't think it's that language either. I'm speaking specifically of its non-object model, lack of exceptions, etc. snip 2. Go has a similar mechanism to exceptions, defer/panic/recover. It does downplay there use for less exceptional conditions in favor of function return values; however, there is nothing preventing you from using them as you see fit to do so. Downplay what exactly? Seems your paragraph got truncated. Sorry. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Tim Harig, 17.01.2011 13:25: If I didn't think Python was a good language, I wouldn't be here. Nevertheless, it isn't a good fit for many pieces of software where a systems language is better suited. Reasons include ease of distribution without an interpeter, non-necessity of distributing source with the product, ability to leverage multiple CPU and multicore systems, and simple sequential performance. Given that Python does't work well in many areas, we could just give up and accept having to write C++ for our day jobs or we can look for a language which bridges the gap between those tasks that require C++'s level of control and those which work well for dynamic languages. Java attempted to do that, and has the market share to show that the concept works, but I think that it missed the mark for many needs. It is still much lower level then Python for purposes of rapid developement and too slow to be competative for non-long-lived tasks. So seriously need to take a look at Cython. http://cython.org Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Mon, Jan 17, 2011 at 1:12 AM, Tim Harig user...@ilthio.net wrote:
On 2011-01-16, geremy condra debat...@gmail.com wrote:
On Sun, Jan 16, 2011 at 3:03 AM, Tim Harig user...@ilthio.net wrote:
On 2011-01-16, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
If the author thinks that Go is a tried and true (his words, not mine)
language where programmers can go to look for work, I think he's
fooling himself.
No I wouldn't say that it has reached market penetration yet; but, it
has more momentum then any language I am familiar with. I wouldn't be
at all surprised to see it becoming quite common in the next five years.
I would be very surprised if this were the case. As you point out,
languages typically have very long incubation times before they reach
any kind of serious market penetration. This seems doubly true for a
relatively narrowly targeted language that is in many ways on the
wrong side of history.
I wouldn't say Go is narrowly targeted. It's a systems language that can
compete in the same domain with scripting languages. It is true that most
languages have long incubation periods; but, corporate support can change
that quite a bit. C#, being backed by Microsoft, managed to go mainstream
pretty quickly.
This seems... shall we say, overly optimistic. I've seen no evidence
at all that Go is even trying to compete with scripting languages, and
I don't know of anyone who would actually use it where a shell script
might do. AFAICS, it is an unabashedly concurrency-centric systems
language for people who are willing to sacrifice some speed and
control for legible code. That's not an impossibly narrow niche (and
it certainly has deep pockets) but it *is* narrow compared to a
general purpose language like Java or Python.
I'd also note that the .NET languages received much, much more in the
way of support than Go seems to be.
How long has it taken Python to reach its present level of market
penetration? And, I still don't see a huge amount of professional Python
use outside of web developement. Go has only been public for less then
a year.
Python's very widely used for scripting and related tasks, and has a
pretty big user base in academia and the sciences.
Python has been widely used by people like us that happen to like the
language and found ways to use it in our workplaces; but, most of the
time it is an unofficial use that the company. You still don't see many
companies doing large scale internal development using Python and you
definately don't see any doing external developement using a language
that gives the customers full access to the source code.
Right, I mean, it's not like the company that wrote Go would *ever*
stoop to using Python ;)
Seriously, I see a lot of Python in use in the sciences, HPC, etc.
It's also a major part of nearly every linux distro, is widely used by
defense and intelligence contractors for what they consider to be
critical infrastructure, etc etc etc. Even if none of that were true
though, the fact is that you can be a successful language and only
deal with the web, and even you admit that Python is widely used in
that context.
Personally, I think the time is ripe for a language that bridges the
gap between ease of use dynamic languages with the performance and
distribution capabilities of a full systems level language.
I agree. That does not make Go that language, and many of the choices
made during Go's development indicate that they don't think it's that
language either. I'm speaking specifically of its non-object model,
lack of exceptions, etc.
1. Go has an object model. What it lacks is an object hierarchy where all
object are decended from a single root object since it does
not support object inheritance as it is used in most languages.
In Go we simply adapt an object to meet the needs of the newer
object by adding whatever new functionality is needed.
Go has structs. Its structs are not objects, principally because they
can't do real inheritance. You can do similar things ('structural
inheritance') to C structs, and nobody argues that C is OO.
2. Go has a similar mechanism to exceptions, defer/panic/recover. It does
downplay
Defer, panic, and recover only allow you to build a recovery stack.
That's like saying that try/except isn't needed anymore because you
have the with statement. Do you think you could get through a rewrite
of Django without ripping out some hair over that?
This is after all the promise the VM based languages made but never
really fulfilled. It is also high time for a fully concurrent language fully
capable of taking advantage of multicore processors without having to
deal with the inherent dangers of threading. There are several good
choices available for both a even a few that fit both bills; but, few of
them have the support of a company like Google that is capable of the
push required to move the language into the
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
In comp.lang.python, you wrote: Tim Harig, 17.01.2011 13:25: If I didn't think Python was a good language, I wouldn't be here. Nevertheless, it isn't a good fit for many pieces of software where a systems language is better suited. Reasons include ease of distribution without an interpeter, non-necessity of distributing source with the product, ability to leverage multiple CPU and multicore systems, and simple sequential performance. Given that Python does't work well in many areas, we could just give up and accept having to write C++ for our day jobs or we can look for a language which bridges the gap between those tasks that require C++'s level of control and those which work well for dynamic languages. Java attempted to do that, and has the market share to show that the concept works, but I think that it missed the mark for many needs. It is still much lower level then Python for purposes of rapid developement and too slow to be competative for non-long-lived tasks. So seriously need to take a look at Cython. http://cython.org One of the arguments for Python has always made is that you can optimize it by writing the most important parts in C. Perhaps that is a crutch that has held the communty back from seeking higher performance solutions in the language itself. I prefer a single language as opposed to a creolization of two. Go gives me more less complete independence from C. I can write pretty much anything I would like using almost pure Go and because it generates a native binary with similar performance to C, I don't need to resort to using another language. I certainly don't need to require anybody who wants to use a program I have compiled to install an interpreter. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-17, geremy condra debat...@gmail.com wrote:
On Mon, Jan 17, 2011 at 1:12 AM, Tim Harig user...@ilthio.net wrote:
On 2011-01-16, geremy condra debat...@gmail.com wrote:
I wouldn't say Go is narrowly targeted. It's a systems language that can
compete in the same domain with scripting languages. It is true that most
languages have long incubation periods; but, corporate support can change
that quite a bit. C#, being backed by Microsoft, managed to go mainstream
pretty quickly.
This seems... shall we say, overly optimistic. I've seen no evidence
at all that Go is even trying to compete with scripting languages, and
I don't know of anyone who would actually use it where a shell script
might do. AFAICS, it is an unabashedly concurrency-centric systems
I don't write Python where shell scripts will do either. I have rewritten
several simple Python scripts in Go. I will not be leaving Python
completely; but, Go will likely replace Python for most of my large scale
programming needs.
might do. AFAICS, it is an unabashedly concurrency-centric systems
language for people who are willing to sacrifice some speed and
control for legible code. That's not an impossibly narrow niche (and
it certainly has deep pockets) but it *is* narrow compared to a
general purpose language like Java or Python.
You are writing Go into far too narrow of a niche then it actually is. In
fact, whatever language you are commenting on doesn't sound like Go at all.
Go is every bit of a general purpose programming language. It is useful
for the same basic applications that you would otherwise write in Java. It
can do pretty much anything that you can do in C, with the probable
exception of writing operating systems. I have been using C/C++ for most
of my programming career; but, everything that I have done can be done with
Go. I am not really sure where you are seeing such narrowing limitations.
Support for concurrency is really icing on the cake. I find it rather
supprising that so many modern languages do not already support full
concurrency constructs.
Python's very widely used for scripting and related tasks, and has a
pretty big user base in academia and the sciences.
Python has been widely used by people like us that happen to like the
language and found ways to use it in our workplaces; but, most of the
time it is an unofficial use that the company. You still don't see many
companies doing large scale internal development using Python and you
definately don't see any doing external developement using a language
that gives the customers full access to the source code.
Right, I mean, it's not like the company that wrote Go would *ever*
stoop to using Python ;)
I have never said that there are not companies doing developement in
Python and certainly not for web programming; but, a handful of companies
that have adopted Python doesn't make it mainstream. Good luck finding
many Python jobs in my area. Java, C#, Visual Basic, PHP, *COBOL*,
RPG-IV, and, to a lesser extent, C++ jobs are available in abundance.
The few Python jobs that are available are for web based programming.
1. Go has an object model. What it lacks is an object hierarchy where all
object are decended from a single root object since it does
not support object inheritance as it is used in most languages.
In Go we simply adapt an object to meet the needs of the newer
object by adding whatever new functionality is needed.
Go has structs. Its structs are not objects, principally because they
can't do real inheritance. You can do similar things ('structural
inheritance') to C structs, and nobody argues that C is OO.
http://www.infoq.com/interviews/johnson-armstrong-oop
Listen to the third point. Object orientation is quite possible even
without inheritance. Not all programming languages support the same set
of OOP features. Not all classless OOP programming languages support
inheritance. The basic definition of object oriented programming is
programing with self contained objects which contain their own data and
the procedures necessary to manipulate that data.
2. Go has a similar mechanism to exceptions, defer/panic/recover. It does
downplay
Defer, panic, and recover only allow you to build a recovery stack.
That's like saying that try/except isn't needed anymore because you
have the with statement. Do you think you could get through a rewrite
of Django without ripping out some hair over that?
I don't know what you are referencing about Django as I don't work on or
with the project; but, if one wanted exceptions with similar sematics to
Python's, it could easily be built around Go's defer/panic/recover. There
are actually packages availble that recreate exceptions as they are used in
Ruby and other languages. The only think defer/panic/recover lacks is an
exception class containing more more detailed information about what
actually went wrong.
The current
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Mon, Jan 17, 2011 at 1:07 PM, Tim Harig user...@ilthio.net wrote: On 2011-01-17, geremy condra debat...@gmail.com wrote: On Mon, Jan 17, 2011 at 1:12 AM, Tim Harig user...@ilthio.net wrote: On 2011-01-16, geremy condra debat...@gmail.com wrote: I wouldn't say Go is narrowly targeted. It's a systems language that can compete in the same domain with scripting languages. It is true that most languages have long incubation periods; but, corporate support can change that quite a bit. C#, being backed by Microsoft, managed to go mainstream pretty quickly. This seems... shall we say, overly optimistic. I've seen no evidence at all that Go is even trying to compete with scripting languages, and I don't know of anyone who would actually use it where a shell script might do. AFAICS, it is an unabashedly concurrency-centric systems I don't write Python where shell scripts will do either. I have rewritten several simple Python scripts in Go. I will not be leaving Python completely; but, Go will likely replace Python for most of my large scale programming needs. I'm happy that you've found a language you like. I don't happen to share your enthusiasm for it, and I think my arguments are better grounded. I suspect you feel the same about yours, and I'm happy to leave it at that. might do. AFAICS, it is an unabashedly concurrency-centric systems language for people who are willing to sacrifice some speed and control for legible code. That's not an impossibly narrow niche (and it certainly has deep pockets) but it *is* narrow compared to a general purpose language like Java or Python. You are writing Go into far too narrow of a niche then it actually is. In fact, whatever language you are commenting on doesn't sound like Go at all. Go is every bit of a general purpose programming language. It is useful for the same basic applications that you would otherwise write in Java. It can do pretty much anything that you can do in C, with the probable exception of writing operating systems. I have been using C/C++ for most of my programming career; but, everything that I have done can be done with Go. I am not really sure where you are seeing such narrowing limitations. I'm a C, Python, and Haskell developer. Everything I've done could be done in C. I would probably not be happy if I had to, though. Some people get very attached to one language and use it for everything. I'd rather use the right tool for the job. Go is not an ideal language for high-performance code. Despite the occasional claims of others, Go is consistently outperformed by C, C++, and Java on a wide variety of benchmarks. Some claim that Ada and Haskell do as well, and my benchmarks (CPU bound, focused on speed of cryptographic primitives) *seem* to confirm that for Haskell. I say 'seem' because I'm clearly much more familiar with Haskell than with Go, and would be inclined to question my conclusions if they weren't in line with the work of others. You can argue that it's good enough- it is, for most cases- but taking a 20% performance hit rules it out of a lot of systems work, and the C-Go gap in many cases is much larger than that. Go is also not an ideal language for enterprise development. It provides no compatibility or support guarantees; in fact, the website describes it as 'an experiment' and recommends it for 'adventurous users'. There are no independent experts in case something goes wrong, and if it goes belly up a year from now you will have a one year old piece of legacy infrastructure on your hands. Maybe you don't think that this will be the case; in any event, I would not want to try convincing a CFO of that. As you point out, Go is also not a good language for operating systems work. The lack of a widely accepted GUI toolkit weakens your argument about application development. The lack of third party tools and dependence on foreign language bindings weakens your single-language argument. Etc, etc, etc. Taking these things out you are left with very little that Go is compellingly good at. I certainly don't see it displacing Java or C, which you claim is equivalent. Support for concurrency is really icing on the cake. I find it rather supprising that so many modern languages do not already support full concurrency constructs. Go's most-lauded feature is its goroutines. I suspect that if this isn't a big deal for you, you aren't its primary use case. Python's very widely used for scripting and related tasks, and has a pretty big user base in academia and the sciences. Python has been widely used by people like us that happen to like the language and found ways to use it in our workplaces; but, most of the time it is an unofficial use that the company. You still don't see many companies doing large scale internal development using Python and you definately don't see any doing external developement using a language that gives the customers full access to the source code. Right,
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-17, geremy condra debat...@gmail.com wrote: On Mon, Jan 17, 2011 at 1:07 PM, Tim Harig user...@ilthio.net wrote: On 2011-01-17, geremy condra debat...@gmail.com wrote: On Mon, Jan 17, 2011 at 1:12 AM, Tim Harig user...@ilthio.net wrote: On 2011-01-16, geremy condra debat...@gmail.com wrote: Go is every bit of a general purpose programming language. It is useful for the same basic applications that you would otherwise write in Java. It can do pretty much anything that you can do in C, with the probable exception of writing operating systems. I have been using C/C++ for most of my programming career; but, everything that I have done can be done with Go. I am not really sure where you are seeing such narrowing limitations. Some people get very attached to one language and use it for everything. I'd rather use the right tool for the job. I much agree. You don't see me dropping python, shell, awk, etc. I do expect Go will enter some of the programming that I am doing in Python and it will almost certainly replace much of the programming that I am doing in C/C++. Go is not an ideal language for high-performance code. Despite the occasional claims of others, Go is consistently outperformed by C, C++, and Java on a wide variety of benchmarks. Some claim that Ada and Haskell do as well, and my benchmarks (CPU bound, focused on speed of I much agree that Go doesn't beat C or C++. I really doubt that it could with the runtime necessary to do garbage collction. Nevertheless, I find that Go can be optimized to perform within tolerable limits of C given the boost it gives in development. I really question that you get Java anywhere even close to C performance. Google reports they get within the same order of magnitude as C for their long-lived server processes where the JIT has had time to optimize its results. For shorter term processes such as desktop applications, Java performance stinks -- even after you discount the JVM starup time. Ada is capable of C++ like performance *if* you compile it to remove *all* of runtime checking. Depending what checks you enable, it can run much slower. cryptographic primitives) *seem* to confirm that for Haskell. I say 'seem' because I'm clearly much more familiar with Haskell than with Go, and would be inclined to question my conclusions if they weren't I have not worked with Haskell, so I don't really have any idea's about its performance. I understand that leveraging lazy evaluation and result caching can provide some *huge* opportunities for optimizations. in line with the work of others. You can argue that it's good enough- it is, for most cases- but taking a 20% performance hit rules it out of a lot of systems work, and the C-Go gap in many cases is much larger than that. I don't work anything that involves and absolute need for performance. I could probably accept penalty several times that of C for higher level functionality; but, sometimes the penalty for Python is just too much. Many of my programs are very quick lived such that even loading an interpeter or VM can eclipse the actual runtime. Given less developmental effort required, I also find that I have more time to look for ways to optimize Go. There are many things (such as using alternate data structures rather then the build in slices and immutable strings) that can be used to accelerate Go when time permits and I suspect many more will be found as the language matures. Go is also not an ideal language for enterprise development. It provides no compatibility or support guarantees; in fact, the website describes it as 'an experiment' and recommends it for 'adventurous There is no doubt that it is a young project and there are a number of things that will need to be improved to be effective for some branches of programming; but, that isn't a language restriction. Frankly, I am rather impressed by the sheer number of third party packages that have already become available. No go isn't going to replace some of the other top mainstream langauges today; but, I can easily see it starting to see some market penetration 5 years from now. users'. There are no independent experts in case something goes wrong, and if it goes belly up a year from now you will have a one year old piece of legacy infrastructure on your hands. Maybe you don't think that this will be the case; in any event, I would not want to try convincing a CFO of that. If I was trying to convince a CFO, I would ask if he really thought Google was likely to simply drop the time and effort that Google has already placed into the infrastructure. Furthermore, few dying languages already have not one, but two, open source compilers available for use. As you point out, Go is also not a good language for operating systems work. The lack of a widely accepted GUI toolkit weakens your argument about application development. The lack of third party tools and dependence on foreign language
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Mon, 17 Jan 2011 19:41:54 +, Tim Harig wrote: One of the arguments for Python has always made is that you can optimize it by writing the most important parts in C. Perhaps that is a crutch that has held the communty back from seeking higher performance solutions in the language itself. Are you aware of PyPy? PyPy is now about double the speed of CPython for most things, and they have set themselves the ambitious target of being faster than C. http://codespeak.net/pypy/dist/pypy/doc/faq.html -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Tim Harig, 17.01.2011 20:41: In comp.lang.python, I wrote: Tim Harig, 17.01.2011 13:25: If I didn't think Python was a good language, I wouldn't be here. Nevertheless, it isn't a good fit for many pieces of software where a systems language is better suited. Reasons include ease of distribution without an interpeter, non-necessity of distributing source with the product, ability to leverage multiple CPU and multicore systems, and simple sequential performance. Given that Python does't work well in many areas, we could just give up and accept having to write C++ for our day jobs or we can look for a language which bridges the gap between those tasks that require C++'s level of control and those which work well for dynamic languages. Java attempted to do that, and has the market share to show that the concept works, but I think that it missed the mark for many needs. It is still much lower level then Python for purposes of rapid developement and too slow to be competative for non-long-lived tasks. So seriously need to take a look at Cython. http://cython.org One of the arguments for Python has always made is that you can optimize it by writing the most important parts in C. Perhaps that is a crutch that has held the communty back from seeking higher performance solutions in the language itself. The good news with Cython is that you no longer need to write the most important parts in C. Instead, you type them statically and compile them. You don't even need to sacrifice Python source compatibility for that. So you get the best of Python at the speed of C (or 'c', as some would say ;). I prefer a single language as opposed to a creolization of two. With the possible exception of Lisp, I find it hard to think of a language that's still alive and not the creolisation of (at least) two other languages. They all inherited from each other, sometimes right from the start (lessons learned) and always during their subsequent life time. I certainly don't need to require anybody who wants to use a program I have compiled to install an interpreter. You will be happy to hear that you can link Cython programs against libpython (even statically) to build an executable that embeds the interpreter for you. Besides, on most operating systems, installing a dependency is done automatically, and Go code doesn't run natively on Windows either, without first installing and running the compiler over it. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Sun, 16 Jan 2011 09:47:35 +, Tim Harig wrote: One of the things that gives me hope for Go is that it is backed by Google so I expect that it may gain some rather rapid adoption. It has made enough of a wake to grab one of Eweek's 18 top languages for 2011. If the author thinks that Go is a tried and true (his words, not mine) language where programmers can go to look for work, I think he's fooling himself. When I design my new language, I will make sure I choose a name such that any attempt to search for it on job sites will produce oodles and oodles and oodles of false positives, all the better to ensure that simple- minded top language of ... surveys will give a massively inflated job count. I think I'll call it Salary. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-16, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sun, 16 Jan 2011 09:47:35 +, Tim Harig wrote: One of the things that gives me hope for Go is that it is backed by Google so I expect that it may gain some rather rapid adoption. It has made enough of a wake to grab one of Eweek's 18 top languages for 2011. If the author thinks that Go is a tried and true (his words, not mine) language where programmers can go to look for work, I think he's fooling himself. No I wouldn't say that it has reached market penetration yet; but, it has more momentum then any language I am familiar with. I wouldn't be at all surprised to see it becoming quite common in the next five years. How long has it taken Python to reach its present level of market penetration? And, I still don't see a huge amount of professional Python use outside of web developement. Go has only been public for less then a year. Personally, I think the time is ripe for a language that bridges the gap between ease of use dynamic languages with the performance and distribution capabilities of a full systems level language. This is after all the promise the VM based languages made but never really fulfilled. It is also high time for a fully concurrent language fully capable of taking advantage of multicore processors without having to deal with the inherent dangers of threading. There are several good choices available for both a even a few that fit both bills; but, few of them have the support of a company like Google that is capable of the push required to move the language into the mainstream. When I design my new language, I will make sure I choose a name such that any attempt to search for it on job sites will produce oodles and oodles and oodles of false positives, all the better to ensure that simple- minded top language of ... surveys will give a massively inflated job count. I would agree that Go wasn't the best idea for a language name from the search perspective. One would have though a company like Google would have been cognizant of those limitations... -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Sun, Jan 16, 2011 at 3:03 AM, Tim Harig user...@ilthio.net wrote: On 2011-01-16, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If the author thinks that Go is a tried and true (his words, not mine) language where programmers can go to look for work, I think he's fooling himself. No I wouldn't say that it has reached market penetration yet; but, it has more momentum then any language I am familiar with. I wouldn't be at all surprised to see it becoming quite common in the next five years. I would be very surprised if this were the case. As you point out, languages typically have very long incubation times before they reach any kind of serious market penetration. This seems doubly true for a relatively narrowly targeted language that is in many ways on the wrong side of history. How long has it taken Python to reach its present level of market penetration? And, I still don't see a huge amount of professional Python use outside of web developement. Go has only been public for less then a year. Python's very widely used for scripting and related tasks, and has a pretty big user base in academia and the sciences. Personally, I think the time is ripe for a language that bridges the gap between ease of use dynamic languages with the performance and distribution capabilities of a full systems level language. I agree. That does not make Go that language, and many of the choices made during Go's development indicate that they don't think it's that language either. I'm speaking specifically of its non-object model, lack of exceptions, etc. This is after all the promise the VM based languages made but never really fulfilled. It is also high time for a fully concurrent language fully capable of taking advantage of multicore processors without having to deal with the inherent dangers of threading. There are several good choices available for both a even a few that fit both bills; but, few of them have the support of a company like Google that is capable of the push required to move the language into the mainstream. You might be right, but I doubt we'll know one way or the other in the next 5 years. Personally, I'm hoping that functional language use continues to grow. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
