Which rather leads us to question what a 'rogue' nation is (besides a political talking point.)
I assume it: 1. is a nation we don't like. 2. has limited ICBM or long range missile capability (could launch at most 5 at once.) 3. has CBN weapons (because a couple of V2s don't justify this laser program.) 4. lacks a conventional weapon force (SAMs, AA, fighters, etc.)
I'm really struggling here to name a single opponent.
Of course, the real point is that flying 747s around with fricking lasers is not a serious military project, it's performance art paid for with your tax dollars.
It's hard to name a single plausible scenario for which this absurdity makes any economic sense.
"Words that are common or ordinary receive less protection unless they have developed public recognition due to their long use in the market place. These type of marks are said to have acquired a secondary meaning."
That's from a Iowa State primer on trademark law, but articulates the concept well: you pick a common word, you'd better have serious mind-share. "Edge?" Nobody is going to think there is any "secondary meaning" here.
You can try to trademark "Earth," "Wisdom," or whatever, but it's a hell of a high bar to clear.
It's cultural. Societies need culture, and that requires a common method of communication/information storage. So if you want to govern a large group of people, you need to:
1. Get everyone speaking the same language. 2. Get everyone writing it the same way. 3. Get everyone thinking the same way.
So, China is a level 1 culture, Russia is level 2, and the USA is level 3.
Quite right. Also, the sliderule is the one true way to compute. You need to spend good money, but it's an investment that will last a lifetime. A really nice sliderule sells for hundreds of dollars.
for the professors, that it. By removing all the syntax, etc, you can be introducing functions, lexical scope, binding, etc in the first week. Data structures and recursion in the second.
Result: most students quit by week two, and you are left with a fairly teachable remainder.
All trading is basically the exchange of information for money. An informed investor uses his knowledge to buy/sell stuff, and, in doing so, reveals the information he has.
High-frequency trading is just the logical effect of information becoming cheaper due to faster computers/telecom: the information is aggregated, analyzed, and acted on faster. Information is worth less because the HFT guys disseminate it faster. The article touches on this: a big buyer is willing to pay $26.40, so within minutes the algo systems figure this out, and move the price right up to $26.39. The information owner makes a profit, but much less than he would have in the old days of slow discovery.
In this environment, a day trader watching prices is merely a self-deluded source of money.
ok, so stick to the end once just to see what a pointless, soul-draining waste of time it is. Then never do it again.
Learn to fail fast: give it 100% effort, try to make it work, but never lose sight of the big picture. If it is destined to fail, try to fix it. If you can't fix it, go find something you can make a difference on.
If you do not know what a client requests upon project start, it's usually a failed project to start. Fire your sales/contract negotiator/project manager.
I don't think we're philosophically far apart here. Project start is the best place to have a go/no-go decision.
I don't much use sales/contract negotiators, etc: just have an expert (senior programmer or whatever) flesh our the rough details with the client, report on the general situation (size, hardness, and sanity,) and we can make a decision in a few minutes. If you find yourself with more than a page of contract per $1M, you're doing it wrong (for in-house work, one email per $100K is a good rule.)
If they were good, they would fix the project. Ideally, two weeks in, they go to the boss with a plan to fix. If that doesn't work, three weeks in, they go to her boss with a plan to fix. If that doesn't work, they quit.
You're obviously a Highly Paid Consultant who could care less what happens to the project or what the client thinks. It's people like you who give developers (and consultants in particular) a bad rap.
I'm a highly paid employee who wants a good job done. I've dumped clients when what they want is absurd: better for my guys, better for them: building stupid stuff is a waste of everyone's money and time.
Quite agree on the sub-project thing. I usually just ask the people involved if what they are doing is reusable or special-case. If it's useful, go for it, but if it's gonna get lost in the noise, just get out.
Last year I got called into a meeting with a bunch of users who had somehow got five programmers lined up to write a really stupid bit of infrastructure (think bat-shit insane replication of bat-shit insane current workflow.) I cancelled it on the spot by telling the poor programmers to go find something useful to do. The users complained, but now I've got five productive, happy programmers, and those users are annoying some other boss at some other firm.
You might be right. I remember getting into a debate with a person about the quality of food in a specific restaurant. I focused on the dishes, the person focused on the fact that person's sister worked there. Was impossible to make headway.
You are a professional. When a project is truly doomed (i.e. the goal is pointless or no software could solve the problem,) just leave. Internal transfer, join a new firm, etc, it doesn't matter: just leave. Collecting a paycheck to support a losing project is sign you are a loser. Either fix the project or leave it.
I'm happy to hire people who have been on doomed projects, I avoid those who collected a pay-check until the final meltdown. A programmer who quits a clusterfuck is an asset: that's a clear warning sign to management that something is seriously screwed up. A keep-plugging-away-as-Rome-burns guy is a net cost: fire these guys first chance you get.
Global warming denialists alway sadden me a bit. Skepticism is a good habit, but you take a look at the math and the physics, and it's hard to take the not-our-fault position with a straight face.
I'd like to know how the deniers think. Is it a philosophical position against absolute truth? A real complaint against data gathering methodology? A way to pick up chicks by being "open-minded?"
They tried pencils in space, and they sucked: flammable wood particles and flammable/conductive graphite particles are a really bad thing to have in space.
Oh, and no taxes went into the zero-gravity pen design: it was created privately, and not under govt contract.
Well, hard to catch with unittests, because correct tests will pass, but incorrects may also pass. All unit tests may happily pass, yet the final application may fail because of an interaction of aliased pointers: which "unit" would be able to catch this?
Alternatives naturally depend upon the application itself, the domain, the skill level of the programmers, etc. My current app (100+ developers, 10M LOC) has stateless C/C++ routines for the heavy number crunching (heavily optimized with serious unittests,) the next layer interfaces to those using a high-level functional language (no side-effects, so many programmers can work on a system without hosing each other down,) and then high-level stuff to schedule work out to multi-thousand CPU compute farms in a reasonable manner, finally little apps sit on top of that (most are just a few lines of code of the form "please compute X".) Works for my domain, but probably not for most.
These certainly help, but are often hard-to-use in large programs: a low-level routine may declare it has restricted pointers, but it has no way to enforce that callers follow the rule. So, in big multi-developer systems, you tend to wind up with restricted pointer code kept in internal library functions, not exported functions, and the vast bulk of the app compiled defensively with full aliasing protection. Either that, or the app fails every other Wednesday for some strange reason.
At least half the Wall St banks are using some form of functional programming for their front-office systems.
It works if you can afford very skilled programmers. Unfortunately, most firms can't. Programmers are like lawyers: a few can talk at length about legal systems and theory, but most are only capable of routine divorce and tort cases.
Actually, you can be faster than C in many cases. C must generate suboptimal code in certain cases because it cannot protect against edge cases like pointer aliasing.
I've seen a LISP compiler generate better loop code in some cases, simply because it can prove arrays are non-overlapping, or that X*X is provably positive.
A lot of datacenters get built in repurposed buildings - the square-footage is often misleading (some are even 60's era compute farm housing - 90% of the space may be unused.)
For low-latency datacenters, you build in the middle of cities. Then you find square-footage really doesn't cover it: the fire-marshall shows up and red-tags you because he doesn't want a six mega-watt dense power sink in the middle of his premium real-estate.
"Publishing", in the context of that law, means distribution for sale
More like distribution OR sale.
It's pretty clear: you own the physical letter that was sent to you. You do NOT own the copyright. So, you are free to burn the letter, frame the letter, etc, but you can't sell or give away copies.
Slashdot Mirror
Which rather leads us to question what a 'rogue' nation is (besides a political talking point.)
I assume it:
1. is a nation we don't like.
2. has limited ICBM or long range missile capability (could launch at most 5 at once.)
3. has CBN weapons (because a couple of V2s don't justify this laser program.)
4. lacks a conventional weapon force (SAMs, AA, fighters, etc.)
I'm really struggling here to name a single opponent.
Of course, the real point is that flying 747s around with fricking lasers is not a serious military project, it's performance art paid for with your tax dollars.
It's hard to name a single plausible scenario for which this absurdity makes any economic sense.
"Words that are common or ordinary receive less protection unless they have developed public recognition due to their long use in the market place. These type of marks are said to have acquired a secondary meaning."
That's from a Iowa State primer on trademark law, but articulates the concept well: you pick a common word, you'd better have serious mind-share. "Edge?" Nobody is going to think there is any "secondary meaning" here.
You can try to trademark "Earth," "Wisdom," or whatever, but it's a hell of a high bar to clear.
That is a rather clever comment.
It's cultural. Societies need culture, and that requires a common method of communication/information storage. So if you want to govern a large group of people, you need to:
1. Get everyone speaking the same language.
2. Get everyone writing it the same way.
3. Get everyone thinking the same way.
So, China is a level 1 culture, Russia is level 2, and the USA is level 3.
mine looks like sin(x)/x, for 1 to 12 pi.
Quite right. Also, the sliderule is the one true way to compute. You need to spend good money, but it's an investment that will last a lifetime. A really nice sliderule sells for hundreds of dollars.
for the professors, that it. By removing all the syntax, etc, you can be introducing functions, lexical scope, binding, etc in the first week. Data structures and recursion in the second.
Result: most students quit by week two, and you are left with a fairly teachable remainder.
All trading is basically the exchange of information for money. An informed investor uses his knowledge to buy/sell stuff, and, in doing so, reveals the information he has.
High-frequency trading is just the logical effect of information becoming cheaper due to faster computers/telecom: the information is aggregated, analyzed, and acted on faster. Information is worth less because the HFT guys disseminate it faster. The article touches on this: a big buyer is willing to pay $26.40, so within minutes the algo systems figure this out, and move the price right up to $26.39. The information owner makes a profit, but much less than he would have in the old days of slow discovery.
In this environment, a day trader watching prices is merely a self-deluded source of money.
ok, so stick to the end once just to see what a pointless, soul-draining waste of time it is. Then never do it again.
Learn to fail fast: give it 100% effort, try to make it work, but never lose sight of the big picture. If it is destined to fail, try to fix it. If you can't fix it, go find something you can make a difference on.
I don't think we're philosophically far apart here. Project start is the best place to have a go/no-go decision.
I don't much use sales/contract negotiators, etc: just have an expert (senior programmer or whatever) flesh our the rough details with the client, report on the general situation (size, hardness, and sanity,) and we can make a decision in a few minutes. If you find yourself with more than a page of contract per $1M, you're doing it wrong (for in-house work, one email per $100K is a good rule.)
If they were good, they would fix the project. Ideally, two weeks in, they go to the boss with a plan to fix. If that doesn't work, three weeks in, they go to her boss with a plan to fix. If that doesn't work, they quit.
I'm a highly paid employee who wants a good job done. I've dumped clients when what they want is absurd: better for my guys, better for them: building stupid stuff is a waste of everyone's money and time.
Oh, and the phrase is "couldn't care less."
Quite agree on the sub-project thing. I usually just ask the people involved if what they are doing is reusable or special-case. If it's useful, go for it, but if it's gonna get lost in the noise, just get out.
Last year I got called into a meeting with a bunch of users who had somehow got five programmers lined up to write a really stupid bit of infrastructure (think bat-shit insane replication of bat-shit insane current workflow.) I cancelled it on the spot by telling the poor programmers to go find something useful to do. The users complained, but now I've got five productive, happy programmers, and those users are annoying some other boss at some other firm.
You might be right. I remember getting into a debate with a person about the quality of food in a specific restaurant. I focused on the dishes, the person focused on the fact that person's sister worked there. Was impossible to make headway.
You are a professional. When a project is truly doomed (i.e. the goal is pointless or no software could solve the problem,) just leave. Internal transfer, join a new firm, etc, it doesn't matter: just leave. Collecting a paycheck to support a losing project is sign you are a loser. Either fix the project or leave it.
I'm happy to hire people who have been on doomed projects, I avoid those who collected a pay-check until the final meltdown. A programmer who quits a clusterfuck is an asset: that's a clear warning sign to management that something is seriously screwed up. A keep-plugging-away-as-Rome-burns guy is a net cost: fire these guys first chance you get.
Global warming denialists alway sadden me a bit. Skepticism is a good habit, but you take a look at the math and the physics, and it's hard to take the not-our-fault position with a straight face.
I'd like to know how the deniers think. Is it a philosophical position against absolute truth? A real complaint against data gathering methodology? A way to pick up chicks by being "open-minded?"
They tried pencils in space, and they sucked: flammable wood particles and flammable/conductive graphite particles are a really bad thing to have in space.
Oh, and no taxes went into the zero-gravity pen design: it was created privately, and not under govt contract.
Well, hard to catch with unittests, because correct tests will pass, but incorrects may also pass. All unit tests may happily pass, yet the final application may fail because of an interaction of aliased pointers: which "unit" would be able to catch this?
Alternatives naturally depend upon the application itself, the domain, the skill level of the programmers, etc. My current app (100+ developers, 10M LOC) has stateless C/C++ routines for the heavy number crunching (heavily optimized with serious unittests,) the next layer interfaces to those using a high-level functional language (no side-effects, so many programmers can work on a system without hosing each other down,) and then high-level stuff to schedule work out to multi-thousand CPU compute farms in a reasonable manner, finally little apps sit on top of that (most are just a few lines of code of the form "please compute X".) Works for my domain, but probably not for most.
These certainly help, but are often hard-to-use in large programs: a low-level routine may declare it has restricted pointers, but it has no way to enforce that callers follow the rule. So, in big multi-developer systems, you tend to wind up with restricted pointer code kept in internal library functions, not exported functions, and the vast bulk of the app compiled defensively with full aliasing protection. Either that, or the app fails every other Wednesday for some strange reason.
At least half the Wall St banks are using some form of functional programming for their front-office systems.
It works if you can afford very skilled programmers. Unfortunately, most firms can't. Programmers are like lawyers: a few can talk at length about legal systems and theory, but most are only capable of routine divorce and tort cases.
Actually, you can be faster than C in many cases. C must generate suboptimal code in certain cases because it cannot protect against edge cases like pointer aliasing.
I've seen a LISP compiler generate better loop code in some cases, simply because it can prove arrays are non-overlapping, or that X*X is provably positive.
A lot of datacenters get built in repurposed buildings - the square-footage is often misleading (some are even 60's era compute farm housing - 90% of the space may be unused.)
For low-latency datacenters, you build in the middle of cities. Then you find square-footage really doesn't cover it: the fire-marshall shows up and red-tags you because he doesn't want a six mega-watt dense power sink in the middle of his premium real-estate.
"Publishing", in the context of that law, means distribution for sale
More like distribution OR sale.
It's pretty clear: you own the physical letter that was sent to you. You do NOT own the copyright. So, you are free to burn the letter, frame the letter, etc, but you can't sell or give away copies.
And so will my multi-million LOC, 24/7, multi-thousand CPU, Python business app.
Different strokes for different folks, I guess.