Just because you find Java complicated doesn't mean a good programmer would.
*yawn*
Perhaps your Java-wielding friends might find the ad hominem attack appropriate, in Python community they are usually considered a sign of immaturity. Your attitude is a bigger problem in large scale programming projects than your language choice.
What a silly statement. The speed at which code can be physically typed into a keyboard is not the limiting factor for development time
You know, I could try explaining this to you forever, and apparently you still wouldn't get it. I'll leave it at that. Life's too short.
Every one who proclaims a Silver Bullet is doomed to be considered a fool.
Aren't you being a bit too dramatic? It's a slashdot signature, not a CS thesis project.
Sorry, but Brookes was right, there is no Silver bullet, and Python certainly is not it.
If you say so;-).
Java is irrelevant as a language, its the support and tools it has that makes it a good platform choice.
Agreed. Java is a very mature platform, and a good, safe, conservative choice. It all depends on what you are doing.
Python will possibly be the conservative choice in some years to come, we'll see. I'd like to see young people educated in Python and become agile developers who run circles around large teams of more conservative developers, thus dragging it into the billion dollar mainstream of Java, instead of the OSS mainstream it inhabits at the moment.
Fortunately, programming languages have advanced somewhat since then. In OCaml, i
Yes, I know that static typing has better implementations than C++ and Java; at least Haskell and OCaml. Unfortunately almost nobody seems to use them. This is a shame especially for OCaml; I've played w/ it a little bit and kinda liked it, esp. w/ the knowledge that it will be almost as fast as C++ when compiled to native code.
Type inference doesn't come w/o a price, though. OCaml is significantly harder to understand than Python, which is a factor. ISTR some OCaml people were even bragging how difficult their language is in some mailing list, in the childish 31137 manner.
Run-time asserts are not the same as compile-time type checking and interface contracts.
Well, duh. Still, they can be used to enforce contracts.
If you don't even understand this simple distinction then you really should avoid serious large-scale software development.
It doesn't occur to you that I might know exactly where you are coming from, having been there myself some 4 years ago? I have just changed my view, because in life one learns new things.
Can't you realize that I know something you don't, someone might say I have a wider perspective. I write large scale C++ for living, yet I "get" Python and dynamic typing. It's nothing you couldn't learn by playing with Python a little bit, perhaps even trying to create something bigger in it. I assume you are not inherently stupid and can learn new tricks.
Python doesn't have type contracts, this makes it unsuitable for serious Object Orientated programming.
Bzzt. You can typecheck and assert all you want. It is just adviced against, because you gain more by using truly dynamic typing. Some projects like Zope have implemented Interfaces system which do the same thing.
It might cripple the productivity of a poor programmer,
No, it cripples the productivity of any programmer. Experience is what you gain by doing stuff, "static typing = necessary" is what inexperienced programmers learn at school and reading beginner level books.
but type-safe programming is second nature to an experienced developer, and it gives invaluable compile-time guarantees about what your code will and won't do.
It's not so invaluable as you may think.
You know, many Python (and Lisp, and Ruby) fans have C++/Java/whatever programming as a day job. They just know better, unlike most Java fans that have never done anything they weren't taught at school. Perhaps you shouldn't extrapolate your limited experience to what all "experienced programmers" should think. It's a bit inflammatory, too.
And if you call f with an object that can't quack, do you find out at compile time or run time?
Run time, it raises an exception.
Experienced software engineers quickly learn that any perceived benefit from weak typing is quickly lost in debugging.
Not true. These types of errors are rare, and catched immediately. There is no debugging involved, just look up the line in the exception traceback, and fix the error. "Experienced software engineer", having experience in languages that are not VB, C and Java, should know that.
In general, it is better to find bugs at compile time than run time.
Yes, it's slightly better. The difference is insignificant compared to the way static typing (as done in Java and C++) cripples your productivity. It's usually people who have not tried dynamically typed language that bring this up - it's an echo from the childhood trauma of having used Basic, and the relief brought by Pascal or C.
Call f with an object that can quack, and it quacks. No need to impose any class hierarchy, the only requirement is that the object can quack. After using DT for a while pieces just "click" and you immediately reach satori.
Lisp and Smalltalk are other examples of DT. Weak typing is a different thing, Python imposes strong but dynamic typing. People at usenet are usually more than eager to explain the difference.
but I would be interested in you had any references or evidence that backed your number up.
There seems to be a concensus in the Python community about these numbers. I think it can be considered more or less valid because most of the py community knows Java, and feel the difference. Its the difference in thought process, there is less "mapping" going on from brain to the screen.
there is also no question for me that static typing makes it generally easier to understand and follow code that I'm reading (by providing more information up front)
This can be cirumvented by documentation, and generally having friendlier API.
and eliminates certain classes of logic errors from code that simply won't show up from a straight compile.
IME these logic errors are catched pretty well w/ runtime exceptions.
This simplifies code reviews, transitioning code from one developer to another, and gives code longer shelf-life.
Nothing helps there more than code readability. This includes the length of the code - you can easily digest only a certain amount of code at the time, and Python code is always shorter and thus easier to read.
Extra keystrokes (given how good most IDEs are) are unimportant. What's critical is how quickly other developers can understand, review, modify, debug, and/or replace your work.
I agree wholeheartedly. However, you miss an essential, "agile" angle in those extra keystrokes - w/ higher development speed you tend to experiment more and write more thorough test cases. Therefore you produce better code and cleaner architecture.
Clarity is my goal, and the language that provides the most clarity to other developers is that language that I will prefer. Right now, in a comparison of Python to Java, I believe that language to be Java.
I share your goals, and agree to disagree about the way of getting there. However, you don't have to make a strict decision to stick to Java and avoid Python. You can implement things like unit tests and prototypes in Jython, thus getting the best of all worlds. Jython won't have the performance of Java, but I'm sure you'll learn to appreciate the productivity boost you get.
Perhaps you could implement your project in Jython over a weekend and then make your team implement it in Java:-).
Rubbish. A skilled Java programmer could write a typical piece of code just as quickly as a skilled python programmer - the difference is that becomming a skilled python programmer is easier.
Do you base this assertion to actual experience, or just a hunch that "it surely must be so"? If both languages are used to solve the same problem, the Python program is much more concise. It's not physically possible to create the Java program as quickly, given the same typing speed. Not to mention the difference in semantic complexity, which determines how fast you can churn out that code (assuming nonzero brain latency).
I guess people who have never tried dynamic typing can't comprehend how much faster development can be using it.
I don't know much about Python and I'll give it a go when I get a chance,
Go ahead and try it today, there is not much of a learning curve. You will see that getting to know it is fun, not a chore like, say, Java.
but it's really hard to take your comments seriously when you call Python a "Silver Bullet" in your sig;)
It has been a SB for me. Perhaps it would be more correct to say that OOP is a SB when realized by a language like Python (it definitely isn't w/ C++ and Java). And besides, little hyperbole never hurt anyone:-).
Productive for you now... but what about 6 months down the road? What if you want to realize your product to the world, how hard is it to extend it?
The advantages over Java are even increased 6 months down the road. Python code is much more readable and maintainable, hence easier to extend. Dynamically typed object model scales incredibly well.
I used to think the same about Perl vs Java, until I started looking at frameworks like Cocoon and they're all written in Java.
Comparing Perl to Java is foolish, Perl is more like Awk than a general purpose programming language, and not meant for large projects at all.
Someone should do a study on the time taken to design, implement and debug a resonably complex chunk of code under C++ and Java. I'm pretty sure that the result would show the huge advanatage of Java over C++.
The difference b/w Java and C++ would be dwarfed by the difference b/w Java and Python. Java may be 30-40% more productive than C++, but Python is 1000% more productive than Java. And yes, this applies to larger projects. J2EE may come to its own w/ projects that have hundreds of mediocre programmers, but if you have a mid-size team of highly skilled developers creating something new & unique (something like Zope or Chandler), Python will trounce the competition.
Note that Python is pretty easy to extend in C/C++, so that speed critical parts can be rewritten in C if the performance becomes an issue. Writing the whole program in C or C++ is a premature optimization.
I guess you'll just have to upgrade your bootloader. Recompilation of init and other software might also be necessary - 2.6.x is known to break the binary compatibility with current versions of NetBSDs. Filesystem should work, though.
Re:Besides Debian, What distros have 2.6.x ?
on
Kernel 2.6.1 Released
·
· Score: 3, Informative
Arjan has prebuilt rpms for Fedore Core 1, at least. Lots of Fedora people run it, unsurprisingly.
Of course it does. That's why you can do most of the stuff you use shell for in Python.
I'm obviously not saying that the shell is evil incarnate that should be removed from the system. I'm saying that programming straight for it, instead of invoking it from Python, is futile.
Also, how is os.system() supposed to be less verbose?
We developers then to use these things called "functions" to make stuff less verbose. And nobody prevents you from doing
x = os.system
x("ls")
And Python isn't designed primarily as a process control language, which makes things trickier than in a shell (have you ever done job control in Python)?
Yes I have, if you mean the.pid file kind of stuff. Works like a charm. You fail to realize that language doesn't need to be "designed" for a particular task to excell in it, it happens automatically if the fundamental language design is good enough. You can do the rest with libraries.
You have to do a check to see what platform you're on
Well, the situation is not buch better with shell scripts on windows - cygwin just doesn't work like it should.
On Python I have to write a wrapper function just to make things usable.
I always have a wrapper fn for os.system. Several, in fact. Typically I print out the command and then execute it. Sometimes w/ logging, sometimes w/o.
In Python, I would either have to fork explicitly (yuck), or read in from the input piecemeal, and then write my translation on the output piecemeal (double-yuck). There is no straight-forward Python equivalent of { }.
Have you checked out "pipes" module, by any chance?
Slashdot Mirror
I'm wondering how good programming can be equated to typing speed.
Of course it isn't. That was million miles away from my point. Apparently the rhetoric got lost, so here's the point:
- Python let's you do the same thing with less typing
- In Python you don't need to think as much what you are typing, hence there is shorter road from he brain to ready code, and you can type faster
Therefore, Python code gets ready sooner than Java Code, and there is less code to maintain.
Just because you find Java complicated doesn't mean a good programmer would.
*yawn*
Perhaps your Java-wielding friends might find the ad hominem attack appropriate, in Python community they are usually considered a sign of immaturity. Your attitude is a bigger problem in large scale programming projects than your language choice.
What a silly statement. The speed at which code can be physically typed into a keyboard is not the limiting factor for development time
You know, I could try explaining this to you forever, and apparently you still wouldn't get it. I'll leave it at that. Life's too short.
Every one who proclaims a Silver Bullet is doomed to be considered a fool.
;-).
Aren't you being a bit too dramatic? It's a slashdot signature, not a CS thesis project.
Sorry, but Brookes was right, there is no Silver bullet, and Python certainly is not it.
If you say so
Java is irrelevant as a language, its the support and tools it has that makes it a good platform choice.
Agreed. Java is a very mature platform, and a good, safe, conservative choice. It all depends on what you are doing.
Python will possibly be the conservative choice in some years to come, we'll see. I'd like to see young people educated in Python and become agile developers who run circles around large teams of more conservative developers, thus dragging it into the billion dollar mainstream of Java, instead of the OSS mainstream it inhabits at the moment.
Fortunately, programming languages have advanced somewhat since then. In OCaml, i
Yes, I know that static typing has better implementations than C++ and Java; at least Haskell and OCaml. Unfortunately almost nobody seems to use them. This is a shame especially for OCaml; I've played w/ it a little bit and kinda liked it, esp. w/ the knowledge that it will be almost as fast as C++ when compiled to native code.
Type inference doesn't come w/o a price, though. OCaml is significantly harder to understand than Python, which is a factor. ISTR some OCaml people were even bragging how difficult their language is in some mailing list, in the childish 31137 manner.
Run-time asserts are not the same as compile-time type checking and interface contracts.
Well, duh. Still, they can be used to enforce contracts.
If you don't even understand this simple distinction then you really should avoid serious large-scale software development.
It doesn't occur to you that I might know exactly where you are coming from, having been there myself some 4 years ago? I have just changed my view, because in life one learns new things.
Can't you realize that I know something you don't, someone might say I have a wider perspective. I write large scale C++ for living, yet I "get" Python and dynamic typing. It's nothing you couldn't learn by playing with Python a little bit, perhaps even trying to create something bigger in it. I assume you are not inherently stupid and can learn new tricks.
Python doesn't have type contracts, this makes it unsuitable for serious Object Orientated programming.
Bzzt. You can typecheck and assert all you want. It is just adviced against, because you gain more by using truly dynamic typing. Some projects like Zope have implemented Interfaces system which do the same thing.
It might cripple the productivity of a poor programmer,
No, it cripples the productivity of any programmer. Experience is what you gain by doing stuff, "static typing = necessary" is what inexperienced programmers learn at school and reading beginner level books.
but type-safe programming is second nature to an experienced developer, and it gives invaluable compile-time guarantees about what your code will and won't do.
It's not so invaluable as you may think.
You know, many Python (and Lisp, and Ruby) fans have C++/Java/whatever programming as a day job. They just know better, unlike most Java fans that have never done anything they weren't taught at school. Perhaps you shouldn't extrapolate your limited experience to what all "experienced programmers" should think. It's a bit inflammatory, too.
And if you call f with an object that can't quack, do you find out at compile time or run time?
Run time, it raises an exception.
Experienced software engineers quickly learn that any perceived benefit from weak typing is quickly lost in debugging.
Not true. These types of errors are rare, and catched immediately. There is no debugging involved, just look up the line in the exception traceback, and fix the error. "Experienced software engineer", having experience in languages that are not VB, C and Java, should know that.
In general, it is better to find bugs at compile time than run time.
Yes, it's slightly better. The difference is insignificant compared to the way static typing (as done in Java and C++) cripples your productivity. It's usually people who have not tried dynamically typed language that bring this up - it's an echo from the childhood trauma of having used Basic, and the relief brought by Pascal or C.
...and it's so obvious that you are concerned with optimization.
Yes, I'm not denying it. The deal here is to avoid the proverbial premature optimization.
def f(obj):
obj.quack()
Call f with an object that can quack, and it quacks. No need to impose any class hierarchy, the only requirement is that the object can quack. After using DT for a while pieces just "click" and you immediately reach satori.
Lisp and Smalltalk are other examples of DT. Weak typing is a different thing, Python imposes strong but dynamic typing. People at usenet are usually more than eager to explain the difference.
BTW, thanks for your sig - it got me starting to look at Python.
:-).
Thanks! That definitely made my day
but I would be interested in you had any references or evidence that backed your number up.
:-).
There seems to be a concensus in the Python community about these numbers. I think it can be considered more or less valid because most of the py community knows Java, and feel the difference. Its the difference in thought process, there is less "mapping" going on from brain to the screen.
there is also no question for me that static typing makes it generally easier to understand and follow code that I'm reading (by providing more information up front)
This can be cirumvented by documentation, and generally having friendlier API.
and eliminates certain classes of logic errors from code that simply won't show up from a straight compile.
IME these logic errors are catched pretty well w/ runtime exceptions.
This simplifies code reviews, transitioning code from one developer to another, and gives code longer shelf-life.
Nothing helps there more than code readability. This includes the length of the code - you can easily digest only a certain amount of code at the time, and Python code is always shorter and thus easier to read.
Extra keystrokes (given how good most IDEs are) are unimportant. What's critical is how quickly other developers can understand, review, modify, debug, and/or replace your work.
I agree wholeheartedly. However, you miss an essential, "agile" angle in those extra keystrokes - w/ higher development speed you tend to experiment more and write more thorough test cases. Therefore you produce better code and cleaner architecture.
Clarity is my goal, and the language that provides the most clarity to other developers is that language that I will prefer. Right now, in a comparison of Python to Java, I believe that language to be Java.
I share your goals, and agree to disagree about the way of getting there. However, you don't have to make a strict decision to stick to Java and avoid Python. You can implement things like unit tests and prototypes in Jython, thus getting the best of all worlds. Jython won't have the performance of Java, but I'm sure you'll learn to appreciate the productivity boost you get.
Perhaps you could implement your project in Jython over a weekend and then make your team implement it in Java
Ummm.. Slashdot is written in Perl, as are many other large projects. I've yet to see anything like Slashdot written in Awk.
I heard there was a vote b/w Perl, Awk, Intercal and sed, and Perl won by a narrow margin.
Rubbish. A skilled Java programmer could write a typical piece of code just as quickly as a skilled python programmer - the difference is that becomming a skilled python programmer is easier.
Do you base this assertion to actual experience, or just a hunch that "it surely must be so"? If both languages are used to solve the same problem, the Python program is much more concise. It's not physically possible to create the Java program as quickly, given the same typing speed. Not to mention the difference in semantic complexity, which determines how fast you can churn out that code (assuming nonzero brain latency).
I guess people who have never tried dynamic typing can't comprehend how much faster development can be using it.
Stop fighting. The solutions for the two of you is jython.
.NET will be a friend also.
:).
Indeed. Java is a friend of Python, C and C++ are friends of Python. Soon
The only enemy is ignorance, but it is also the enemy of productivity, so Python is fighting the good fight
I don't know much about Python and I'll give it a go when I get a chance,
;)
:-).
Go ahead and try it today, there is not much of a learning curve. You will see that getting to know it is fun, not a chore like, say, Java.
but it's really hard to take your comments seriously when you call Python a "Silver Bullet" in your sig
It has been a SB for me. Perhaps it would be more correct to say that OOP is a SB when realized by a language like Python (it definitely isn't w/ C++ and Java). And besides, little hyperbole never hurt anyone
Productive for you now ... but what about 6 months down the road? What if you want to realize your product to the world, how hard is it to extend it?
The advantages over Java are even increased 6 months down the road. Python code is much more readable and maintainable, hence easier to extend. Dynamically typed object model scales incredibly well.
I used to think the same about Perl vs Java, until I started looking at frameworks like Cocoon and they're all written in Java.
Comparing Perl to Java is foolish, Perl is more like Awk than a general purpose programming language, and not meant for large projects at all.
True. This kinda invalidates that part of the benchmark, because they are not comparing the same thing.
Someone should do a study on the time taken to design, implement and debug a resonably complex chunk of code under C++ and Java. I'm pretty sure that the result would show the huge advanatage of Java over C++.
The difference b/w Java and C++ would be dwarfed by the difference b/w Java and Python. Java may be 30-40% more productive than C++, but Python is 1000% more productive than Java. And yes, this applies to larger projects. J2EE may come to its own w/ projects that have hundreds of mediocre programmers, but if you have a mid-size team of highly skilled developers creating something new & unique (something like Zope or Chandler), Python will trounce the competition.
Note that Python is pretty easy to extend in C/C++, so that speed critical parts can be rewritten in C if the performance becomes an issue. Writing the whole program in C or C++ is a premature optimization.
NetBSD...wtf?
I guess you'll just have to upgrade your bootloader. Recompilation of init and other software might also be necessary - 2.6.x is known to break the binary compatibility with current versions of NetBSDs. Filesystem should work, though.
Arjan has prebuilt rpms for Fedore Core 1, at least. Lots of Fedora people run it, unsurprisingly.
This stunt is quite probably done to reduce the value consumers get from modding the xbox; soon similar stuff can be done with an un-modded xbox.
Quite probably MSFT will be referring to this as an "innovation", like all the other obvious things they do.
Anyone that passes around "confidential" stuff w/o putting it through GPG or equivalent is an idiot and deserver to be burned anyway.
Surprise, surprise, os.system() invokes--get this--the shell
.pid file kind of stuff. Works like a charm. You fail to realize that language doesn't need to be "designed" for a particular task to excell in it, it happens automatically if the fundamental language design is good enough. You can do the rest with libraries.
Of course it does. That's why you can do most of the stuff you use shell for in Python.
I'm obviously not saying that the shell is evil incarnate that should be removed from the system. I'm saying that programming straight for it, instead of invoking it from Python, is futile.
Also, how is os.system() supposed to be less verbose?
We developers then to use these things called "functions" to make stuff less verbose. And nobody prevents you from doing
x = os.system
x("ls")
And Python isn't designed primarily as a process control language, which makes things trickier than in a shell (have you ever done job control in Python)?
Yes I have, if you mean the
You have to do a check to see what platform you're on
Well, the situation is not buch better with shell scripts on windows - cygwin just doesn't work like it should.
On Python I have to write a wrapper function just to make things usable.
I always have a wrapper fn for os.system. Several, in fact. Typically I print out the command and then execute it. Sometimes w/ logging, sometimes w/o.
In Python, I would either have to fork explicitly (yuck), or read in from the input piecemeal, and then write my translation on the output piecemeal (double-yuck). There is no straight-forward Python equivalent of { }.
Have you checked out "pipes" module, by any chance?