What ultimately put my mind at ease with regard to all of these "what ifs" is the recognition that cosmic rays routinely smash into the Earth with energies that we can still only dream of; for instance, see the Oh-My-God particle, an impact event still several orders of magnitude in energy above what we can produce in a lab. If an impact event could produce a black hole that could swallow a planet, the Solar System and indeed the entire universe would be nothing but a bunch of black holes of various sizes orbiting each other, as every massive body has long since been hit with at least one particle sufficient to start the black-hole or strangelet putative chain reaction.
Seeing as how every massive body in the universe has been hit with umpteen bajillion of these impacts, yet massive bodies remain, it would seem the probability of this occurring is effectively 0.
A priori, it's not necessarily a wrong idea. But the evidence is pretty clear that it's not a problem.
It's not the same word. "Mistake" is a generic term, covering things intentional and unintentional, a whole range of impacts of the error from trivial to catastrophic, and carries no information about admission of guilt.
"Brainos" are unintentional, freely admitted, generally minor errors.
Since we're communicating in English, which answers the "How do I indicate shades of meaning?" with "Lots and lots of words, all with slightly varying denotations", these little differences are very useful for precise, yet concise, communication. "Braino" fills in a hole, just as "pessimal" or a still-hypothetical gender-neutral third-person pronoun does.
I call things like that "brainos", in obvious analogy to "typos" where you have a "typing" problem. I know I am not the only one. My point is that there really isn't an official word for such things, but I don't really let that stop me.
Usually, when I use the word, it's in a coding context. "Yeah, I'm looking at this code and I know you have to check the return value of that function, I've done it a hundred times. I don't know why I forgot that time; must be a braino."
Even if I could choose my language, and I choose Ruby instead of Python, I'm still not ready to commit to Ruby on Rails for the size of application I'm talking about. I wouldn't have chosen Apache::ASP, either, but at least I've got it harnessed.
(Honestly, my problem hasn't been the frameworks, my problem has been people proving that you can write tightly-coupled spaghetti code in any environment if you don't watch them like a hawk. Ruby's no more the answer to that than what I've already got in place.)
If you still like the GPL v3, but don't like that clause, strike it. You can do this without controversy if you have full control of the code, or can get all contributors to sign off on it. (I'm assuming that with GPL v2, you left the "optional upgrade" clause in, or you have full control. Otherwise it's not an issue, as a license change would require consent from all contributors, at which point you can do anything you want.)
It ought to still be compatible with the GPL v3, which you might want to mention in your license, because even though you don't require the text in the binary, you're not violating your license by adding it. I'd add a clause that the user can optionally upgrade to the full GPL v3 as it might make it easier for them in the future to merge licenses.
You can release with whatever license you like.
Up to you, of course.
Personally, I've used the LGPL on something I wanted to use the LGPL, but since it was a Javascript library, I added a clause to clarify what I mean, since the LGPL is rather tightly bound to the idea of libraries that have to be compiled and "linked" to other compiled binaries, which doesn't apply to JS.
Functions lie like dogs. You can test the output of functions until you're blue in the face, but until you take a holistic view of the application and what it does, unit tests are more a salve for management's mind than a boon to developers.
And the solution is... "holistic" unit tests.
While it's true that unit tests have a hard time making that last little yard (mostly in the form of hardware output, like graphics on the screen or your example), you're not writing your unit tests correctly. It's a rare unit test for me that is the equivalent of checking that adding two numbers work correctly, and while those are useful in development, they very, very rarely ever break later. Pure arithmetic function are the easiest to write, in general, and they correspondingly have the smallest need for continuous automated testing. (Not zero, of course, just the smallest. And when they do break, boy howdy...!)
In your other example, you ask:
Can you verify that the input data was correctly injected into the database...
(and I cut the rest of this question off as it posits an incorrect approach.)
The answer to this is yes, although you need a good database and a good understanding of how they work. (Not "great", just good.) I have thousands of tests that verify that certain code correctly manipulates the database, and that verifies calling certain webpages correctly manipulates the database. It's only marginally harder than testing a traditional function. The key here is to do everything inside a transaction; perform the task, do your verification, then roll the entire transaction back. Then it doesn't affect your database (which should normally be the "test" database, of course), and as a side effect under all but the "READ-UNCOMMITTED" transaction level, allows you to have any number of copies of the same test(s) running against the exact same database.
I can't imagine writing a distributed database-based application without such tests. Well, I can, but it's no fun.
In a lot of database-based applications, since the database is the application, this goes a long way toward testing the entire app.
Your unit tests ought to cover everything but the hardware output, which is more the exception than the rule.
Part of the problem is the number of APIs that exist with no thought for testing, making it seem as if unit testing them is impossible. For example, a lot of GUI toolkits are a major pain in the ass because it's difficult or impossible to fully simulate pressing a key in them and then processing the event loop exactly once, after which you will see what happened. This is a limitation of the toolkit, though, not unit testing, one I fervently hope will someday be eliminated after my whining on Slashdot catches the eye of one of the GTK developers or something.
In other cases, you have to a little work, but it can be done. We use Apache::ASP, and it ships with a little Perl script that can run an ASP page outside of the webserver via a command line. Still not terribly useful, but I was able to take that script and turn it into something that accepts multiple requests over a pipe, and wrap another Perl module around it that manages the connection to make it easy to use. Now, in my unit tests, calling a web page looks just like calling a function. Unfortunately, the rollback idea doesn't trivially work here, but I have some other things in place to help with this. The upshot is my unit tests include whether entire web pages work. This is some damned fine testing, and it's caught plenty of bugs long before they get out to the user.
Sure, right on the periphery of some systems is hard to reach, but the vast majority of any system is perfectly managable.
You say you have "great pay", and you are thinking about taking a pay cut. Are you currently saving money at some significant rate per month? Everybody should be, but you're the canonical example of someone who should be.
If you've got a cushion stashed away, so that the startup can go under and you're not on the street in the next week, I'd strongly suggest jumping ship, for two reasons. One is that your current complaints are only going to become worse. The second is that you may find that you are in a career dead-end, relative to where you want to be. You hint at this; I confirm this.
If you can get equity in the startup (ask!), so much the better. (If you believe, you may even seal the deal with a bit of investment.)
If, on the other hand, despite your great pay you have no savings, my suggestion would be, pretend you're taking the pay cut now and start pocketing the difference, but unless you can make yourself extremely sure the startup is a "sure thing" for some period of time, skip it. You'll have to take on the next opportunity that comes by. Odds are extremely good there will be one.
(One aspect of savings that people seriously underestimate is how it frees you to take certain riskier opportunities as they come by. Spending every last dime traps you even before the "health catastrophe" or the "death in the family" or "sudden illness" or the other traditional sudden money drains.)
Where you go wrong in your post is you miss the key point of relativity. It is true that the Lorentz transform tells you how to go from one time dimension to another. What is not true is your assertion that the initial time dimension is privileged in the transform. The transform is fully symmetric, and in math, that's not just the observation that the two directions merely "look" the same, it is the observation that they are so thoroughly the same that there is no way to tell them apart. (Symmetry arguments are very a powerful tool in the mathematician's toolkit, one of the fundamental ones.)
What this professor is claiming is quite frankly relativity 101. For instance, it is directly addressed in Section 1-1 of Reflections on Relativity; right there in that last diagram is the idea of two distinct time axes with the only distinction between them being which one you happen to be the observer of. We're just barely out of the Preface, and in fact this book happens to develop the idea rather more slowly than some other references!
It takes a real genious to recognize that there is more than one time direction, and that it is "truly true" and not just mathematical sophistry or convenience. But the name of that genious is Albert Einstein, not Alex Mayer.
A slight modification of the "Google it" answer: Open a phonebook. There are like a million companies that do this sort of thing. Find one locally, because you're going to want to talk to them in person. Unless you live out in the complete boonies, you've got some near you.
Once you get going, if in fact you ever do, you may find you need to hire people, etc. That's up to you, and basically a constant no matter what. But if you've truly got everything laid out, you can hire one of these companies.
Your problem is that if you are not technically competent, you can't tell a good developer from one that can talk the talk, but not walk the walk. Hiring developers directly is not practical. This is a handicap no matter how you slice it, but this approach minimizes the risk, if you do due diligence on the company you choose.
Oh, and I hate to say it, but it's a good 99% bet in my experience that if you don't know how to code or program, you do not have it all figured out. But hey, it's your dime.
Is it a "Oh wow, look what I just discovered on xbox live! This is the first shmup I've ever seen and its the greatest one there is!"
Seriously, it's quite possible. The genre has been "dead" now for what, ten years? Yes, I know it wasn't truly dead, hence the scare quotes. But it certainly was something only old-school gamers even knew about, and then only some of those would develop a serious taste for them.
Not helping is the fact that some of the later iterations got increasingly focused on that market, which was very scary for newbies. I enjoyed Mars Matrix, but almost everyone I showed it to just had their eyes glaze over.
The lack of a cost-effective way to sell cheap games that people actually know about has been a problem. A lot of previously "dead" genres may get a shot in the arm. (Anybody up for some 2-D platforming on something other than a GBA/DS?)
than having to find all of my bugs (rather than 5% of them) through testing.
HOLY FUCK. 95% of your bugs are typing bugs?!?!?
What kind of incompetent programmer are you? Don't ever come to me looking for a job!
My experience in dynamically-typed languages over the last few years is that 5% at most are typing bugs, and I'd guess much closer to 1%.
Seriously, if the primary effect of using a dynamically typed language was to increase your bug rate by a factor of 20, don't you think we'd have, you know, noticed? Give us some credit. While you're at it, why not try it out for a few months, if that strawman argument is what is holding you back?
Re:Dynamic typing
on
Beyond Java
·
· Score: 5, Insightful
I don't understand as a developer what dynamic typing does to help a language, and what real world advantages it offers the developer.
Fact: Nothing is free.
Everyone will agree with that in principle, but few people have internalized it.
Static typing is not free. It makes you jump through hoops to type correct code. When you need to change a type, it's even more difficult, especially when it's not something you can search and replace. When changing requirements require you to refactor out some interface, this costs yet more.
The great failure in this debate between static typing people and dynamic typing ethusiasts largely arises from the fact that static typing people can only see the benefits of static typing, and only see the costs of dynamic typing. You particularly made reference to your own inablitity to see the benefits in your post.
You can't complete the debate until you admit to yourself that there are costs to static typing, and benefits to dynamic typing. Only then can you intelligently weigh the costs and benefits of each approach.
I think dynamic typing wins in the vast majority of cases not because "static typing has no advantages", but because static typing charges you through the nose for very, very dubious benefits. Yes, static type correctness catches bugs. But what kind of bugs does it catch? Type bugs. All in all, as someone working in dynamically typed languages exclusively for years now, that's just not the kind of bug I deal with very often. I have logic bugs, architecture bugs, library bugs (bleh! and no these aren't type bugs), comprehension bugs, specification bugs, but I just don't run into type bugs that often. Thus, "paying through the nose" to avoid this particular type of bug is not a compelling bargain.
You're almost always better off taking the development-speed gains of a dynamically-typed language, and learning the discipline to write good tests (which, incidentally, tend to be easier in those languages). Static type correctness has very little overlap with program correctness. (Neither is even a subset of one another; it's perfectly possible to have a completely correct program that does not meet some definition of "static type correctness".) (Elaboration by somebody else.)
There are rare calls for static type languages, where it is so important not to make any type errors, ever, that's it's worth the pain of using them. But it's pretty rare for most programmers. (Of course there are programmers who deal in that exclusively.)
One of the things that could conceivably tip the balance back in favor of static type correctness is if static type correctness becomes more cheap, perhaps with such things like better type inference. But few things are worth the unbelievably staggering price you pay in Java for static type correctness. If you've never used a dynamic language for long enough to see the benefits, you have no idea just how much you are paying.
Until someone shows me that all the code that I've written in dynamic languages that have served tens or hundreds of thousands of people are somehow riddled with type bugs that have somehow failed to cause my code to come crashing down, I'm going to continue to use dynamically-typed languages. The predictions of doom if you let go of static typing have so far shown themselves to just be fear-mongering, quite a lot of it (as far as I can tell) from people who learned in school that static typing was important and have never even tried anything else.
It is seductively easy for those of us who like to consider ourselves intelligent to assume greater intelligence will get more done, but there is precious little evidence that this works reliably, neither individually nor, even moreso, at a collective level.
What's needed is not more intelligence, but more wisdom.
As a sign of how poorly "wisdom" is doing lately as a concept... when's the last time you heard the word?
Betcha it's been a while. (At least on average across all people reading this comment.)
Sorry, I just can't believe that with over 50 years of cinema to choose from your top two are so recent.
In another context, I might make that very comment. And I do enjoy many, many other movies, and my top ten wouldn't be all in the last two years by any means. But I think that in the last three or four years, the maturity of special effects has allowed the creation of alternate worlds, where the special effects aren't the story at all, to be done to a degree not really feasible in earlier times. As I am a sucker for that sort of thing, it does tend to very legitimately load my favorites to the recent past.
The people remain constant; storytelling hasn't improved in the last ten years. If anything, the average storytelling that makes it to the silver screen has gotten worse. But those who use the technology, instead of being used by it, are using it to make what I consider to be wonderful movies.
Books don't have this effect, so my top selections would range all over the place. My favorite music ranges all over the past 300 years, but I do have to admit that in the hands of a person who uses the tech (and is not used by the tech), excellent music can be made today which couldn't be made 50 years ago. (I have been utterly surprised by some modern stuff.)
A valid criticism, but I hope this helps you understand a little.:)
Initially I was worried about this buyout. Pixar is responsible for my personal favorite film (The Incredibles, narrowly edging out Serenity).
But I was talking with some people about this last night and I realized something. First, Steve Jobs has had a lot of experience with the media industry thank to iTunes and his experience at Apple. Granted, that's more music than movies but I think the same basic forces are in play. I think he has a clear view of how both industries are, and the quality problems that Disney has, and the inevitable financial consequences that will eventually follow.
Second, Steve Jobs is an excellent businessman. I don't think he would trade 50+% of Pixar for 7% of Disney, unless he had some good reason to believe that Disney was going to be able to grow more than Pixar. The only way that would be true is if the merger deal included a lot of control over Disney by the Pixar crew, because clearly Business As Usual at Disney wasn't going to get it done.
I haven't heard about the specifics of the deal; maybe it's been covered, but the only clue I have is basically TFA (which I saw earlier). But it gives me a lot of hope. Still not convinced, but "hopeful" is a major improvement from when I figured that Disney would just kill the golden goose.
What in the name of their Dark Mother goddess will they do to us when they rise into our airy realm?... Us computer geeks are basically fucked
If you'd like to learn more about this, perhaps to better defend yourself in the future, I believe the Japanese have a huge selection of documentaries on this very subject.
You really need to be careful about throwing that point around in an argument, because it just as easily boomerangs back on you. Have you considered all the evidence that Global Warming isn't anything to worry about endlessly, or isn't Man-made, or isn't even happening to speak of (vs. perfectly normal cycles that will cause us to be screaming "GLOBAL COOLING!" again in 20 years)? Are you really sure that in this politically charged environment, all the climatologists are really sure, instead of agreeing with political consensus at the risk of losing their jobs (and what does a displaced climatologist do)?
My point is not that these things MUST be true, or even necessarily that they CAN be true. In fact, it's not about any of that stuff at all. My point is about that article you're waving around like it's your manhood; it's useless in an argument to quote it, because if you're partisan enough to claim that the truth is so obvious that your brain must just be editing out all contrary evidence because you're obviously just stupid, that's plenty of evidence that you're partisan enough to be affected too. Live by the sword, die by the sword.
No. The energy WILL disappear. Do not forget radiated heat. We won't send all the mass down at once, of course!
Across what, millions of years?
One way or another, you're dealing with huge numbers. Plus, since the rate of heat dissipation is proportional to the heat difference, if you insist on keeping the biosphere livable the entire time (spoilsport!), you're going to add some more factors of magnitude to the time it takes to dissipate the heat since you can't raise the temperature very far before it's unlivable down here; just a few hundred degrees renders the entire place unlivable. (And in this context "a few hundred degrees" is indeed "just".) We'd be engulfed by the sun long before we could move any significant amount of the moon to Earth. Yeah, I didn't do the math, but with these factors of magnitude involved, it's a safe bet.
(The Earth can actually hold onto heat pretty well, after all. Several billion years and only the top few miles have solidified; the rest remains really, really hot.)
To cart away even one millionth of one percent of the moon would require staggering amounts of energy. By the time we're dealing with that kind of energy, if we ever can (which I have my doubts about, at least in any way that would be useful for this task), I think we will be able to deal with the consequences.
Are you worried about whether if we do too much mining, we'll run out of crust on the Earth? Worrying about the Moon's mass is even sillier, since while there may be less moon, you're talking about actually removing the mass, something Earth mines don't have to do.
You'd also be talking about cosmic levels of heat here, because said "staggering amounts of energy" can't just disappear. Assuming you're talking about moving bits of the Moon to Earth (and not just flinging it uselessly into space) since the Earth is lower in a gravity well, all the mass will pick up the difference in gravitational potential between the Earth and the Moon, 100% in heat (since it won't move on the surface of the Earth, at least not for long). If you moved any cosmically significant amount of the Moon to the Earth, you'd make the surface of the Earth incandescent. (The exact temperature would vary depending on how much mass you're talking, but if you want to have some fun, take the gravitational potential difference of 1% of the mass of the moon, compute how much energy that is, then see how much heat that would add. It's a Big Number.) Until such time as Mankind is so powerful as to be able to revoke the laws of conservation of energy, at which point you can't predict effects anyhow, no significant amount of the Moon is going to get to Earth, at least not with a biosphere on Earth left to care.
The problem appears to be that the whole minority voice, blabla thing doesn't work out.
For a long time I echoed the "Two parties are bad" party line. But the more I think about it, the more it actually doesn't seem half-bad.
Our system tends to actively split down the middle. It's not coincidence, it's structural. While the minority party (today the Democrats) may be largely disenfranchised, by the very way our system works they will extremely rarely be in a huge minority. In the Senate, for instance, it's currently 55/44/1 (R/D/I), which means that only 6 seats have to change to change the controlling party, something that can definately happen. Due to Democratic structural failures (IMHO, and note that I am strictly speaking of the organizational structure of the party, not anything else), that's actually higher than it probably should be, it's often even closer.
This leaves the Democrats overall in a better position than they would be if it were 70/29/1, and because of the way our two party system tends to work, it's extremely unlikely to come to that disparity, as any such disparity would prompt the Democrats to co-opt the triggering issues out of self-preservation. (At least for more than one election in a row.)
The system isn't half-bad. Minorities of course are still minorities and by definiton can't expect parity with the majority, but our system tends to keep them much better balanced than many other systems. The Democrats still have a significant voice in our system, even in the minority. It's not the Republican's fault they haven't been able to use it well lately.
I've changed my mind about the two-party system. It's actually pretty good. Most of the problems laid at the feet of the two-party system would not be solved by any other system, since most of them come from the people themselves. (And of course there's a lot of wishful thinking when people imagine other systems... of course if there was a strong third party it would be the People-That-Agree-With-You party that will magically set everything right. In reality, no such party is likely to arise, and you may well end up with the People-That-Largely-Disagree-With-You party. Everybody assumes they are the true majority and it's The System keeping them down, but, frankly, the evidence is that the minority is the minority, and no amount of fiddling with the election system can change that.)
Is not one of the big problems with "gravitons" that gravity appears to act more or less instantaneously at great distances? And isn't that a little troubling from the "Action at a Distance is Big No-No" point of view?
It turns out that if you do a full analysis, when something like the Sun is moving at a constant rate, then the Earth will orbit in such a way that it almost looks like it is orbiting where the sun instantanously is, but the instantaneous-ness is an illusion. For a full and highly recommended mathematical treatment, see Reflections on Relativity.
It is an illusion because if the Sun were to somehow, say, instantly and magically disappear, the Earth would continue to orbit the Sun until the news got to the Earth at light speed.
For more information, consult the rest of that very good book.
Slashdot Mirror
What ultimately put my mind at ease with regard to all of these "what ifs" is the recognition that cosmic rays routinely smash into the Earth with energies that we can still only dream of; for instance, see the Oh-My-God particle, an impact event still several orders of magnitude in energy above what we can produce in a lab. If an impact event could produce a black hole that could swallow a planet, the Solar System and indeed the entire universe would be nothing but a bunch of black holes of various sizes orbiting each other, as every massive body has long since been hit with at least one particle sufficient to start the black-hole or strangelet putative chain reaction.
Seeing as how every massive body in the universe has been hit with umpteen bajillion of these impacts, yet massive bodies remain, it would seem the probability of this occurring is effectively 0.
A priori, it's not necessarily a wrong idea. But the evidence is pretty clear that it's not a problem.
It's not the same word. "Mistake" is a generic term, covering things intentional and unintentional, a whole range of impacts of the error from trivial to catastrophic, and carries no information about admission of guilt.
"Brainos" are unintentional, freely admitted, generally minor errors.
Since we're communicating in English, which answers the "How do I indicate shades of meaning?" with "Lots and lots of words, all with slightly varying denotations", these little differences are very useful for precise, yet concise, communication. "Braino" fills in a hole, just as "pessimal" or a still-hypothetical gender-neutral third-person pronoun does.
I call things like that "brainos", in obvious analogy to "typos" where you have a "typing" problem. I know I am not the only one. My point is that there really isn't an official word for such things, but I don't really let that stop me.
Usually, when I use the word, it's in a coding context. "Yeah, I'm looking at this code and I know you have to check the return value of that function, I've done it a hundred times. I don't know why I forgot that time; must be a braino."
"First rule in government spending: why build one when you can have two at twice the price?" - S.R. Hadden
Even if I could choose my language, and I choose Ruby instead of Python, I'm still not ready to commit to Ruby on Rails for the size of application I'm talking about. I wouldn't have chosen Apache::ASP, either, but at least I've got it harnessed.
(Honestly, my problem hasn't been the frameworks, my problem has been people proving that you can write tightly-coupled spaghetti code in any environment if you don't watch them like a hawk. Ruby's no more the answer to that than what I've already got in place.)
I'm not a lawyer, but I play one on Slashdot.
If you still like the GPL v3, but don't like that clause, strike it. You can do this without controversy if you have full control of the code, or can get all contributors to sign off on it. (I'm assuming that with GPL v2, you left the "optional upgrade" clause in, or you have full control. Otherwise it's not an issue, as a license change would require consent from all contributors, at which point you can do anything you want.)
It ought to still be compatible with the GPL v3, which you might want to mention in your license, because even though you don't require the text in the binary, you're not violating your license by adding it. I'd add a clause that the user can optionally upgrade to the full GPL v3 as it might make it easier for them in the future to merge licenses.
You can release with whatever license you like.
Up to you, of course.
Personally, I've used the LGPL on something I wanted to use the LGPL, but since it was a Javascript library, I added a clause to clarify what I mean, since the LGPL is rather tightly bound to the idea of libraries that have to be compiled and "linked" to other compiled binaries, which doesn't apply to JS.
Functions lie like dogs. You can test the output of functions until you're blue in the face, but until you take a holistic view of the application and what it does, unit tests are more a salve for management's mind than a boon to developers.
And the solution is... "holistic" unit tests.
While it's true that unit tests have a hard time making that last little yard (mostly in the form of hardware output, like graphics on the screen or your example), you're not writing your unit tests correctly. It's a rare unit test for me that is the equivalent of checking that adding two numbers work correctly, and while those are useful in development, they very, very rarely ever break later. Pure arithmetic function are the easiest to write, in general, and they correspondingly have the smallest need for continuous automated testing. (Not zero, of course, just the smallest. And when they do break, boy howdy...!)
In your other example, you ask:
Can you verify that the input data was correctly injected into the database...
(and I cut the rest of this question off as it posits an incorrect approach.)
The answer to this is yes, although you need a good database and a good understanding of how they work. (Not "great", just good.) I have thousands of tests that verify that certain code correctly manipulates the database, and that verifies calling certain webpages correctly manipulates the database. It's only marginally harder than testing a traditional function. The key here is to do everything inside a transaction; perform the task, do your verification, then roll the entire transaction back. Then it doesn't affect your database (which should normally be the "test" database, of course), and as a side effect under all but the "READ-UNCOMMITTED" transaction level, allows you to have any number of copies of the same test(s) running against the exact same database.
I can't imagine writing a distributed database-based application without such tests. Well, I can, but it's no fun.
In a lot of database-based applications, since the database is the application, this goes a long way toward testing the entire app.
Your unit tests ought to cover everything but the hardware output, which is more the exception than the rule.
Part of the problem is the number of APIs that exist with no thought for testing, making it seem as if unit testing them is impossible. For example, a lot of GUI toolkits are a major pain in the ass because it's difficult or impossible to fully simulate pressing a key in them and then processing the event loop exactly once, after which you will see what happened. This is a limitation of the toolkit, though, not unit testing, one I fervently hope will someday be eliminated after my whining on Slashdot catches the eye of one of the GTK developers or something.
In other cases, you have to a little work, but it can be done. We use Apache::ASP, and it ships with a little Perl script that can run an ASP page outside of the webserver via a command line. Still not terribly useful, but I was able to take that script and turn it into something that accepts multiple requests over a pipe, and wrap another Perl module around it that manages the connection to make it easy to use. Now, in my unit tests, calling a web page looks just like calling a function. Unfortunately, the rollback idea doesn't trivially work here, but I have some other things in place to help with this. The upshot is my unit tests include whether entire web pages work. This is some damned fine testing, and it's caught plenty of bugs long before they get out to the user.
Sure, right on the periphery of some systems is hard to reach, but the vast majority of any system is perfectly managable.
You say you have "great pay", and you are thinking about taking a pay cut. Are you currently saving money at some significant rate per month? Everybody should be, but you're the canonical example of someone who should be.
If you've got a cushion stashed away, so that the startup can go under and you're not on the street in the next week, I'd strongly suggest jumping ship, for two reasons. One is that your current complaints are only going to become worse. The second is that you may find that you are in a career dead-end, relative to where you want to be. You hint at this; I confirm this.
If you can get equity in the startup (ask!), so much the better. (If you believe, you may even seal the deal with a bit of investment.)
If, on the other hand, despite your great pay you have no savings, my suggestion would be, pretend you're taking the pay cut now and start pocketing the difference, but unless you can make yourself extremely sure the startup is a "sure thing" for some period of time, skip it. You'll have to take on the next opportunity that comes by. Odds are extremely good there will be one.
(One aspect of savings that people seriously underestimate is how it frees you to take certain riskier opportunities as they come by. Spending every last dime traps you even before the "health catastrophe" or the "death in the family" or "sudden illness" or the other traditional sudden money drains.)
Sorry, I did see this before posting, but re-reading the parent comment to my comment made it too easy to say "professor".
Where you go wrong in your post is you miss the key point of relativity. It is true that the Lorentz transform tells you how to go from one time dimension to another. What is not true is your assertion that the initial time dimension is privileged in the transform. The transform is fully symmetric, and in math, that's not just the observation that the two directions merely "look" the same, it is the observation that they are so thoroughly the same that there is no way to tell them apart. (Symmetry arguments are very a powerful tool in the mathematician's toolkit, one of the fundamental ones.)
What this professor is claiming is quite frankly relativity 101. For instance, it is directly addressed in Section 1-1 of Reflections on Relativity; right there in that last diagram is the idea of two distinct time axes with the only distinction between them being which one you happen to be the observer of. We're just barely out of the Preface, and in fact this book happens to develop the idea rather more slowly than some other references!
It takes a real genious to recognize that there is more than one time direction, and that it is "truly true" and not just mathematical sophistry or convenience. But the name of that genious is Albert Einstein, not Alex Mayer.
A slight modification of the "Google it" answer: Open a phonebook. There are like a million companies that do this sort of thing. Find one locally, because you're going to want to talk to them in person. Unless you live out in the complete boonies, you've got some near you.
Once you get going, if in fact you ever do, you may find you need to hire people, etc. That's up to you, and basically a constant no matter what. But if you've truly got everything laid out, you can hire one of these companies.
Your problem is that if you are not technically competent, you can't tell a good developer from one that can talk the talk, but not walk the walk. Hiring developers directly is not practical. This is a handicap no matter how you slice it, but this approach minimizes the risk, if you do due diligence on the company you choose.
Oh, and I hate to say it, but it's a good 99% bet in my experience that if you don't know how to code or program, you do not have it all figured out. But hey, it's your dime.
Is it a "Oh wow, look what I just discovered on xbox live! This is the first shmup I've ever seen and its the greatest one there is!"
Seriously, it's quite possible. The genre has been "dead" now for what, ten years? Yes, I know it wasn't truly dead, hence the scare quotes. But it certainly was something only old-school gamers even knew about, and then only some of those would develop a serious taste for them.
Not helping is the fact that some of the later iterations got increasingly focused on that market, which was very scary for newbies. I enjoyed Mars Matrix, but almost everyone I showed it to just had their eyes glaze over.
The lack of a cost-effective way to sell cheap games that people actually know about has been a problem. A lot of previously "dead" genres may get a shot in the arm. (Anybody up for some 2-D platforming on something other than a GBA/DS?)
than having to find all of my bugs (rather than 5% of them) through testing.
HOLY FUCK. 95% of your bugs are typing bugs?!?!?
What kind of incompetent programmer are you? Don't ever come to me looking for a job!
My experience in dynamically-typed languages over the last few years is that 5% at most are typing bugs, and I'd guess much closer to 1%.
Seriously, if the primary effect of using a dynamically typed language was to increase your bug rate by a factor of 20, don't you think we'd have, you know, noticed? Give us some credit. While you're at it, why not try it out for a few months, if that strawman argument is what is holding you back?
I don't understand as a developer what dynamic typing does to help a language, and what real world advantages it offers the developer.
Fact: Nothing is free.
Everyone will agree with that in principle, but few people have internalized it.
Static typing is not free. It makes you jump through hoops to type correct code. When you need to change a type, it's even more difficult, especially when it's not something you can search and replace. When changing requirements require you to refactor out some interface, this costs yet more.
The great failure in this debate between static typing people and dynamic typing ethusiasts largely arises from the fact that static typing people can only see the benefits of static typing, and only see the costs of dynamic typing. You particularly made reference to your own inablitity to see the benefits in your post.
You can't complete the debate until you admit to yourself that there are costs to static typing, and benefits to dynamic typing. Only then can you intelligently weigh the costs and benefits of each approach.
I think dynamic typing wins in the vast majority of cases not because "static typing has no advantages", but because static typing charges you through the nose for very, very dubious benefits. Yes, static type correctness catches bugs. But what kind of bugs does it catch? Type bugs. All in all, as someone working in dynamically typed languages exclusively for years now, that's just not the kind of bug I deal with very often. I have logic bugs, architecture bugs, library bugs (bleh! and no these aren't type bugs), comprehension bugs, specification bugs, but I just don't run into type bugs that often. Thus, "paying through the nose" to avoid this particular type of bug is not a compelling bargain.
You're almost always better off taking the development-speed gains of a dynamically-typed language, and learning the discipline to write good tests (which, incidentally, tend to be easier in those languages). Static type correctness has very little overlap with program correctness. (Neither is even a subset of one another; it's perfectly possible to have a completely correct program that does not meet some definition of "static type correctness".) (Elaboration by somebody else.)
There are rare calls for static type languages, where it is so important not to make any type errors, ever, that's it's worth the pain of using them. But it's pretty rare for most programmers. (Of course there are programmers who deal in that exclusively.)
One of the things that could conceivably tip the balance back in favor of static type correctness is if static type correctness becomes more cheap, perhaps with such things like better type inference. But few things are worth the unbelievably staggering price you pay in Java for static type correctness. If you've never used a dynamic language for long enough to see the benefits, you have no idea just how much you are paying.
Until someone shows me that all the code that I've written in dynamic languages that have served tens or hundreds of thousands of people are somehow riddled with type bugs that have somehow failed to cause my code to come crashing down, I'm going to continue to use dynamically-typed languages. The predictions of doom if you let go of static typing have so far shown themselves to just be fear-mongering, quite a lot of it (as far as I can tell) from people who learned in school that static typing was important and have never even tried anything else.
.oN
It is seductively easy for those of us who like to consider ourselves intelligent to assume greater intelligence will get more done, but there is precious little evidence that this works reliably, neither individually nor, even moreso, at a collective level.
What's needed is not more intelligence, but more wisdom.
As a sign of how poorly "wisdom" is doing lately as a concept... when's the last time you heard the word?
Betcha it's been a while. (At least on average across all people reading this comment.)
Sorry, I just can't believe that with over 50 years of cinema to choose from your top two are so recent.
:)
In another context, I might make that very comment. And I do enjoy many, many other movies, and my top ten wouldn't be all in the last two years by any means. But I think that in the last three or four years, the maturity of special effects has allowed the creation of alternate worlds, where the special effects aren't the story at all, to be done to a degree not really feasible in earlier times. As I am a sucker for that sort of thing, it does tend to very legitimately load my favorites to the recent past.
The people remain constant; storytelling hasn't improved in the last ten years. If anything, the average storytelling that makes it to the silver screen has gotten worse. But those who use the technology, instead of being used by it, are using it to make what I consider to be wonderful movies.
Books don't have this effect, so my top selections would range all over the place. My favorite music ranges all over the past 300 years, but I do have to admit that in the hands of a person who uses the tech (and is not used by the tech), excellent music can be made today which couldn't be made 50 years ago. (I have been utterly surprised by some modern stuff.)
A valid criticism, but I hope this helps you understand a little.
Naw, I think he's got it covered.
Look upon his works, ye nerds, and despair. Or hope. Your choice, I guess.
Initially I was worried about this buyout. Pixar is responsible for my personal favorite film (The Incredibles, narrowly edging out Serenity).
But I was talking with some people about this last night and I realized something. First, Steve Jobs has had a lot of experience with the media industry thank to iTunes and his experience at Apple. Granted, that's more music than movies but I think the same basic forces are in play. I think he has a clear view of how both industries are, and the quality problems that Disney has, and the inevitable financial consequences that will eventually follow.
Second, Steve Jobs is an excellent businessman. I don't think he would trade 50+% of Pixar for 7% of Disney, unless he had some good reason to believe that Disney was going to be able to grow more than Pixar. The only way that would be true is if the merger deal included a lot of control over Disney by the Pixar crew, because clearly Business As Usual at Disney wasn't going to get it done.
I haven't heard about the specifics of the deal; maybe it's been covered, but the only clue I have is basically TFA (which I saw earlier). But it gives me a lot of hope. Still not convinced, but "hopeful" is a major improvement from when I figured that Disney would just kill the golden goose.
What in the name of their Dark Mother goddess will they do to us when they rise into our airy realm?... Us computer geeks are basically fucked
If you'd like to learn more about this, perhaps to better defend yourself in the future, I believe the Japanese have a huge selection of documentaries on this very subject.
You really need to be careful about throwing that point around in an argument, because it just as easily boomerangs back on you. Have you considered all the evidence that Global Warming isn't anything to worry about endlessly, or isn't Man-made, or isn't even happening to speak of (vs. perfectly normal cycles that will cause us to be screaming "GLOBAL COOLING!" again in 20 years)? Are you really sure that in this politically charged environment, all the climatologists are really sure, instead of agreeing with political consensus at the risk of losing their jobs (and what does a displaced climatologist do)?
My point is not that these things MUST be true, or even necessarily that they CAN be true. In fact, it's not about any of that stuff at all. My point is about that article you're waving around like it's your manhood; it's useless in an argument to quote it, because if you're partisan enough to claim that the truth is so obvious that your brain must just be editing out all contrary evidence because you're obviously just stupid, that's plenty of evidence that you're partisan enough to be affected too. Live by the sword, die by the sword.
No. The energy WILL disappear. Do not forget radiated heat. We won't send all the mass down at once, of course!
Across what, millions of years?
One way or another, you're dealing with huge numbers. Plus, since the rate of heat dissipation is proportional to the heat difference, if you insist on keeping the biosphere livable the entire time (spoilsport!), you're going to add some more factors of magnitude to the time it takes to dissipate the heat since you can't raise the temperature very far before it's unlivable down here; just a few hundred degrees renders the entire place unlivable. (And in this context "a few hundred degrees" is indeed "just".) We'd be engulfed by the sun long before we could move any significant amount of the moon to Earth. Yeah, I didn't do the math, but with these factors of magnitude involved, it's a safe bet.
(The Earth can actually hold onto heat pretty well, after all. Several billion years and only the top few miles have solidified; the rest remains really,
really hot.)
The mass of the Moon is ~7,349,000,000,000,000,000,000 kilograms.
To cart away even one millionth of one percent of the moon would require staggering amounts of energy. By the time we're dealing with that kind of energy, if we ever can (which I have my doubts about, at least in any way that would be useful for this task), I think we will be able to deal with the consequences.
Are you worried about whether if we do too much mining, we'll run out of crust on the Earth? Worrying about the Moon's mass is even sillier, since while there may be less moon, you're talking about actually removing the mass, something Earth mines don't have to do.
You'd also be talking about cosmic levels of heat here, because said "staggering amounts of energy" can't just disappear. Assuming you're talking about moving bits of the Moon to Earth (and not just flinging it uselessly into space) since the Earth is lower in a gravity well, all the mass will pick up the difference in gravitational potential between the Earth and the Moon, 100% in heat (since it won't move on the surface of the Earth, at least not for long). If you moved any cosmically significant amount of the Moon to the Earth, you'd make the surface of the Earth incandescent. (The exact temperature would vary depending on how much mass you're talking, but if you want to have some fun, take the gravitational potential difference of 1% of the mass of the moon, compute how much energy that is, then see how much heat that would add. It's a Big Number.) Until such time as Mankind is so powerful as to be able to revoke the laws of conservation of energy, at which point you can't predict effects anyhow, no significant amount of the Moon is going to get to Earth, at least not with a biosphere on Earth left to care.
The problem appears to be that the whole minority voice, blabla thing doesn't work out.
For a long time I echoed the "Two parties are bad" party line. But the more I think about it, the more it actually doesn't seem half-bad.
Our system tends to actively split down the middle. It's not coincidence, it's structural. While the minority party (today the Democrats) may be largely disenfranchised, by the very way our system works they will extremely rarely be in a huge minority. In the Senate, for instance, it's currently 55/44/1 (R/D/I), which means that only 6 seats have to change to change the controlling party, something that can definately happen. Due to Democratic structural failures (IMHO, and note that I am strictly speaking of the organizational structure of the party, not anything else), that's actually higher than it probably should be, it's often even closer.
This leaves the Democrats overall in a better position than they would be if it were 70/29/1, and because of the way our two party system tends to work, it's extremely unlikely to come to that disparity, as any such disparity would prompt the Democrats to co-opt the triggering issues out of self-preservation. (At least for more than one election in a row.)
The system isn't half-bad. Minorities of course are still minorities and by definiton can't expect parity with the majority, but our system tends to keep them much better balanced than many other systems. The Democrats still have a significant voice in our system, even in the minority. It's not the Republican's fault they haven't been able to use it well lately.
I've changed my mind about the two-party system. It's actually pretty good. Most of the problems laid at the feet of the two-party system would not be solved by any other system, since most of them come from the people themselves. (And of course there's a lot of wishful thinking when people imagine other systems... of course if there was a strong third party it would be the People-That-Agree-With-You party that will magically set everything right. In reality, no such party is likely to arise, and you may well end up with the People-That-Largely-Disagree-With-You party. Everybody assumes they are the true majority and it's The System keeping them down, but, frankly, the evidence is that the minority is the minority, and no amount of fiddling with the election system can change that.)
Is not one of the big problems with "gravitons" that gravity appears to act more or less instantaneously at great distances? And isn't that a little troubling from the "Action at a Distance is Big No-No" point of view?
It turns out that if you do a full analysis, when something like the Sun is moving at a constant rate, then the Earth will orbit in such a way that it almost looks like it is orbiting where the sun instantanously is, but the instantaneous-ness is an illusion. For a full and highly recommended mathematical treatment, see Reflections on Relativity.
It is an illusion because if the Sun were to somehow, say, instantly and magically disappear, the Earth would continue to orbit the Sun until the news got to the Earth at light speed.
For more information, consult the rest of that very good book.