Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Have to wonder which will come first (Score 1) 105

by SuperKendall (#49516611) Attached to: Swift Tops List of Most-Loved Languages and Tech

Rust adoption seems to have been slow. Given that Swift took a lot of ideas from Rust, and is evolving more rapidly to completeness, I have to wonder if Swift will not take over positions Rust holds before Rust gains much of a foothold...

That's all predicated of course on Swift being released as open source, which will probably happen in a year or so.

Comment: Swift loved 'cause ObjC (and frameworks) supported (Score 1) 105

by SuperKendall (#49515699) Attached to: Swift Tops List of Most-Loved Languages and Tech

I've been using Swift for production work since shortly after it was released (much of it on an internal enterprise application which is how we were able to start using it right away).

What makes Swift really nice to use in its own right is that it has a lot of useful language features (like closures, generics, tuples, etc) with a syntax that can be kind of boiled away to the degree that you choose, to keep code clear and understandable. I think the best way I could describe it, is that it's like a functional language buy is very practical and doesn't get preachy about it.

So already the language is very pleasant to use. The real benefit Swift enjoys that give it such a high rating though, is that it comes with very advanced tooling and a super-integrated mirror-counterpart language (Objective-C) right out of the box.

Think about it, how many new languages like Rust suffer because you have to build up syntax highlighting support in the editors you like, figure out a new build process tailored to that language, how to run the applications and so on. With Swift if you knew XCode you could easily just start writing Swift and all of the annoying overhead was gone. Even if you DIDN'T know XCode, at least it's a pretty advanced tool dedicated to helping produce running code in very short order (VERY short order with Playgrounds).

Then along with that, you have a new language which invariably has some missing features or capabilities, that make some particular thing you are trying to do hard in the new language. Well in those cases, Objective-C is very close at hand - you can mix code from both languages easily in the same class even. For example Swift itself is strongly typed and has very few reflection or dynamic method lookup features yet. Objective-C is kind of the opposite way, full of dynamism and runtime reflective use, so you can jump over to those abilities as needed.

I don't think people outside the iOS community realize just how fast everyone doing iOS development is switching to Swift. Swift (for me) has actually worked really well since day1, the tooling was rough for a while (with the syntax highlighter/code completion crapping out regularily on Swift code) but I THINK it may finally be OK.

It's definitely not a case of people hating Objective-C, because a lot of the people that like Swift also liked Objective-C. It's a case of having some good tools already, and being given another tool that seems to work really well for some tasks and thus appreciating having an expanded toolbox...

Comment: Re:Less humane to keep them alive. (Score 1) 545

This may be true under the legal codes of some countries

Sorry, but after that statement I really cannot see you as anything but a monster.

You think only of yourself and what makes you feel good, not what is good for humanity or even the prisoner himself...

Under the constitution treason is punishable by death, so it's obvious the crutch you re falling back on cannot stand.

Comment: Re:Less humane to keep them alive. (Score 1) 545

What you overlook is that some people have truly lost the right to be considered human any more, through causing enough pain and suffering in others. Again, you overlook that keeping someone alive for many years may bring about a lot more pain and suffering to others, including guards and other prisoners.

You wouldn't advocate to keep a live landmine hidden randomly inside a prison, yet you are arguing for exactly the same effect. How is that more humane? Even to the guy to be killed it's not more humane to keep them locked up forever.

Comment: Less humane to keep them alive. (Score 1) 545

I'm not sure why it's considering more humane to keep someone locked up forever than simply to kill them and end what is essentially torture...

The more you allow contact with other prisoners, the more you are punishing others by allowing contact with someone who has no reason or incentive to avoid harm to others.

The more you keep someone locked away the more it is essentially torture.

The death penalty should not be about expense, but exists because some people simply cannot live without harming others, and have no place in the world.

Comment: That is OK when... (Score 0) 246

by SuperKendall (#49503445) Attached to: The Upsides of a Surveillance Society

They were under constant watch of the Stasi

The difference is that the Stazi was not under constant watch from the people, as is the case now with citizens filming police.

Omnipresent monitoring is OK if there is enough monitoring to ensure captured video is not taken out of context, and can reveal abuse from the state.

Comment: The EU does not get a pass (Score 1) 48

True I would say places in the U.S. like NYC, SF, and Miami have especially bad cab drivers.

But I did not have good experiences in Rome, Belgum (also Brussels), and in fact in Germany also (Berlin).

I will agree the black cabs in London are very good, and actually I did have a great cab driver also in Turkey now that I think about it so I do feel a bit sorry for maligning them all in a blanket statement.

But I still stand by the statement that on average the Uber drivers have been much nicer, the cars in much better repair (even the taxi drivers that were friendly in Turkey still had pretty beat up cars).

Comment: What's bad about Uber drivers? (Score 3, Informative) 48

The Uber drivers I have used have all been great. Complaints I've seen have all been about Uber the company, not the drivers... the drivers are just normal people trying to earn a living by making use of what they have.

Most taxi drivers I have encountered on the other hand, have ranged from standoffish to incredibly rude and sometimes hostile, frequently lying about fares to get more money. Taxi drivers can be that way in most places because they have no competition, no reason to provide anything like good service at all - and it doesn't hurt that in a number of areas they are tied to organized crime.

Comment: Actually (Score 2) 136

uhm, actually plist files are xml

ACTUALLY plist files can be either textual or binary, which is very much not XML

I should have said not necessarily though, instead of just "not"... but it was kind of irrelevant to the main point.

They certainly aren't very compact as far as formats go, even on the watch.

Sigh, didn't read much of that original message, did you?

They don't NEED TO BE EXTREMELY COMPACT because they are sent over only once, when the app is loaded on the watch - that said, it is in the binary format which is much more compact than the textual format.

In use the watch pulls files from that bundle at runtime. And if you were any kind of programmer you'd know there is a tradeoff between compression and computation (which the watch has little of) in terms of file formats, so a fairly but not maximally compact file format is better for performance than whatever you are thinking of.

Comment: Yes you are wrong (Score 2) 136

The UI definition is held in a Plist format (like, but not, XML) but that's not what the device gets. It gets a very compact binary form of your UI, that is loaded onto the watch before the user even opens your application.

The Apple Watch API is actually EXTREMELY conservative with what gets sent over to the watch, to the extent that even attempting to set the same label value twice in a row is rejected with a warning. and UI elements on the screen are wits-only (you cannot query the watch see what currently displayed values are).

365 Days of drinking Lo-Cal beer. = 1 Lite-year