Comment Re:Hmmm .... (Score 4, Insightful) 127
> These detectors will let us do gravitational wave astronomy much like we do with light and radio waves now.
Mmmm, more like neutrino I'd say. You can't point your GWD at an object.
> These detectors will let us do gravitational wave astronomy much like we do with light and radio waves now.
Mmmm, more like neutrino I'd say. You can't point your GWD at an object.
> That depends entirely on the licensing agreement between Saban and Toei, no "probably" about it - that's how the law works.
No, it's not. Unless Toei *transfered the ownership of the copyrights", they still own them. Copyrights are not jurisdictional beyond the international boundaries of the group being applied. You cannot transfer the copyright for the united states. You can *license* someone to *use* the copyrights, clearly happened, but the fact that Toei continued to make products with the same characters suggests it is highly unlikely the transfer occurred. So it remains Toei's copyright to protect.
> you've downed a fifth of Jack and snorted a couple of grams a coke
You sound like an expert.
> The established principle (with regards to trademarks)
Great argument. In case you didn't read it, the claim is copyright violation, not trademark.
> As the Saban's version of the Power Rangers is a licensed work, that principle cannot possibly apply here
"That depends entirely on the licensing agreement between Saban and Toei"
> No, this is another case of a Slashdot poster, ignorant of the law, creating assumptions out of thin air
> and then using convoluted sophomoric logic to reach a predetermined conclusion.
Sophomoric... like name calling, claiming the other person is drunk and high, etc, like that?
*plonk*
Haim Saban's "creation" consists of dubbed versions of the characters from Super Sentai, which you can see on the Wiki page for one installment, Kagaku Sentai Dynaman - scroll down.
As a derivative work, Saban doesn't own squat, and ownership, if there is any, probably belongs to Toei Company. However, as the same characters have appeared in many works *as different characters*, the argument might also be made that they are generic.
So this is basically yet another example of someone claiming ownership of something they never owned, which is precisely why copyright is such a farce in general.
> but it has little to offer over C for tasks other than GUI programming
That strikes me as similar to saying a Porsche has little to offer other than performance and fun. That statement is demonstrably true, but appears to be missing the point. Is it the case that only some programming is GUI-based? Yes. Is it true that almost every program ends up with a GUI? Also yes. Lets not ignore the forest for the trees.
But more directly, I disagree with the statement at its core. ObjC, and other languages like it, offers several features that make *very* common tasks *dramatically* simpler:
1) Late-bound methods. In ObjC you can send any message to any object at any time. That includes dangling pointers or null. What that means is that if you do this...
String x = LoadStringFromFile("a file that doesn't exist")
x.printToDebug
the code runs fine. The answer to any method passed to null is null, which is precisely what you actually want. Why is this useful? Because it eliminates the 10% of the code you write, the code that checks every step of a method like this for any nulls...
someObjectWithFields.aMethodThatReturnsAField.whichIsAnotherObjectWithAField.trim.printToDebug
The correct answer for this method is null in the case that anything in it is null. ObjC does that (from now on, I'm using "ObjC" to refer to other languages with similar features, the Smalltalk family). Sure, you *can* put in all the IFs if you feel that you really need to know if Another is null and not AField, but in 99% of the cases I've seen, that's not what you actually need.
This eliminates many, many lines of code from your project, which makes the resulting code smaller and far easier to read.
2) Data models. In conventional languages you can't load an object in a generic class and then have it assume the qualities of your model. Let me give you a recent example from my own code. I have a library that can read and write XLSX files, turning them into Rows, Columns and Items (item is the actual value). My program has Accounts, Contracts and Addresses, which are collections of code. In order to turn the Rows into, say, and Account, I have to roll over the rows and create parallel objects that point back to the Row. It's a complete mess. In comparison, in ObjC (from now on, that's a generic term) I can swizzle the object after it is loaded and that Row magically turns into an Account.
If you don't understand the power of this concept I think you need to look at some actual examples of DB programming under Apple's late, lamented EOF. It is, bar none, the simplest and cleanest object modelling platform I've seen. I understand examples of similar simplicity and cleanliness exist on other dynamic platforms, but I've tried them all on Java, C++ and
3) Zombies. This is really just a subset of swizzling applied to a real-world problem. You can flick a switch so that when ObjC releases an object it doesn't, it instead swizzles it into a Zombie. Recall (1)... this means that instead of your program crashing, it calls that method on the Zombie. Zombies have one method that gets all calls, and it prints out useful debugging information.
Yes, you can do this in other languages, and some even do it. But again, as in (2), ObjC's *implementation* of this is trivially simple and easy to use.
4) Method signatures are strings. I think this is what you're touching on when you say "good for GUI" but you don't specify. The advantage here is that I can save method calls in files. This has all sorts of interesting side effects. One simple one is that I can bind a button to a method directly... unlike (say)
But the real side effect of this is the ability to trivially extend objects. Recently I found that Apple had not exposed some API in Swift. So I did...
extension Array {
var randomItem: T {
if (self.count == 0) { return self[0] }
let index = Int(arc4random_uniform(UInt32(self.count)))
return self[index]
}
}
Now all my arrays, like String[], have this method. Everywhere.
Now I know other languages have similar functionality, but the difference, again, is implementation. In ObjC, this concept is built into the language, not bolted on after the fact like it was in
That's just the ones I use. And again, this isn't limited to ObjC, many other languages have this. Nor does any of this excuse some of the terrible things in ObjC. And yes, you do have some or all of these in some or all other languages. But to say that ObjC is only good for GUIs is simply false, and belies a misunderstanding of OO programming and/or the language itself.
> JavaScript is probably the mainstream language that fits closest (it's actually very close to Smalltalk).
It's much closer to Self. IIRC it was a fork.
> it was swiftly replaced after his demise
Nice.
> Dynamic binding and loading is ugly and clunky
I really can't agree with that. Quite the opposite, given that dynamic binding solves a very very common problem, and that the code required to do the same in a non-dynamic language is *extensive*, I have always found that compile-time bound languages are far more clunky and ugly. I thought that was a pretty common opinion among people that have used both.
>.Errors you don't catch at compile time are errors that you have to write tests for. Y
Sure, that's true, but of the total set of errors that compliers don't catch, the ones that are caused by dynamic binding is a tiny subset. I still get dangling objects and nulls all the time in my C# code, probably 50 to 100 times as often as I've had a binding problem in ObjC. It is a problem, sure, but it's not *the* problem.
Quite the opposite, in fact. I would posit that nulls remain the largest problem in modern code. ObjC (and Swift) allow you to call methods on null. That means you get a null instead of a crash, which in most cases is what you want in the first place. Yet in my C# and VB.net code, I have to liberally sprinkle all sorts of checks and such. C# is better in this regard than VB, and VB is adding support for better handling in the next release because it's so bad at it, but neither comes remotely close to the way ObjC handled it, from the start.
So, while dynamic binding may indeed result in some uncaught runtime exceptions, I'd say ObjC programs *on a whole* have far less runtime exceptions due to other design decisions.
> In either case, the first thing you should learn is a unit testing framework for that language
Well you've just invalidated your own point, haven't you? If the problem is runtime errors, and the solution is unit testing, then the relative paucity of dynamic binding problems is going to add maybe zero lines of code to your test suite.
> Objective-C is an ugly, clunky language
It is now. It certainly wasn't when I first encountered it in 2000, running on OpenStep. Back then it was clear, far cleaner than C++, and the libraries were (and are) fantastic. Say what you will about Qt, all of it's true, but everything from strings to db programming was joke on OpenStep compared to anything else out there. Which is why the company existed at all at that point, the financial guys used it a lot.
But fast-forward a decade to 2010 when I next looked at it for an iPhone program. Uggg! What an abysmal mess! I can't believe it's even the same language! So many one-off @ commands and bizarre "well, you need to know that..." In spite of all the problems in beta testing a *languages*, I still moved to Swift ASAP. Swift is currently about what ObjC was when I first saw it - relatively lightweight and fairly clean. I'm sure that will change, but for now...
That said, C++ remains a mystery to me. The syntax steadfastly refuses to lodge in my brain. I had the same problem with Lisp, which is saying a lot. But as others have noted, it remains the only real cross-platform system one can use for base logic and then plug into the underlying GUI language whether that be ObjC or Java. The only thing that comes close is C, and I still debate which language is better to use in these cases.
They've been running one of these in nova Scotia for decades. And I'm sure it's not the first either.
> know I was disappointed as a kid when it came out originally in theaters
Interesting. I saw it after it passed its first run, and it was a double-feature (remember those?) with Firefox starting. I arrived late and saw the 2nd half of Firebox, which even as a 15-yr-old boy nerd I dismissed as silly. Then Blade Runner came on. I remember being awed. Not by the plot itself, but by the vision. The gritty always-raining deteriorating city stuck in my mind like no movie since Star Wars (in which case it was the *scale* that stuck in my mind). This was shortly after reading Johnny Mnemonic for the first time, so that likely has a lot to do with it.
> Just because manufacturers haven't provided many affordable solutions doesn't mean that Steam in the living room is a pointless concept
It strongly suggests it.
> and in-fact it's a rather welcome one
Another console that doesn't play any console games, but does play all the ones I already have on my PC. How is this welcome?
> Patience is a virtue.
Lolz. Out-of-the-gate momentum tells you a lot.
> Why is this particular to electric cars?
Electric cars will generally have a 230V/30A connection, rather than 115/15. So they get four times the power.
They also have electrically powered heaters. So they can turn on the interior heat without having to start anything else.
> gas cars have electric heaters in the cooling
These slightly warm the fluid or oil. They are useful, but don't heat the interior.
Read the actual numbers... "(170 Wh/km), whereas the upper Midwest fared the worst in terms of energy efficiency (196 Wh/km; red)". We're talking about a 13% difference - the article uses the 15% figure from 170, cheating IMHO. BFD, one way or the other, yet the graph varies from green to BRIGHT RED!!!!
More numbers; even if you power your electric car on 100% coal, its about twice as clean per mile than a gasoline engine. The math is trivial and I suggest everyone try it themselves:
https://matter2energy.wordpress.com/2013/02/22/wells-to-wheels-electric-car-efficiency/
That's right, because Apple's has a terrible track record when it comes to investing in marketing.
> They really need some sort of better name to differentiate between these...
Like "PV" vs. "CSP" maybe?
To write good code is a worthy challenge, and a source of civilized delight. -- stolen and paraphrased from William Safire
