In fact, it was one of the things that kept me from even bothering to look at Python for a long time -- all of the Python advocates come across like a bunch of jerks....
I think that some Python advocates come off as jerks, when talking about Perl, because they have had to work with Perl and loathed the experience. Perl code has write-only properties that can make it frustrating to work with, especially if a Perl newbie is working with highly idiomatic code written by an expert.
Why don't they raise a big stink every time someone mentions Java?
Java is a lot more readable than idiomatic Perl.
Cheers,
Brian
Re:Not convinced at all
on
Think Python
·
· Score: 1
From 3.6.1:
"It is implementation-defined whether a program in a freestanding environment is required to define a main function."
I guess we would need to know the definition of "freestanding" in this context.
Re:Not convinced at all
on
Think Python
·
· Score: 1
I haven't read the Elkner article/paper/book so I can't comment on it as a whole.
But think that your comment about main() might indicate a lack of understanding on your part, not on Elkners.
I don't think that the ANSI C specification defines a return type for main() (I did a quick grep of the spec to check).
Also, in practice, different implementations require different return types. UNIX mains return an int. Macs mains return void. For Windows GUI apps, main isn't even the entry point.
Re:Perl?
on
Think Python
·
· Score: 2, Interesting
Actually, Python and Perl are very different:
- Python is strongly dynamically typed, while Perl is weakly typed - Python has a small number of syntactic constructs, while Perl has many - In Python, everything is an object
One of the problems with using templates in interfaces is that STL implementations may not be binary compatible between releases. Imagine the following libary interface:
mylib.h ------- vector<blah> getBlahs(void);
The vector<blah> implementation is compiled into both mylib and the application that uses it (mayapp). The nasty part is that if mylib and myapp are compiled with different STL versions, then they may not be binary compatible. I encountered this problem when moving to gcc 3.0. It was amazingly difficult to debug the problem.
Also, the gcc and VC6.0 STL implementations suck and have subtle incompatibilities.
So, after being bitten hard a few times, I try to avoid STL like the plague.
I think that most implementors ignore the ASCII string requirement because it is impossible to transmit all ASCII characters anyway e.g. NUL is an ASCII character but it is not an XML character.
* Avoiding the use of the Unicode strings is recommended because many languages that use XML-RPC (e.g. C, PHP) don't have terribly good Unicode support.
As its name suggests it passes XML documents between server and client, in this case over HTTP.
This statement is a bit deceptive. The purpose of the XML-RPC protocol is not to allow you to exchange XML documents with your own grammar between a client and server. It's purpose is to define a grammar of simple, cross-language types that can be used to marshal the arguments and return values of most simple method calls.
However it's pretty asymmetric. It can only deal with client requests, an issue pretty much covered the other day. [slashdot.org]. The server can't delay a response or let the client know when it's finished a lengthy request.
Why don't you just start a new thread for each of your requests?
There are at least two significant processes involved in every GUI app: the application itself and the window server. And remember that console applications that write to stdout/stderr use the Window server as well. In fact, for a few of my applications, the time to render the text on screen seems to be more significant than the actual computation time.
So most GUI applications will take significant advantage of the 2nd processor.
I am more interested in how you do your 3d modeling in text mode. I mean, sure the model can be described using text but how do you actually view it? Some sort of ASCII art system or is actually rendering your models not of interest to you?
Remember Mac OS Before the apple menu? I do. The functionality (like being able to add aliases) were added in OS-6. The control strip appeared for powerbooks only in os-7. The mac os this guy misses is less than 5 years old. all of his widgets are relatively new.
I don't recall anything about the really early versions of the Mac OS but System 4.1 definately had an Apple Menu that was configurable. Aliases didn't come until System 7 (which was the first version of the OS to have an Alias Manager).
I don't understand how organized labor can help programmers.
The demand for software development talent is sufficiently high that it's practitioners have serious negotiating power with their employers. If you don't like your work environment, discuss it with your boss and then, if you don't get the outcome that you want, quit. Then spend the next day of two getting a new job. Hell, it is likely that you will be employeed continuously if you are obligated to give two weeks notice.
Organized labor, in my opinion, is only of benefit to people who aren't terribly talented or (inclusive) work in an industry where employees are commodities.
Slashdot Mirror
In fact, it was one of the things that kept me from even bothering to look at Python for a long time -- all of the Python advocates come across like a bunch of jerks....
I think that some Python advocates come off as jerks, when talking about Perl, because they have had to work with Perl and loathed the experience.
Perl code has write-only properties that can make it frustrating to work with, especially if a Perl newbie is working with highly idiomatic code written by an expert.
Why don't they raise a big stink every time someone mentions Java?
Java is a lot more readable than idiomatic Perl.
Cheers,
Brian
From 3.6.1:
"It is implementation-defined whether a program in a freestanding environment is required to define a main function."
I guess we would need to know the definition of "freestanding" in this context.
I haven't read the Elkner article/paper/book so I can't comment on it as a whole.
But think that your comment about main() might indicate a lack of understanding on your part, not on Elkners.
I don't think that the ANSI C specification defines a return type for main() (I did a quick grep of the spec to check).
Also, in practice, different implementations require different return types. UNIX mains return an int. Macs mains return void. For Windows GUI apps, main isn't even the entry point.
Actually, Python and Perl are very different:
- Python is strongly dynamically typed, while Perl is weakly typed
- Python has a small number of syntactic constructs, while Perl has many
- In Python, everything is an object
blah, blah, blah
One of the problems with using templates in interfaces is that STL implementations may not be binary compatible between releases. Imagine the following libary interface:
mylib.h
-------
vector<blah> getBlahs(void);
The vector<blah> implementation is compiled into both mylib and the application that uses it (mayapp). The nasty part is that if mylib and myapp are compiled with different STL versions, then they may not be binary compatible. I encountered this problem when moving to gcc 3.0. It was amazingly difficult to debug the problem.
Also, the gcc and VC6.0 STL implementations suck and have subtle incompatibilities.
So, after being bitten hard a few times, I try to avoid STL like the plague.
As for the ASCII string dependence...
I think that most implementors ignore the ASCII string requirement because it is impossible to transmit all ASCII characters anyway e.g. NUL is an ASCII character but it is not an XML character.
My (and others') interpretation of the spec is:
- ASCII string
+ XML Char*
* Avoiding the use of the Unicode strings is recommended because many languages that use XML-RPC (e.g. C, PHP) don't have terribly good Unicode support.
As its name suggests it passes XML documents between server and client, in this case over HTTP.
This statement is a bit deceptive. The purpose of the XML-RPC protocol is not to allow you to exchange XML documents with your own grammar between a client and server. It's purpose is to define a grammar of simple, cross-language types that can be used to marshal the arguments and return values of most simple method calls.
However it's pretty asymmetric. It can only deal with client requests, an issue pretty much covered the other day. [slashdot.org]. The server can't delay a response or let the client know when it's finished a lengthy request.
Why don't you just start a new thread for each of your requests?
There are at least two significant processes involved in every GUI app: the application itself and the window server. And remember that console applications that write to stdout/stderr use the Window server as well. In fact, for a few of my applications, the time to render the text on screen seems to be more significant than the actual computation time.
So most GUI applications will take significant advantage of the 2nd processor.
I am more interested in how you do your 3d modeling in text mode. I mean, sure the model can be described using text but how do you actually view it? Some sort of ASCII art system or is actually rendering your models not of interest to you?
I don't recall anything about the really early versions of the Mac OS but System 4.1 definately had an Apple Menu that was configurable. Aliases didn't come until System 7 (which was the first version of the OS to have an Alias Manager).
I don't understand how organized labor can help programmers.
The demand for software development talent is sufficiently high that it's practitioners have serious negotiating power with their employers. If you don't like your work environment, discuss it with your boss and then, if you don't get the outcome that you want, quit. Then spend the next day of two getting a new job. Hell, it is likely that you will be employeed continuously if you are obligated to give two weeks notice.
Organized labor, in my opinion, is only of benefit to people who aren't terribly talented or (inclusive) work in an industry where employees are commodities.