It always makes me giggle whenever someone comments on this "tech" site and exposes a laughably narrow and counterproductive view of programming tools, computers, or anything else related to technology.
Or COBOL ones. Mind you, most of them don't know what interwebs are so you're unlikely to ever meet one unless you walk into a pub and there's a Fairport Convention tribute band playing.
That's interesting. Enjoy your giggles. I've got one screen, and if I'm programming, that's what I want to use it for. I find a book doesn't shove my program into the background, cover it up, and attempt to hide it. And this is even without using something that trys to pretend that the front application is the only one I could possibly be interested in seeing.
I'd like to give Microsoft rare kudos for making a language that (mostly) allows two syntax styles: "C" and "VB". Maybe they can add a third: Python/Ruby-like. (I know their CLR allows many languages, but they are not quite as cross-comparable as C# and VB.Net.)
Everybody has their syntax preference and there is no use in continued bickering; it's a personal thing that matches personal psychology/physiology. Your head is not my head. Your fingers are not my fingers.
Every tool has it's place and Python is no different.
Does Python get used where it's not the best tool? Obviously. But it's a failing of the programmer/system engineer, not the tool. There is a lot of stuff a tool can do. You can flatten a 10" wide plank on both sides and make it perfectly square using a crescent wrench and insert a screw with a hammer, but you are either going to waste a lot of time, end up with substandard results, or both...
You can compile Python into C. I had a Python script to roll a pair of dice one million times that took 123 seconds. Compiled Python to C, it took four seconds.
You can compile Python into C. I had a Python script to roll a pair of dice one million times that took 123 seconds. Compiled Python to C, it took four seconds.
Great. However, all of Python's weaknesses exist to support its use as an interpreted language. There are things I really love about Python (eg list comprehensions look almost mathematical, and are designed for readability), but just compiling it doesn't get round the limitations of the language architecture.
However, all of Python's weaknesses exist to support its use as an interpreted language.
This reminds of the arguments made against Java when it first came out 20 years ago: "It compiles to a virtual machine, not into actual assembly code like C/C++ does. That's a serious limitation for a programming language."
That's a different issue. There's a discussion about whether there is such a thing as "interpreted languages" and "compiled languages", and in the strictest sense, the answer is no, because some normally-compiled languages can be run in an interpreter, and most normally-interpreted languages can be compiled; but there is also a philosophical debate that allows an imprecise use of the terms. Java is what I'd consider a "compiled language" because of its architectural design -- I don't care that the target ar
STFU, Python shill. Python has no place. Compiled languages are the ONLY way to go if you want to get any big boy work done.
BTW, this Python shill actually HATES Python for a number of structural reasons and I avoid it for most tasks. It doesn't seem to be the proper tool for the kind of work I generally do, but that doesn't mean it doesn't have its use. A good programmer has many tools and understands which ones to use for what task.
Python is a useful language for prototyping things, or trying out some new algorithm.
It allows me to test these things out without worrying about all kinds of details like I would if I were programming in C.
Of course if I want performance for whatever it is I'm doing, then yes, I'll rewrite in C eventually.
And yet you don't need to be able to dynamically rewrite entire class definitions in order to do most of the useful stuff that Python lets you do quickly. And if you do use a lot of the stuff that makes Python Python, it will be a tough job to rewrite into C at a later date. As such, I personally feel that Python is a double-edged sword, and I would like the core of it without the ultra-dynamic, self-modifying stuff that (for my purposes) only serves as a source of potential errors.
Just write 'em along with your code. It's easy in general, and in Python, it's even easier. Between the diff import lib and the unittest import lib, you should be able to do *something* about testing.
people being afraid to touch the code to avoid breaking a rare and poorly-tested code path
In short, no unit tests were ever written.
Yes, welcome to the real world of software development where deadlines trump other things.
Your concept of the "real world" is pretty damned narrow... and false.
I would reply like this: No. Welcome to the real world where shitty programmers or shitty organizations pretend their shitty practices are the general case.
I've worked in large commercial firms, small start-ups and defense-related companies, each with teams of various sizes and different projects. C/C++, Java, C#, Python and what not. Some where horrid, some were great. Most were ok. Unit testing has always been the norm for the ok an
people being afraid to touch the code to avoid breaking a rare and poorly-tested code path
In short, no unit tests were ever written.
Yes, welcome to the real world of software development where deadlines trump other things.
Like I said (assuming you're the original AC), you need to work with better engineers. Code that's hard to test is typically a poorly designed monolith. People that "don't have time" to write tests code themselves into corners and then try to write the tests after the fact. Type checking doesn't prevent that, it just makes it harder to refactor.
I see that insecure python fanboys are downmodding this thread like a herd of global interpreter locks. I guess there's little chance for intelligent (if slightly heated) discussion of the merits of the language.
The best way to write Python is not to write it at all. Everywhere I've worked, any large project written in a dynamically typed language ballooned into a maintenance nightmare, sometimes to the point of people being afraid to touch the code to avoid breaking a rare and poorly-tested code path.
Seriously, it boggles the mind that, after all academic research and technical progress in compiler development, we still use dynamic languages. A compiler works like a mathematical proof machine, doubly so when a type-inferenced language is used. This is a tremendous advantage for error-checking and program correctness, yet it's "cool and hip" to take the hard way. Dynamic languages, python included, make easy things trivial, and hard things impossible. It's a tradeoff that should never be made.
I write python for a living, and I'm with you on dynamically typed languages, for big projects.
Having said that, small to medium projects and prototyping python is fantastic. Python lets me get a project up and running, without all the boilerplate and unnecessary overhead, which allows me to concentrate on getting the algorithm correct.
Then, if need be, I port to a language like Java (or C++ or C or w/ever).
I write python for a living, and I'm with you on dynamically typed languages, for big projects.
Having said that, small to medium projects and prototyping python is fantastic. Python lets me get a project up and running, without all the boilerplate and unnecessary overhead, which allows me to concentrate on getting the algorithm correct.
Then, if need be, I port to a language like Java (or C++ or C or w/ever).
True, but the problem emerges when a small project grows in size and scope, as it eventually will. Then a herd of outsourced developers or overenthusiastic and underexperienced co-ops take over, while the original developer leaves. Then all hell breaks loose. Even small projects need to be started on solid foundations. With modern compiled languages the barrier to start a project should be no worse than starting with a dynamic language. The decision will always pay off in the long run.
The best way to write Python is not to write it at all. Everywhere I've worked, any large project written in a dynamically typed language ballooned into a maintenance nightmare, sometimes to the point of people being afraid to touch the code to avoid breaking a rare and poorly-tested code path.
Seriously, it boggles the mind that, after all academic research and technical progress in compiler development, we still use dynamic languages. A compiler works like a mathematical proof machine, doubly so when a type-inferenced language is used. This is a tremendous advantage for error-checking and program correctness, yet it's "cool and hip" to take the hard way. Dynamic languages, python included, make easy things trivial, and hard things impossible. It's a tradeoff that should never be made.
Python is not the problem, bad engineering practices are. Strict typing is not a "mathematical proof machine", it's a spell checker. You can still write utter and complete garbage. Seriously, if you don't have good unit testing, functional testing and static code analysis, you are likely creating a support nightmare. And if you do have good unit testing, functional testing and static code analysis then strict typing is a hinderance to good design.
Books. Heh. (Score:1)
It always makes me giggle whenever this "tech" site publishes a review of something static and made of dead trees.
How about firing up some reviews of blogs for people who like to keep up with emerging tech instead?
Re: (Score:2)
You assume that books cannot change, but books kept in an electronic format can, and do, receive updates.
Especially when your provider is threatened with a lawsuit of some kind and they pull it from your account.
Re: (Score:1)
I know what you mean.
It always makes me giggle whenever someone comments on this "tech" site and exposes a laughably narrow and counterproductive view of programming tools, computers, or anything else related to technology.
Re: (Score:2)
Did you stop giggling when you found out it's an e-book?
Re: (Score:2)
You know, perl programmers never say anything quite as inane as this.
Re: (Score:2)
Or COBOL ones. Mind you, most of them don't know what interwebs are so you're unlikely to ever meet one unless you walk into a pub and there's a Fairport Convention tribute band playing.
Re: (Score:2)
Hey COBOL is awesome, especially the SCREEN SECTION :)
Why futz about with (n)curses for a day when you can knock out a beautifully laid out text UI in a 10 minutes!
(I'm 50% serious here..)
Re: (Score:2)
That's interesting. Enjoy your giggles. I've got one screen, and if I'm programming, that's what I want to use it for. I find a book doesn't shove my program into the background, cover it up, and attempt to hide it. And this is even without using something that trys to pretend that the front application is the only one I could possibly be interested in seeing.
Re:F*ck Python (Syntax Squabbles & Choice) (Score:1)
I'd like to give Microsoft rare kudos for making a language that (mostly) allows two syntax styles: "C" and "VB". Maybe they can add a third: Python/Ruby-like. (I know their CLR allows many languages, but they are not quite as cross-comparable as C# and VB.Net.)
Everybody has their syntax preference and there is no use in continued bickering; it's a personal thing that matches personal psychology/physiology. Your head is not my head. Your fingers are not my fingers.
My fingers are getting old, and I'm beginni
Effective Python (Score:2)
Hisssssss
Re: (Score:2)
Re:yeah right (Score:4, Informative)
Every tool has it's place and Python is no different.
Does Python get used where it's not the best tool? Obviously. But it's a failing of the programmer/system engineer, not the tool. There is a lot of stuff a tool can do. You can flatten a 10" wide plank on both sides and make it perfectly square using a crescent wrench and insert a screw with a hammer, but you are either going to waste a lot of time, end up with substandard results, or both...
Re: (Score:3)
You can compile Python into C. I had a Python script to roll a pair of dice one million times that took 123 seconds. Compiled Python to C, it took four seconds.
http://cython.org/ [cython.org]
Re: (Score:3)
I haven't tried running craps on my Nvidia video card yet. That should be a hell of a lot faster.
https://developer.nvidia.com/how-to-cuda-python [nvidia.com]
Re: (Score:2)
You can compile Python into C. I had a Python script to roll a pair of dice one million times that took 123 seconds. Compiled Python to C, it took four seconds.
Great. However, all of Python's weaknesses exist to support its use as an interpreted language. There are things I really love about Python (eg list comprehensions look almost mathematical, and are designed for readability), but just compiling it doesn't get round the limitations of the language architecture.
Re: (Score:2)
However, all of Python's weaknesses exist to support its use as an interpreted language.
This reminds of the arguments made against Java when it first came out 20 years ago: "It compiles to a virtual machine, not into actual assembly code like C/C++ does. That's a serious limitation for a programming language."
Re: (Score:2)
That's a different issue. There's a discussion about whether there is such a thing as "interpreted languages" and "compiled languages", and in the strictest sense, the answer is no, because some normally-compiled languages can be run in an interpreter, and most normally-interpreted languages can be compiled; but there is also a philosophical debate that allows an imprecise use of the terms. Java is what I'd consider a "compiled language" because of its architectural design -- I don't care that the target ar
Re:yeah right (Score:4, Insightful)
STFU, Python shill. Python has no place. Compiled languages are the ONLY way to go if you want to get any big boy work done.
BTW, this Python shill actually HATES Python for a number of structural reasons and I avoid it for most tasks. It doesn't seem to be the proper tool for the kind of work I generally do, but that doesn't mean it doesn't have its use. A good programmer has many tools and understands which ones to use for what task.
Re: (Score:2)
So what do you suggest?
Bash and grep?
perl?
This is /. Everything is to be written in elisp and run under Emacs.
Re: (Score:2)
Python is a useful language for prototyping things, or trying out some new algorithm.
It allows me to test these things out without worrying about all kinds of details like I would if I were programming in C.
Of course if I want performance for whatever it is I'm doing, then yes, I'll rewrite in C eventually.
And yet you don't need to be able to dynamically rewrite entire class definitions in order to do most of the useful stuff that Python lets you do quickly. And if you do use a lot of the stuff that makes Python Python, it will be a tough job to rewrite into C at a later date. As such, I personally feel that Python is a double-edged sword, and I would like the core of it without the ultra-dynamic, self-modifying stuff that (for my purposes) only serves as a source of potential errors.
Re: (Score:2)
Re: (Score:3)
people being afraid to touch the code to avoid breaking a rare and poorly-tested code path
In short, no unit tests were ever written.
Unit tests are cool. (Score:2)
Just write 'em along with your code. It's easy in general, and in Python, it's even easier. Between the diff import lib and the unittest import lib, you should be able to do *something* about testing.
Re: (Score:2)
people being afraid to touch the code to avoid breaking a rare and poorly-tested code path
In short, no unit tests were ever written.
Yes, welcome to the real world of software development where deadlines trump other things.
Your concept of the "real world" is pretty damned narrow... and false.
I would reply like this: No. Welcome to the real world where shitty programmers or shitty organizations pretend their shitty practices are the general case.
I've worked in large commercial firms, small start-ups and defense-related companies, each with teams of various sizes and different projects. C/C++, Java, C#, Python and what not. Some where horrid, some were great. Most were ok. Unit testing has always been the norm for the ok an
Re: (Score:2)
people being afraid to touch the code to avoid breaking a rare and poorly-tested code path
In short, no unit tests were ever written.
Yes, welcome to the real world of software development where deadlines trump other things.
Like I said (assuming you're the original AC), you need to work with better engineers. Code that's hard to test is typically a poorly designed monolith. People that "don't have time" to write tests code themselves into corners and then try to write the tests after the fact. Type checking doesn't prevent that, it just makes it harder to refactor.
Re: (Score:2, Funny)
I see that insecure python fanboys are downmodding this thread like a herd of global interpreter locks. I guess there's little chance for intelligent (if slightly heated) discussion of the merits of the language.
Re: (Score:2, Insightful)
The best way to write Python is not to write it at all. Everywhere I've worked, any large project written in a dynamically typed language ballooned into a maintenance nightmare, sometimes to the point of people being afraid to touch the code to avoid breaking a rare and poorly-tested code path.
Seriously, it boggles the mind that, after all academic research and technical progress in compiler development, we still use dynamic languages. A compiler works like a mathematical proof machine, doubly so when a type-inferenced language is used. This is a tremendous advantage for error-checking and program correctness, yet it's "cool and hip" to take the hard way. Dynamic languages, python included, make easy things trivial, and hard things impossible. It's a tradeoff that should never be made.
I write python for a living, and I'm with you on dynamically typed languages, for big projects.
Having said that, small to medium projects and prototyping python is fantastic. Python lets me get a project up and running, without all the boilerplate and unnecessary overhead, which allows me to concentrate on getting the algorithm correct.
Then, if need be, I port to a language like Java (or C++ or C or w/ever).
Re: (Score:1)
I write python for a living, and I'm with you on dynamically typed languages, for big projects.
Having said that, small to medium projects and prototyping python is fantastic. Python lets me get a project up and running, without all the boilerplate and unnecessary overhead, which allows me to concentrate on getting the algorithm correct.
Then, if need be, I port to a language like Java (or C++ or C or w/ever).
True, but the problem emerges when a small project grows in size and scope, as it eventually will. Then a herd of outsourced developers or overenthusiastic and underexperienced co-ops take over, while the original developer leaves. Then all hell breaks loose. Even small projects need to be started on solid foundations. With modern compiled languages the barrier to start a project should be no worse than starting with a dynamic language. The decision will always pay off in the long run.
Re: (Score:2)
The best way to write Python is not to write it at all. Everywhere I've worked, any large project written in a dynamically typed language ballooned into a maintenance nightmare, sometimes to the point of people being afraid to touch the code to avoid breaking a rare and poorly-tested code path.
Seriously, it boggles the mind that, after all academic research and technical progress in compiler development, we still use dynamic languages. A compiler works like a mathematical proof machine, doubly so when a type-inferenced language is used. This is a tremendous advantage for error-checking and program correctness, yet it's "cool and hip" to take the hard way. Dynamic languages, python included, make easy things trivial, and hard things impossible. It's a tradeoff that should never be made.
Python is not the problem, bad engineering practices are. Strict typing is not a "mathematical proof machine", it's a spell checker. You can still write utter and complete garbage. Seriously, if you don't have good unit testing, functional testing and static code analysis, you are likely creating a support nightmare. And if you do have good unit testing, functional testing and static code analysis then strict typing is a hinderance to good design.
You need to work with better engineers.
My Python is Already Effective (Score:1)
Re: (Score:1)
but your GF says it has white-space errors
59 Ways? (Score:2)
My 60th way to write better python (Score:2)
alias python=gcc
Re: (Score:2)
Classy.
Rule #1 (Score:2)
Just kidding!