- Each compilation unit can be compiled in isolation, assuming you have certain information about the referenced code. (Granted, this is C, so the compilation units are pretty large.) - You can assemble a fair bit of information about each section of code -- enough to parallelize much of the conversion to IR -- in parallel. You will need to block on other processes at times, though. - Each function can be optimized in isolation.
Of course, compilers are moving toward analyzing multiple files (ideally entire programs) at once to improve their optimization, which is somewhat at odds with parallel multicore compilation. e.g. optimizing functions in isolation isn't good enough for many modern optimization techniques.
not only do they have assets, but thanks to their every-citizen-has-a-battle-rifle-in-his-closet policy...
There is no such policy. There _used_ to be a policy of allowing those citizens who so desired to keep their rifles and ammo after they got out of military service (it was never "every citizen", and the full-auto capacity on the rifle was disabled).
It's my understanding that while you can still keep the rifle, they've stopped allowing ammunition in the home as of a few years back (after Corinne Rey-Bellet, a ski champion, was shot by her husband with a military rifle and ammo), so the rifles are far from battle-ready. I'd welcome any details or links, since info is scarce.
And desegregates and reverberates must be okay, right?
Re:Hey, remember when Ender's Game was good?
on
Ender in Exile
·
· Score: 2, Insightful
I realize we left the realm of rational thought behind a while ago, and are now waging fan warfare (I'm ok with this, it's fun, but one has to recognize it for what it is;)), but I do feel compelled to make a serious point here: just because more people agree with you than me doesn't make you right, and me wrong. Art being a subjective medium, tastes in art can't be wrong or right.
No, but being a subjective medium means that appeals to consensus are much more useful than idiosyncratic opinions. If I'm trying to figure out what movie to watch, knowing that a lot of people consider the Godfather to be a great film is more likely to get me to watch it than one person saying that Weekend at Bernie's II was better.
The individual opinion is useful, though, if: a) I have some reason to think that person's taste is more aligned with my own than popular consensus (e.g. I know a lot of other stuff they like and dislike, and what appeals to them seems akin to what appeals to me); or b) They offer a compelling explanation as to why they have their preference, and that explanation seems to coincide with my own foibles; c) They are offering up a little-known example such that there isn't much consensus about its quality.
There should probably be more entries on this list, but those are the 3 that immediately come to mind.
The "stretching reduces injury" canard has been disproven in study after study. Warming up may have some benefit, but stretching isn't the way to go if you're worried about injuries.
As it turned out, stretching during warm-up had no statistically significant effect on the risk of injury, either for soft-tissue problems or bony disorders...Although pre-exercise stretching was totally unimportant from an injury standpoint, other easy-to-determine factors actually did a decent job of prognosticating who would get hurt. For example, age was a good predictor of injury (the older the athlete, the higher the injury frequency)...In addition, 20-metre shuttle-run time was an outstanding predictor (the faster the time, the lower the risk of injury), a relationship which suggested that overall fitness -- not the presence or absence of pre-workout stretching -- had the paramount influence on injury occurrence
Personally, I solve this by a) when it's the same project, fixing every caller in one go, or b) when it's a separate project, treating FooLib as its own product. When a team is ready for a new library, they can upgrade.
Well, I'm talking about an internal library that only our team uses. We go through this all the time. When we can, we pull out libraries into separate "products", but there's always a blurred line between "a method that gets called from another class" and "this is a self-contained library that's external to the product".
The point is, if you're doing serious re-architecting of the code you can wind up having a portion of the product that's converted over and tested.
You can either bottleneck it at one programmer making sure he understands every place that interfaces with the change, and how to change them to work with the new semantics, or you can let those familiar with the callers work in parallel to update them. The latter is often a much more efficient use of programmer talents, and is facilitated by a development branch.
This is generally the kind of thing where I pair. If I don't know enough to do the job on my own and neither do they, then it seems to make more sense to work together.
In the case I outlined, neither side "doesn't know enough". You're just firewalling the testing from the code development so that you get a different brain writing the tests from the code.
Here I'd favor automating the acceptance tests, plus pair programming and possibly other quality-oriented practices. There's still some risk of a bug, but it's pretty low. Branching means a doubling of the test effort, as you have to test both before merge and after.
Usually you pull master into the dev branch before you test; you've already merged, but you haven't supplanted master until post-testing.
And even where automated testing is feasible, you normally want a sanity check by a human tester ("Yeah, it has the right text there, but for some reason it's now in large green!" or "Whoah, that's a glaringly obvious omission from the test suite"). I'm all about writing tests up front, but even the best programmers occasionally miss something and merging into master before getting human testers to look at things is a bit irrational, IMO.
Meh. If you do a "git status" and see that the 3 files you want to commit are the only changed ones, there's no reason not to use "git commit -a" rather than copying the filenames over explicitly.
As long as you know exactly what you're committing, exactly how you spell the commit command doesn't matter.
I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?
Not always.
In the real world, a development branch often requires coordination between multiple programmers; I change the broken API to FooLib. I know that this breaks the callers, but that's okay because we're working in the "big changes to FooLib" branch. I test that FooLib 2.0 works okay, then check it in to the dev branch. The rest of the team updates their code bases which use FooLib to the new APIs and check them in. Nothing's merged into any live branch until it's all integrated and tested. In the meantime, the stable branch continues to work.
Or I write the tests for the new refactor, commit them (all broken), and then another programmer pulls them down and does the refactor. In the meantime, you still have a working test suite for the stable branch that's not showing false negatives.
That's even leaving aside the much more obvious cases of "this is a massive change that's going to result in several days' breakage as we all work through it", where you have several developers who need to coordinate their efforts (and probably use many of the tools that a decent VCS gives them) and also don't want to have floating changes sitting outside the repository for days at a time (in case, say, a dev gets the flu and you need to continue working without trying to get at his personal machine or duplicate his work).
And, of course, even if you write decent tests and are cautious about commits, it's entirely possible that you'll miss some bug (it may only show up in a certain environment, or you missed an obvious test case, or whatever). On even a medium-sized project, you don't want to supplant the stable code until there's been a whole heck of a lot more testing than just one programmer who thinks he's written good tests and done plenty of his own integration testing.
Heck, you may even need to support the users who are running the old code for a long time, and have to keep doing bug fixes for them while most of the world is on the newer codebase.
Microsoft is now pushing for Python as a de-facto standard scripting language for.NET (with Ruby as an option) - there's a reason why the DLR namespaces are "Microsoft.Scripting.*". They're also recommending it as a language of choice for Silverlight projects (which is probably part of the same strategy). Research/vanity project? Hardly...
Huh? That's exactly what "vanity project" means--Microsoft is pushing it to be able to say "hey, look, it runs on.NET". That's their own platform. It's a vanity check-box point.
My last 3 jobs (including the current one) have all been basically full-time Python development. I go to PyCon every year. While there's occasional buzz about things like Jython/JPython and IronPython, 95% of the Python developers I talk to have never considered them for serious use. They're cool to point to and say "hey, we _could_ work in the same VM with X and Y". But nobody ever does; it's easier to make web services calls, synchronize in the database, or do all the other standard stuff that lets you use the full libraries of your own language (just as other languages have done for decades).
Have you actually seen performance comparisons for e.g. CPython vs IronPython, or, better yet, Ruby vs JRuby?
Yes, and CPython wins vs. IronPython in a landslide for every real-world app I've tried.
IronPython wins a few number-crunching benchmarks that have little real world applicability because 1) they never test against numpy, which any serious numeric user of python uses 2) they ignore the massive dominance of CPython in I/O (especially in reading/writing to sockets), when for the majority of web apps I/O takes the lion's share of compute resources; and 3) they ignore the existence of psyco
If you're going to do a few tightly-looped numerics without talking to the network or database, IronPython will stomp the floor with raw CPython; once you add in reading from the web/database and writing out, CPython gets the lead back handily for everything I've worked on. And in real life when you throw "import psyco" and "psyco.profile()" at the top of your handful of computationally expensive files (or, if they're math-intensive, use numpy) then traditional python apps tend to beat IronPython even without factoring in the much, much faster I/O.
That said, I'm sure that there are some apps where IronPython is the fastest choice. For those, by all means use it. In general, though, they tend to tout a few microbenchmarks taken out of any context far, far too much. It's the same cycle we went through with JPython/Jython, which published a few faster benchmarks and yelled loudly about them while real-world developers kept using CPython in large part because it was much faster for real-world apps.
The problem is that existing interpreters do have major performance/scalability problems (GIL, threading roughly bolted-on, etc).
You really don't want to bring up parallel processing if you're trying to make a case for the CLI or JVM over the standard python VM. That is a horrible, horrible weakness of both platforms.
Unlike C# or Java, Python has strong support for multiprocessing. It's only gotten better with the multiprocessing module in 2.5 and later.
Threads are pretty dangerous in that they throw out memory protection between each other. They're valuable in some limited cases (e.g. a limited humber of threads based on the number of cores available to handle network connections available, when you need to throw protected memory out the window), but the Python interpreter doesn't hold the GIL on I/O or most of the other areas where multithreading makes sense. Opponents like to yell "GIL! GIL!", but in reality there's no global lock held when, say, you read from a network socket, run a regex compare, talk to the database, or do any of the other common things where threads need to contend.
That's really a side point, though, since even if the GIL _did_ block all of those thin
That's somewhat reasonable, though if you're trying to teach programming paradigms I think there's a _massive_ difference between teaching MIPS (or MMIX or any other asm/pseudo-asm) versus using C or C++ to teach mid-level pointer driven programming.
I could easily see using C++ in the Java/C# category, but at the same time C fills another "programming style" category that is distinct from any ASM, and C++ is general enough that it's the only other truly mainstream language that could really fill that role.
Ultimately, though, I think I'd agree with you; C is unique, and possibly the only language where nothing else is really in its niche. That "mid-level pointer-driven paradigm" really means that any consummate programmer will learn C, and as you say C++ just doesn't really fill the same niche.
As such, C is possibly the _only_ language that I think pretty much every top-tier programmer I've known has a strong grasp of. I was trying to force C++ into the conversation, but you're right that it doesn't belong. In retrospect, C++ hasn't really had anywhere near the widespread knowledge among great programmers I've known that C has; it's kind of is another statically typed OO language competing with Ada/Java/etc; even though it easily _could_ be in that mid-level tier (in a way that, say, Java couldn't be), in practice it really isn't.
So, yeah, you've convinced me. I was trying not to be too biased toward only one language in a category, but ultimately C is a special case.
I guess I'd drop C++ entirely from the "languages to learn" list, and leave the mid-level pointer-driven languages tier to C alone. That seems sad, but really you're right; C++ doesn't have the kind of paradigm-specific traction that many of the other languages under discussion do.
You should have clarified you did not mean production there.
I thought from context it was pretty obvious (most people aren't going to be learning a ton of languages for the first time in a commercial production environment), but obviously I was wrong--at any rate, we've got that cleared up now.
But anyway, what do you consider an appropriate size for such a project, then?
Personally, the first thing I do when I'm learning a language, I write Conway's Game of Life in it.
It's a neat problem that captures a lot, and is probably about the right size for a first program in a new language (for an experienced programmer). Depending on the language/paradigm it might be worth doing something else (that's targeted toward the problem domain, to help see a common case where choosing that paradigm makes sense) as well.
Exposure is fine, but "at least a project or two"?
A project or two seems about the minimum to learn a language. It's pretty much impossible to really learn a language without writing _something_ in it.
How many production projects in Eiffel, or Sather, or Ada, or Erlang, have you, or at least some people you know personally, taken part in?
This seems like a strawman; most learning projects are a lot smaller than anything production (e.g. compare your compiler design class in university with gcc).
The point of learning a lot of languages is mainly for exposure to multiple programming paradigms (hence why I split things up that way). Even if you never use the language itself at work, it's a lot easier to get your head around, say, functional programming by going through ML culture shock than trying to write a functional program in Java when you don't really know what that means. Once you know it, you can do it in any language.
But to answer the question: I know dozens of people who are working (or have worked) on Ada projects, and I've done so in the past.
One of our developers left our company 3 months ago to work on a commercial Erlang product, making him the 2nd I know, and we're considering using it at my current workplace.
I don't personally know anyone using Sather or Eiffel commercially.
Just how do you manage to put C and C++ in the same category? C++ is definitely not 'mid-level pointer driven'. It's multi-paradigm (including the o-o, generic & functional paradigms).
As I noted, many of those languages can be used in a lot of different ways. But if you're trying to teach pointers, C and C++ are by far the most common languages for doing so.
Sooner or later, if you want to be stuck in programming for all your life, you'll notice that - in projects people are willing to pay money for - you more or less use two or three languages, max.
I absolutely disagree. It's nice to think that you might just be able to stick with one or two languages and work on just the code-base you're developing, but at every job I've worked there's significant exposure to lots of other systems, and unless you can deal with them in a pretty substantial way you're liable to be stuck as a junior-level coder indefinitely.
The 4-month consulting gig I was on between my previous job and my current one used the fewest languages of any real-world gig I've had. C, Perl, Python, Ada, awk, sh.
At the previous job we worked with C, C++, Java, Python, Perl, awk, VB, and at the very end were starting in with C# (brand new c. 2000).
At my current job I've used C, C++, Python, Perl, Common Lisp, awk, sh, Cold Fusion, VBscript, Actionscript, and Javascript (as well as a few domain-specific languages, SQL, and markup languages).
Sure, 95% of the day-to-day stuff is in 2-3 languages, but the other stuff comes up when integrating with outside projects (be they company-internal or not), troubleshooting the larger system of which our primary product is only one key part, helping the web designers do something trickier than usual with their Javascript/Flash, etc.
!necessary: The three best developers I have known just concentrate on delivering software to the clients needs. They all used their favorite language, and squeezed the most out of that language.
IME, the best developers may use only a few languages but they have exposure to many. The point of learning a wide range is more to learn different programming paradigms than anything else.
I think you meant logic or declarative programming.
Yes, you're the first of several to point that error out.
I'd consider the minimum for a really good programmer to include at least a project or two's worth of exposure to:
At least one assembly language or pseudo-asm. At least one mid-level pointer-driven language (C/C++/etc) At least one statically typed functional language (ML/Haskell/etc) At least one dynamically typed functional language (Lisp/Scheme/etc) At least one dynamically typed OO language (Smalltalk/Python/ruby/etc) At least one higher-level statically typed OO language (Java/Ada/C#/etc)
That still leaves some holes that could be tricky to pick up, and ideally you'd know: At least one stack-based language (Forth/Postscript/etc) At least one imperative programming language (Prolog/etc) At least one DBC-centered language (Eiffel/Sather/etc) At least one concurrency-oriented language (erlang, etc)
But you can have a long and successful career as a top-shelf programmer without really needing that latter group.
And yes, those monikers are a bit arbitrary; you can do full OO in Lisp, functional programming in Python, etc. So you can get away with a lot fewer languages than there are on the list, as long as you learn the different programming models. It tends to be a little easier to learn a model with a language that's been used that way traditionally.
Just because Bush claims to be a conservative doesn't mean he actually is one!
The US has an incredibly interventionist foreign policy, and Americans haven't experienced a free market for almost a century.
Historically, that _is_ conservative. Free markets are a hallmark of classical liberalism. Around much of the world outside the US, politics, that's still what those words mean.
The "normative core" of classical liberalism is the idea that laissez-faire economics will bring about a spontaneous order or invisible hand that benefits the society, though it does not necessarily oppose the state's provision of a few basic public goods...Several liberals, including Adam Smith, and Richard Cobden, argued that the free exchange of goods between nations could lead to world peace.
Bush has a lot more historical standing in claiming to be a conservative than a laissez-faire National Review follower would, and certainly he's been socially conservative (an area where, as opposed to economics, there isn't a huge difference of opinions over what's liberal and what's conservative).
I think it's more that IronPython is basically a vanity/research project, akin to JPython/Jython a few years ago; very few people use it in practice, since the standard Python interpreter runs just fine on Windows and lets you avoid significant compatibility problems (and use all the packages that the rest of the Python world uses, seamlessly).
These "other language on my interpreter" projects _seem_ really cool, but in practice it's usually simpler and faster (both development and performance wise) to use the languages in their own interpreters and use some IPC/RPC/web services/etc to communicate with.NET (or Java, or whatever) rather than trying to shoehorn your language onto the CLI or JVM.
python + wxpython for the GUI (with wxglade as the gui-builder). If you follow the wxwindows standards the UI will have native look and feel on Windows, GNOME, and Mac machines (including more major differences like the menubar being in the window on Windows/GNOME at at the top of the screen on Macs).
The improved whisky is then transferred to a bottle with a better label, and typically served "on the rocks" to morons who can't taste the difference anyway.
It would not work on whiskey, since that is usually consumed at room temperature (perhaps with a drop of water, but no ice), and the slight imbalance of flavours due to addition of tea might well be detected by a knowledgeable palate.
Huh?
I'm assuming that you mean: Whisky = Scotch Whiskey = Irish, Bourbon, Tennessee, etc
If that's true, the latter is far more likely to be served on the rocks than the former--though a good whiskey like a 1792 Ridgemont Reserve Bourbon or Bushmill's 10 year Single Malt Irish Whiskey is best served Scotch-style (no ice, a drop or two of water, and a bad Scotch is best on ice.
I stopped having a swap partition about 7 years ago (whenever my machine's RAM hit the 256MB mark and RAM really stopped being an issue). RAM is copious enough that swap's not needed to run everything I want, and I like not having the chance of swapping sensitive information out to non-volatile storage.
Some of the suspend-to-disk packages need (or have needed) swap to work well, but most of the machines I run don't bother with swap nowadays.
I've never seen a relevant test, but I would expect that a contract that attempts to stifle the freedom of speech of one its parties would be very difficult to enforce, except in very specific circumstances. Such circumstances would probably include stuff like near-equality of bargaining power between the parties, which isn't the case here (where there's a producer/consumer relationship). Contracts that cannot be simply terminated without leaving behind residual obligations are harder to form, too.
FWIW, contracts that purport to restrict one party's freedom of speech (unilaterally, even in click-through licenses) are very common. In particular, prohibiting the publication of any timing or benchmark results is a common license clause (see, e.g., http://www.oracle.com/technology/software/popup-license/instant_client_lic.html (6) or most big database and a lot of other software packages).
If someone is really that horrible, how are you supposed to let the other employer know without being sued?
Assuming they use the same 4 questions that it seems everyone's used for the last 10 years, it's easy.
Them: Did he/she work at your company? You: Yes. Them: During what time frame? You: August 2000-October 2003 Them: What was their title/position? You: Senior Software Engineer Them: Would you hire them again? You: No. Them: Thanks for your time, bye.
At the same time that people stopped being willing to say anything about the referent than confirm employment as title X during a timeframe, everyone started asking "Would you hire them again?". It's safe enough that the government and most big companies let you answer yes/no without fear of being sued--you're not saying anything about them, you're not alleging incompetence, you're really talking about yourself.
At the same time, it's pretty obviously the same as the old (now deprecated for fear of lawsuits) "Is there anything else I should know about them?". They're both basically circumlocutions for "Did they suck?".
Slashdot Mirror
- Each compilation unit can be compiled in isolation, assuming you have certain information about the referenced code. (Granted, this is C, so the compilation units are pretty large.)
- You can assemble a fair bit of information about each section of code -- enough to parallelize much of the conversion to IR -- in parallel. You will need to block on other processes at times, though.
- Each function can be optimized in isolation.
Of course, compilers are moving toward analyzing multiple files (ideally entire programs) at once to improve their optimization, which is somewhat at odds with parallel multicore compilation. e.g. optimizing functions in isolation isn't good enough for many modern optimization techniques.
not only do they have assets, but thanks to their every-citizen-has-a-battle-rifle-in-his-closet policy...
There is no such policy. There _used_ to be a policy of allowing those citizens who so desired to keep their rifles and ammo after they got out of military service (it was never "every citizen", and the full-auto capacity on the rifle was disabled).
It's my understanding that while you can still keep the rifle, they've stopped allowing ammunition in the home as of a few years back (after Corinne Rey-Bellet, a ski champion, was shot by her husband with a military rifle and ammo), so the rifles are far from battle-ready. I'd welcome any details or links, since info is scarce.
And desegregates and reverberates must be okay, right?
I realize we left the realm of rational thought behind a while ago, and are now waging fan warfare (I'm ok with this, it's fun, but one has to recognize it for what it is ;)), but I do feel compelled to make a serious point here: just because more people agree with you than me doesn't make you right, and me wrong. Art being a subjective medium, tastes in art can't be wrong or right.
No, but being a subjective medium means that appeals to consensus are much more useful than idiosyncratic opinions. If I'm trying to figure out what movie to watch, knowing that a lot of people consider the Godfather to be a great film is more likely to get me to watch it than one person saying that Weekend at Bernie's II was better.
The individual opinion is useful, though, if:
a) I have some reason to think that person's taste is more aligned with my own than popular consensus (e.g. I know a lot of other stuff they like and dislike, and what appeals to them seems akin to what appeals to me); or
b) They offer a compelling explanation as to why they have their preference, and that explanation seems to coincide with my own foibles;
c) They are offering up a little-known example such that there isn't much consensus about its quality.
There should probably be more entries on this list, but those are the 3 that immediately come to mind.
The "stretching reduces injury" canard has been disproven in study after study. Warming up may have some benefit, but stretching isn't the way to go if you're worried about injuries.
One study is at http://www.sportsinjurybulletin.com/archive/stretching-exercises.html
As it turned out, stretching during warm-up had no statistically significant effect on the risk of injury, either for soft-tissue problems or bony disorders...Although pre-exercise stretching was totally unimportant from an injury standpoint, other easy-to-determine factors actually did a decent job of prognosticating who would get hurt. For example, age was a good predictor of injury (the older the athlete, the higher the injury frequency)...In addition, 20-metre shuttle-run time was an outstanding predictor (the faster the time, the lower the risk of injury), a relationship which suggested that overall fitness -- not the presence or absence of pre-workout stretching -- had the paramount influence on injury occurrence
Yes. The US Supreme Court upheld the practice (again) just this month.
http://news.yahoo.com/s/ap/20081006/ap_on_go_su_co/scotus_divided_juries
The Supreme Court has rejected a plea by a convicted murderer to require that jury verdicts be unanimous in all criminal cases.
Two states, Louisiana and Oregon, allow people to be convicted of some crimes despite disagreement among jurors.
Personally, I solve this by a) when it's the same project, fixing every caller in one go, or b) when it's a separate project, treating FooLib as its own product. When a team is ready for a new library, they can upgrade.
Well, I'm talking about an internal library that only our team uses. We go through this all the time. When we can, we pull out libraries into separate "products", but there's always a blurred line between "a method that gets called from another class" and "this is a self-contained library that's external to the product".
The point is, if you're doing serious re-architecting of the code you can wind up having a portion of the product that's converted over and tested.
You can either bottleneck it at one programmer making sure he understands every place that interfaces with the change, and how to change them to work with the new semantics, or you can let those familiar with the callers work in parallel to update them. The latter is often a much more efficient use of programmer talents, and is facilitated by a development branch.
This is generally the kind of thing where I pair. If I don't know enough to do the job on my own and neither do they, then it seems to make more sense to work together.
In the case I outlined, neither side "doesn't know enough". You're just firewalling the testing from the code development so that you get a different brain writing the tests from the code.
Here I'd favor automating the acceptance tests, plus pair programming and possibly other quality-oriented practices. There's still some risk of a bug, but it's pretty low. Branching means a doubling of the test effort, as you have to test both before merge and after.
Usually you pull master into the dev branch before you test; you've already merged, but you haven't supplanted master until post-testing.
And even where automated testing is feasible, you normally want a sanity check by a human tester ("Yeah, it has the right text there, but for some reason it's now in large green!" or "Whoah, that's a glaringly obvious omission from the test suite"). I'm all about writing tests up front, but even the best programmers occasionally miss something and merging into master before getting human testers to look at things is a bit irrational, IMO.
Meh. If you do a "git status" and see that the 3 files you want to commit are the only changed ones, there's no reason not to use "git commit -a" rather than copying the filenames over explicitly.
As long as you know exactly what you're committing, exactly how you spell the commit command doesn't matter.
The teams I have run recently have defect-in-production rates below one per developer-month.
Or, to rephrase, even _your_ team is unable to produce stable code every time they check in.
I agree that's popular, but I don't think it's a good idea. Wouldn't it be better to have every check-in be stable?
Not always.
In the real world, a development branch often requires coordination between multiple programmers; I change the broken API to FooLib. I know that this breaks the callers, but that's okay because we're working in the "big changes to FooLib" branch. I test that FooLib 2.0 works okay, then check it in to the dev branch. The rest of the team updates their code bases which use FooLib to the new APIs and check them in. Nothing's merged into any live branch until it's all integrated and tested. In the meantime, the stable branch continues to work.
Or I write the tests for the new refactor, commit them (all broken), and then another programmer pulls them down and does the refactor. In the meantime, you still have a working test suite for the stable branch that's not showing false negatives.
That's even leaving aside the much more obvious cases of "this is a massive change that's going to result in several days' breakage as we all work through it", where you have several developers who need to coordinate their efforts (and probably use many of the tools that a decent VCS gives them) and also don't want to have floating changes sitting outside the repository for days at a time (in case, say, a dev gets the flu and you need to continue working without trying to get at his personal machine or duplicate his work).
And, of course, even if you write decent tests and are cautious about commits, it's entirely possible that you'll miss some bug (it may only show up in a certain environment, or you missed an obvious test case, or whatever). On even a medium-sized project, you don't want to supplant the stable code until there's been a whole heck of a lot more testing than just one programmer who thinks he's written good tests and done plenty of his own integration testing.
Heck, you may even need to support the users who are running the old code for a long time, and have to keep doing bug fixes for them while most of the world is on the newer codebase.
Microsoft is now pushing for Python as a de-facto standard scripting language for .NET (with Ruby as an option) - there's a reason why the DLR namespaces are "Microsoft.Scripting.*". They're also recommending it as a language of choice for Silverlight projects (which is probably part of the same strategy). Research/vanity project? Hardly...
Huh? That's exactly what "vanity project" means--Microsoft is pushing it to be able to say "hey, look, it runs on .NET". That's their own platform. It's a vanity check-box point.
My last 3 jobs (including the current one) have all been basically full-time Python development. I go to PyCon every year. While there's occasional buzz about things like Jython/JPython and IronPython, 95% of the Python developers I talk to have never considered them for serious use. They're cool to point to and say "hey, we _could_ work in the same VM with X and Y". But nobody ever does; it's easier to make web services calls, synchronize in the database, or do all the other standard stuff that lets you use the full libraries of your own language (just as other languages have done for decades).
Have you actually seen performance comparisons for e.g. CPython vs IronPython, or, better yet, Ruby vs JRuby?
Yes, and CPython wins vs. IronPython in a landslide for every real-world app I've tried.
IronPython wins a few number-crunching benchmarks that have little real world applicability because
1) they never test against numpy, which any serious numeric user of python uses
2) they ignore the massive dominance of CPython in I/O (especially in reading/writing to sockets), when for the majority of web apps I/O takes the lion's share of compute resources; and
3) they ignore the existence of psyco
If you're going to do a few tightly-looped numerics without talking to the network or database, IronPython will stomp the floor with raw CPython; once you add in reading from the web/database and writing out, CPython gets the lead back handily for everything I've worked on. And in real life when you throw "import psyco" and "psyco.profile()" at the top of your handful of computationally expensive files (or, if they're math-intensive, use numpy) then traditional python apps tend to beat IronPython even without factoring in the much, much faster I/O.
That said, I'm sure that there are some apps where IronPython is the fastest choice. For those, by all means use it. In general, though, they tend to tout a few microbenchmarks taken out of any context far, far too much. It's the same cycle we went through with JPython/Jython, which published a few faster benchmarks and yelled loudly about them while real-world developers kept using CPython in large part because it was much faster for real-world apps.
The problem is that existing interpreters do have major performance/scalability problems (GIL, threading roughly bolted-on, etc).
You really don't want to bring up parallel processing if you're trying to make a case for the CLI or JVM over the standard python VM. That is a horrible, horrible weakness of both platforms.
Unlike C# or Java, Python has strong support for multiprocessing. It's only gotten better with the multiprocessing module in 2.5 and later.
Threads are pretty dangerous in that they throw out memory protection between each other. They're valuable in some limited cases (e.g. a limited humber of threads based on the number of cores available to handle network connections available, when you need to throw protected memory out the window), but the Python interpreter doesn't hold the GIL on I/O or most of the other areas where multithreading makes sense. Opponents like to yell "GIL! GIL!", but in reality there's no global lock held when, say, you read from a network socket, run a regex compare, talk to the database, or do any of the other common things where threads need to contend.
That's really a side point, though, since even if the GIL _did_ block all of those thin
That's somewhat reasonable, though if you're trying to teach programming paradigms I think there's a _massive_ difference between teaching MIPS (or MMIX or any other asm/pseudo-asm) versus using C or C++ to teach mid-level pointer driven programming.
I could easily see using C++ in the Java/C# category, but at the same time C fills another "programming style" category that is distinct from any ASM, and C++ is general enough that it's the only other truly mainstream language that could really fill that role.
Ultimately, though, I think I'd agree with you; C is unique, and possibly the only language where nothing else is really in its niche. That "mid-level pointer-driven paradigm" really means that any consummate programmer will learn C, and as you say C++ just doesn't really fill the same niche.
As such, C is possibly the _only_ language that I think pretty much every top-tier programmer I've known has a strong grasp of. I was trying to force C++ into the conversation, but you're right that it doesn't belong. In retrospect, C++ hasn't really had anywhere near the widespread knowledge among great programmers I've known that C has; it's kind of is another statically typed OO language competing with Ada/Java/etc; even though it easily _could_ be in that mid-level tier (in a way that, say, Java couldn't be), in practice it really isn't.
So, yeah, you've convinced me. I was trying not to be too biased toward only one language in a category, but ultimately C is a special case.
I guess I'd drop C++ entirely from the "languages to learn" list, and leave the mid-level pointer-driven languages tier to C alone. That seems sad, but really you're right; C++ doesn't have the kind of paradigm-specific traction that many of the other languages under discussion do.
You should have clarified you did not mean production there.
I thought from context it was pretty obvious (most people aren't going to be learning a ton of languages for the first time in a commercial production environment), but obviously I was wrong--at any rate, we've got that cleared up now.
But anyway, what do you consider an appropriate size for such a project, then?
Personally, the first thing I do when I'm learning a language, I write Conway's Game of Life in it.
It's a neat problem that captures a lot, and is probably about the right size for a first program in a new language (for an experienced programmer). Depending on the language/paradigm it might be worth doing something else (that's targeted toward the problem domain, to help see a common case where choosing that paradigm makes sense) as well.
Exposure is fine, but "at least a project or two"?
A project or two seems about the minimum to learn a language. It's pretty much impossible to really learn a language without writing _something_ in it.
How many production projects in Eiffel, or Sather, or Ada, or Erlang, have you, or at least some people you know personally, taken part in?
This seems like a strawman; most learning projects are a lot smaller than anything production (e.g. compare your compiler design class in university with gcc).
The point of learning a lot of languages is mainly for exposure to multiple programming paradigms (hence why I split things up that way). Even if you never use the language itself at work, it's a lot easier to get your head around, say, functional programming by going through ML culture shock than trying to write a functional program in Java when you don't really know what that means. Once you know it, you can do it in any language.
But to answer the question:
I know dozens of people who are working (or have worked) on Ada projects, and I've done so in the past.
One of our developers left our company 3 months ago to work on a commercial Erlang product, making him the 2nd I know, and we're considering using it at my current workplace.
I don't personally know anyone using Sather or Eiffel commercially.
Just how do you manage to put C and C++ in the same category? C++ is definitely not 'mid-level pointer driven'. It's multi-paradigm (including the o-o, generic & functional paradigms).
As I noted, many of those languages can be used in a lot of different ways. But if you're trying to teach pointers, C and C++ are by far the most common languages for doing so.
Sooner or later, if you want to be stuck in programming for all your life, you'll notice that - in projects people are willing to pay money for - you more or less use two or three languages, max.
I absolutely disagree. It's nice to think that you might just be able to stick with one or two languages and work on just the code-base you're developing, but at every job I've worked there's significant exposure to lots of other systems, and unless you can deal with them in a pretty substantial way you're liable to be stuck as a junior-level coder indefinitely.
The 4-month consulting gig I was on between my previous job and my current one used the fewest languages of any real-world gig I've had. C, Perl, Python, Ada, awk, sh.
At the previous job we worked with C, C++, Java, Python, Perl, awk, VB, and at the very end were starting in with C# (brand new c. 2000).
At my current job I've used C, C++, Python, Perl, Common Lisp, awk, sh, Cold Fusion, VBscript, Actionscript, and Javascript (as well as a few domain-specific languages, SQL, and markup languages).
Sure, 95% of the day-to-day stuff is in 2-3 languages, but the other stuff comes up when integrating with outside projects (be they company-internal or not), troubleshooting the larger system of which our primary product is only one key part, helping the web designers do something trickier than usual with their Javascript/Flash, etc.
!necessary: The three best developers I have known just concentrate on delivering software to the clients needs. They all used their favorite language, and squeezed the most out of that language.
IME, the best developers may use only a few languages but they have exposure to many. The point of learning a wide range is more to learn different programming paradigms than anything else.
I think you meant logic or declarative programming.
Yes, you're the first of several to point that error out.
I'd consider the minimum for a really good programmer to include at least a project or two's worth of exposure to:
At least one assembly language or pseudo-asm.
At least one mid-level pointer-driven language (C/C++/etc)
At least one statically typed functional language (ML/Haskell/etc)
At least one dynamically typed functional language (Lisp/Scheme/etc)
At least one dynamically typed OO language (Smalltalk/Python/ruby/etc)
At least one higher-level statically typed OO language (Java/Ada/C#/etc)
That still leaves some holes that could be tricky to pick up, and ideally you'd know:
At least one stack-based language (Forth/Postscript/etc)
At least one imperative programming language (Prolog/etc)
At least one DBC-centered language (Eiffel/Sather/etc)
At least one concurrency-oriented language (erlang, etc)
But you can have a long and successful career as a top-shelf programmer without really needing that latter group.
And yes, those monikers are a bit arbitrary; you can do full OO in Lisp, functional programming in Python, etc. So you can get away with a lot fewer languages than there are on the list, as long as you learn the different programming models. It tends to be a little easier to learn a model with a language that's been used that way traditionally.
I'm sure I'm missing some areas, too.
Just because Bush claims to be a conservative doesn't mean he actually is one!
The US has an incredibly interventionist foreign policy, and Americans haven't experienced a free market for almost a century.
Historically, that _is_ conservative. Free markets are a hallmark of classical liberalism. Around much of the world outside the US, politics, that's still what those words mean.
http://en.wikipedia.org/wiki/Classical_liberalism
Bush has a lot more historical standing in claiming to be a conservative than a laissez-faire National Review follower would, and certainly he's been socially conservative (an area where, as opposed to economics, there isn't a huge difference of opinions over what's liberal and what's conservative).
I think it's more that IronPython is basically a vanity/research project, akin to JPython/Jython a few years ago; very few people use it in practice, since the standard Python interpreter runs just fine on Windows and lets you avoid significant compatibility problems (and use all the packages that the rest of the Python world uses, seamlessly).
These "other language on my interpreter" projects _seem_ really cool, but in practice it's usually simpler and faster (both development and performance wise) to use the languages in their own interpreters and use some IPC/RPC/web services/etc to communicate with .NET (or Java, or whatever) rather than trying to shoehorn your language onto the CLI or JVM.
python + wxpython for the GUI (with wxglade as the gui-builder). If you follow the wxwindows standards the UI will have native look and feel on Windows, GNOME, and Mac machines (including more major differences like the menubar being in the window on Windows/GNOME at at the top of the screen on Macs).
The improved whisky is then transferred to a bottle with a better label, and typically served "on the rocks" to morons who can't taste the difference anyway.
It would not work on whiskey, since that is usually consumed at room temperature (perhaps with a drop of water, but no ice), and the slight imbalance of flavours due to addition of tea might well be detected by a knowledgeable palate.
Huh?
I'm assuming that you mean:
Whisky = Scotch
Whiskey = Irish, Bourbon, Tennessee, etc
If that's true, the latter is far more likely to be served on the rocks than the former--though a good whiskey like a 1792 Ridgemont Reserve Bourbon or Bushmill's 10 year Single Malt Irish Whiskey is best served Scotch-style (no ice, a drop or two of water, and a bad Scotch is best on ice.
I stopped having a swap partition about 7 years ago (whenever my machine's RAM hit the 256MB mark and RAM really stopped being an issue). RAM is copious enough that swap's not needed to run everything I want, and I like not having the chance of swapping sensitive information out to non-volatile storage.
Some of the suspend-to-disk packages need (or have needed) swap to work well, but most of the machines I run don't bother with swap nowadays.
FWIW, contracts that purport to restrict one party's freedom of speech (unilaterally, even in click-through licenses) are very common. In particular, prohibiting the publication of any timing or benchmark results is a common license clause (see, e.g., http://www.oracle.com/technology/software/popup-license/instant_client_lic.html (6) or most big database and a lot of other software packages).
If someone is really that horrible, how are you supposed to let the other employer know without being sued?
Assuming they use the same 4 questions that it seems everyone's used for the last 10 years, it's easy.
Them: Did he/she work at your company?
You: Yes.
Them: During what time frame?
You: August 2000-October 2003
Them: What was their title/position?
You: Senior Software Engineer
Them: Would you hire them again?
You: No.
Them: Thanks for your time, bye.
At the same time that people stopped being willing to say anything about the referent than confirm employment as title X during a timeframe, everyone started asking "Would you hire them again?". It's safe enough that the government and most big companies let you answer yes/no without fear of being sued--you're not saying anything about them, you're not alleging incompetence, you're really talking about yourself.
At the same time, it's pretty obviously the same as the old (now deprecated for fear of lawsuits) "Is there anything else I should know about them?". They're both basically circumlocutions for "Did they suck?".