I dunno about you, but I'm actually more anal-retentive about whitespace in C++ (or other similar languages) than in Python. In Python, it's just natural and easy.
Python has the Global Interpreter Lock, which means even though there are threads, they don't execute concurrently.
That's what popen(), fork(), system(), pipes, sockets, shared memory, and other methods of separate processes are for. Threading is probably not the answer in Python. As another reply mentioned, the GIL doesn't hurt for multi-threaded apps that are I/O-bound, you're still probably better off using something like asyncore when necessary, and multi-processing otherwise.
As another benefit, all of the standard system utilities for dealing with processes work much better than for threads... it's easy to cycle a single part of the system when every part is a separate daemon process. It's easy to actually use signals for interesting things like configuration reloading when processes are used instead of threads.
No. JavaScript is a scripting language, whereas Java is a full-fledged programming language [emphasis mine].
I understand the differences between Java and JavaScript. I don't understand the difference between a scripting language and a "full-fledged" programming language, and I usually find that false dichotomy used as a weasel phrase. What did you actually mean when you said that?
I do think that in 2008, solving **normal** business problems (whatever the hell that means) worrying about pointers and memory allocation seems to be a bit of an unnecessary distraction.
I know you put "normal" in double-asterisks, but I still think it's not obvious enough. Where I work, it is normal to be worrying about memory allocations (pointers not so much... if you actually have to worry about the pointers you wouldn't have been hired). It's still a distraction—but then, so is application-level access control, authentication, network security, and all of that other stuff that may be necessary for the business to succeed.
In other news, one of my friends works with Ruby on Rails. He loves it, but every once in a while, he's the guru who has to replace a ruby script with a raw SQL script and maybe a few stored procedures (because some 10-second queries would take hours in RoR-land). It always pays to know your tools inside and out.
You could always strace the executable, or run some sort of persistent netstat in the background. You don't need access to the source to detect if an application is making unexpected network connections.
When talking about web page load-times, it's not uncommon to measure things in hundreds of milliseconds. Two seconds is a long time for a simple page to load, and it is very noticable.
Not that it matters, though. Professional human click-traders will still have time to act before Google's data hits any clients over the internet; and even the very fastest pros are still slower than robots.
Alright, time to use an idea from real life 1. Create software that analyzes, buys and sells stocks. 2. Let it run. 3. Profit!
Fixed that for you. If you've never heard of algorithmic trading before, I suggest you spend a lot of time studying before you attempt it. Otherwise, all it will do is bankrupt your trading account faster than manual trading decisions.
Add Fooled by Randomness to that reading list. In one particular example, the author shows that a dentist looking at hour-by-hour market data sees mostly noise, wheres a dentist looking at quarterly reports sees very little noise.
...if you want to maximize your profitability you can time your share purchase precisely.
You can predict the future? If so, more power to you, you will defeat the entire market. If not, then "timing your purchase" is a gamble. Who cares if you can predict the behavior within the next 20 seconds when you can't even see the behavior in the next 20 milliseconds?
I don't disagree with the "truth about real-time quotes," but it often tells you a lot about how the market is reacting to news which can have some interesting implications.
...and those interesting implications can't wait 20 minutes?
xrange() vs range() depends on more than that... I'm assuming you point it out as a general efficiency rule. However, for small ranges, it may not matter. range() produces a small list, which can be iterated over natively. xrange() produces a generator, which uses __next__().
In any case, I'd probably just say [1, 2, 3] for such a small example (:
...your project grows in distribution requirements and annoyances
Depends on your method of third-party inclusion. For C or C++, third-party dependencies compiled in statically (or header-only dependencies) don't affect the distribution requirements at all.
...bytes your EXE consumes
I bet if everyone reimplemented libc, libstdc++, libpthread, libm, libX, etc. in their own executable, their executables would be pretty big. Ironically, the distribution size is an argument for well-organized code sharing, because of dynamic libraries.
...bugs you can't fix accumulate
Suck, I agree. But if an open-source library has a bug that's too complex for me to fix myself, I would probably have the same problem in a homebrew solution as well, so I think that's more of a strawman.
...code accumulates which you don't actually understand
Stop using libraries you don't understand.
...subtle bugs creep in because you don't understand what you've included
Stop using libraries you don't understand.
...you have trouble making things portable
The boost people are much better at portable development than I am.
...legal coercion you are subject to
Suck, I agree.
...obligations you have to 3rd parties increase
I don't understand this one... unless you're referring to licenses, which you already mentioned.
...you have trouble maintaining the code
The boost people are much better at maintaining their code than I am at recreating it from scratch.
...compatibility and functionality between different port targets diverges
the boost people... you get it.
I guess... our experiences have been different. I prefer to not reinvent the wheel, unless it's a particularly entertaining wheel.
I'm not even going to bother with the absurdity of the idea of JIT bytecode outperforming a compiled language on any architecture.
What's absurd about one bit of native binary code outperforming a different bit of native binary code? o_O
Well, nothing... but based on the GP's usage of the phrase "JIT bytecode", my best guess is that he's talking about Python (compiles source code to bytecode "JIT") as opposed to Java (compiles bytecode to machine code JIT).
If I ever encounter software that looks like that in a business outside of compiler/language design or mathematics, my immediate reaction would be svn blame followed by an angry conversation with the guilty party. Just because it's possible to write software that's formally hard to prove things about doesn't mean it's good to do so.
Anyone who leaves a single hydra by itself deserves to lose it! Are you sure you're accounting for the nearby pair of burrowed zerglings (a.k.a "developer interns", to stay on topic)?
Do you know what they put in car radiators? You'll find some of the same ingredients in many brands of ice cream... Do you know why these are found in many foods? Oh, they are preservatives, are they? So what are these chemicals supposed to preserve the food from? Oh yeah, spoilage! Well now, what causes spoilage? Oh right, microorganisms.
Being "natural" does not make something intrinsically good for you. Stevia (from Yerba mate) is a very strong natural sweetener, but the FDA has been very slow to accept it as a sweetener (since Americans consume much larger quantities of sweeteners than the rest of the world).
Preservatives are not intrinsically bad. Spoilage is caused by many reasons, such as oxidation or rancidification, both of which are caused by chemical processes and not microorganisms. For example, when I make guacamole, I add a bit of lime juice as a preservative because I want it to last more than 5 minutes.
The fact alone that an ingredient is present in edible things (ice cream) and inedible things (radiator fluid) doesn't tell me much. I'd be more interested in seeing what the FDA says about it. What if car manufacturers decided that natural honey had positive effects on radiators? Would that mean that honey was no longer safe to eat?
Sure, if you know the food has terrible things in it, don't eat it (and in this case, it looks like "vote with your wallet" is starting to work). But the mantra "If you can't pronounce it, don't eat it" is not the solution.
If you can't pronounce or understand any ingredient name, don't buy the item.
Or, you could spend a little bit of time to learn what the ingredient is, and then make your decision based off of information instead of FUD. Along those lines, I'd like to recommend What Einstein Told His Cook. It's quite interesting, and probably fairly accessible to most/. readers.
One of the things I hate about Microsoft software (indeed, almost all software thet runs in Windows) is non-descriptive file names.
On windows? Try "everywhere". Some other poorly-named libraries that come to mind are libm.so and libiberty.so (as cute as gcc -liberty may be, it is a useless name from a functional standpoint). Or if you consider any file, what about any of the 3-letter UNIX-style directory names?
Run-time library of graphics functions for Word.DLL
I would want to shoot any developer that used the phrase "Run-time library" or similar in the name of a DLL file. Windows DLLs are run-time libaries by definition. So we're down to WordGraphicsFunctions.dll. Or, since "functions" is a silly name (especially if you end up putting classes in the DLL or macros in the related header files), how about WordGraphics{Util,Tools}.dll or just WordGraphics.dll?
Second, this is the kind of device you want closest to your customers, not down the line where your traffic aggregates. If you want to stave upstream traffic, do it as soon as possible in the network.
I concur. I used to work at an ISP. The topology at one site was basically "Ethernet Jack -- Building Switch -- Site-Wide Switch -- Core Router -- Internet Cloud". When viruses hit, it was the fiber (from building to core switch) that saturated first. A desktop machine was capable of taking out an entire block of apartments just by saturating the local switch. QoS in the core gear wouldn't help at all if one of the building switches was doing nothing but sending out spam.
So unless Comcast routes every packet to their headquarters at the top of Mt. Doom for inspection before delivery...
I think that's the best phrase I've heard about Comcast ever. But on a serious note, think about the NSA wiretap room that AT&T had... that's gotta at least count as Orthanc or something.
Slashdot Mirror
I dunno about you, but I'm actually more anal-retentive about whitespace in C++ (or other similar languages) than in Python. In Python, it's just natural and easy.
That's what popen(), fork(), system(), pipes, sockets, shared memory, and other methods of separate processes are for. Threading is probably not the answer in Python. As another reply mentioned, the GIL doesn't hurt for multi-threaded apps that are I/O-bound, you're still probably better off using something like asyncore when necessary, and multi-processing otherwise.
As another benefit, all of the standard system utilities for dealing with processes work much better than for threads... it's easy to cycle a single part of the system when every part is a separate daemon process. It's easy to actually use signals for interesting things like configuration reloading when processes are used instead of threads.
whoosh...
I understand the differences between Java and JavaScript. I don't understand the difference between a scripting language and a "full-fledged" programming language, and I usually find that false dichotomy used as a weasel phrase. What did you actually mean when you said that?
No, he means
typedef static_if_<
is_practical<language::procedural<cee_plus_plus_tag<1> >::lang_type>::value,
language::procedural<
cee_plus_plus_tag<1>
>::lang_type>::allocator<boost::pool_allocator, 1024>,
empty_struct
>
my_heart;
I know you put "normal" in double-asterisks, but I still think it's not obvious enough. Where I work, it is normal to be worrying about memory allocations (pointers not so much... if you actually have to worry about the pointers you wouldn't have been hired). It's still a distraction—but then, so is application-level access control, authentication, network security, and all of that other stuff that may be necessary for the business to succeed.
In other news, one of my friends works with Ruby on Rails. He loves it, but every once in a while, he's the guru who has to replace a ruby script with a raw SQL script and maybe a few stored procedures (because some 10-second queries would take hours in RoR-land). It always pays to know your tools inside and out.
You could always strace the executable, or run some sort of persistent netstat in the background. You don't need access to the source to detect if an application is making unexpected network connections.
When talking about web page load-times, it's not uncommon to measure things in hundreds of milliseconds. Two seconds is a long time for a simple page to load, and it is very noticable.
Not that it matters, though. Professional human click-traders will still have time to act before Google's data hits any clients over the internet; and even the very fastest pros are still slower than robots.
Fixed that for you. If you've never heard of algorithmic trading before, I suggest you spend a lot of time studying before you attempt it. Otherwise, all it will do is bankrupt your trading account faster than manual trading decisions.
Add Fooled by Randomness to that reading list. In one particular example, the author shows that a dentist looking at hour-by-hour market data sees mostly noise, wheres a dentist looking at quarterly reports sees very little noise.
You can predict the future? If so, more power to you, you will defeat the entire market. If not, then "timing your purchase" is a gamble. Who cares if you can predict the behavior within the next 20 seconds when you can't even see the behavior in the next 20 milliseconds?
I'd like to see the sources for that... both out of curiosity and incredulity of validity.
xrange() vs range() depends on more than that... I'm assuming you point it out as a general efficiency rule. However, for small ranges, it may not matter. range() produces a small list, which can be iterated over natively. xrange() produces a generator, which uses __next__().
In any case, I'd probably just say [1, 2, 3] for such a small example (:
Seriously? You don't leave a lot of wiggle-room.
Depends on your method of third-party inclusion. For C or C++, third-party dependencies compiled in statically (or header-only dependencies) don't affect the distribution requirements at all.
I bet if everyone reimplemented libc, libstdc++, libpthread, libm, libX, etc. in their own executable, their executables would be pretty big. Ironically, the distribution size is an argument for well-organized code sharing, because of dynamic libraries.
Suck, I agree. But if an open-source library has a bug that's too complex for me to fix myself, I would probably have the same problem in a homebrew solution as well, so I think that's more of a strawman.
Stop using libraries you don't understand.
Stop using libraries you don't understand.
The boost people are much better at portable development than I am.
Suck, I agree.
I don't understand this one... unless you're referring to licenses, which you already mentioned.
The boost people are much better at maintaining their code than I am at recreating it from scratch.
the boost people... you get it.
I guess... our experiences have been different. I prefer to not reinvent the wheel, unless it's a particularly entertaining wheel.
Well, nothing... but based on the GP's usage of the phrase "JIT bytecode", my best guess is that he's talking about Python (compiles source code to bytecode "JIT") as opposed to Java (compiles bytecode to machine code JIT).
If I ever encounter software that looks like that in a business outside of compiler/language design or mathematics, my immediate reaction would be svn blame followed by an angry conversation with the guilty party. Just because it's possible to write software that's formally hard to prove things about doesn't mean it's good to do so.
You mean like the "not working here anymore" division?
Anyone who leaves a single hydra by itself deserves to lose it! Are you sure you're accounting for the nearby pair of burrowed zerglings (a.k.a "developer interns", to stay on topic)?
Sure, if you know the food has terrible things in it, don't eat it (and in this case, it looks like "vote with your wallet" is starting to work). But the mantra "If you can't pronounce it, don't eat it" is not the solution.
Or, you could spend a little bit of time to learn what the ingredient is, and then make your decision based off of information instead of FUD. Along those lines, I'd like to recommend What Einstein Told His Cook. It's quite interesting, and probably fairly accessible to most /. readers.
On windows? Try "everywhere". Some other poorly-named libraries that come to mind are libm.so and libiberty.so (as cute as gcc -liberty may be, it is a useless name from a functional standpoint). Or if you consider any file, what about any of the 3-letter UNIX-style directory names?
I would want to shoot any developer that used the phrase "Run-time library" or similar in the name of a DLL file. Windows DLLs are run-time libaries by definition. So we're down to WordGraphicsFunctions.dll. Or, since "functions" is a silly name (especially if you end up putting classes in the DLL or macros in the related header files), how about WordGraphics{Util,Tools}.dll or just WordGraphics.dll?
I concur. I used to work at an ISP. The topology at one site was basically "Ethernet Jack -- Building Switch -- Site-Wide Switch -- Core Router -- Internet Cloud". When viruses hit, it was the fiber (from building to core switch) that saturated first. A desktop machine was capable of taking out an entire block of apartments just by saturating the local switch. QoS in the core gear wouldn't help at all if one of the building switches was doing nothing but sending out spam.
I think that's the best phrase I've heard about Comcast ever. But on a serious note, think about the NSA wiretap room that AT&T had... that's gotta at least count as Orthanc or something.