Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:Lightning is cheaper (Score 1) 124

Not true and not true.

The confusion comes in that both Airplay and the Lightning adapter use the platform H.264 encoding to stream the video. The iPad Mini they were testing couldn't handle 1080p MPEG encoding in hardware - but it would stream 1080p pre-encoded video just fine, for instance - it isn't a limitation of the cable throughput.

Comment Re:Why are strings passed by value? (Score 1) 339

Swift strings are value types, just like C++ or C#. The value type contains a reference to the string text. (Ok, libc++ in llvm will actually tag the pointers on 64 bit platforms to stuff small strings *into* the struct directly, but I digress)

Swift strings are copy on write, where the reference count is used to determine if you possess a unique reference to the string before mutation. This is similar to how libstdc++ works, or at least used to work.

I believe C++ libraries have been migrating away from CoW strings because of the atomicity costs of the reference counting. Swift, maintaining compatibility with Objective C, already needed to have support for ref-counted strings.

So it was a different trade-off - the ref-counted Swift strings can be bridged to Objective C, while a non-reference-counted string would need to be copied. If they make the decision to have reference counted strings to make the interoperability faster, then they might as well add CoW support to make them more efficient/faster in other cases.

Comment Re:One more in a crowded field (Score 1) 337

Three apple platforms now: iOS, Mac OS X and watchOS.

Swift has had a lot of up-front design decisions made to ease what will be a long transition from objective C - methods with named parameters to match Objective C rules, the ability to see if you have a single reference (a feature of reference counting) is a feature needed to optimize string and collection types, so use in a non-reference-counted system would be a pain. Also things like the error model are quite different.

This would make it more difficult to compile to java/dalvik byte code or .Net CIL (java/dalvik being way harder). This does not preclude native compilation via the open-source compiler and bridging.

While Apple audited their APIs to make sure their API bridging generator worked well and created nice APIs everywhere, and even added some language features to Objective C to fill in the gaps, a third party like Google or Microsoft would not have such 'guided' translation - they would need to design Swift-like APIs to expose.

Its possible, but not close to free.

Comment Re:More approachable? (Score 2) 270

I don't know how this idea started, but only a non-programmer could think Swift is more approachable than Objective-C. Swift is way more complicated and has more fundamentals that must be understood.

let versus var

const char* vs char* vs char const*
NSInteger vs const NSInteger
NSString vs NSMutableString

optionals, including implicit and explicit binding

NSInteger vs NSInteger*
nil vs NULL vs NSNull

differences between structs and classes (value versus reference)

NSInteger vs NSColor

generics

vs not having generics :-)

different ways of specifying parameters, including named and unnamed parameters

vs:
[NSString stringWithFormat: @"%@", value]
[NSString initWithFormat: @"%@" arguments: va_arg]
NSStringFromPoint(pt)

property declarations, including a multitude of shortcuts

vs
@property(readwrite,copy) NSString* foo;

The problem is, if you don't learn most of the syntax in all its variety, you'll have a hard time understanding any random code you come across. Learning by example helps make a language approachable.

The problem is that you are judging a new language's learning difficulty by comparing it to a language you already know.

That said, Swift is not solid enough to live there 100% yet. You have to understand both languages currently to really be efficient. Going forward, knowing both languages will just be a very desirable skill (but not essential).

Comment Re:And yet, no one understands Git. (Score 1) 203

I would say it is both a useful tool, and complicated to the point of getting in the way of getting things done :-)

Git has a data model which I imagine is based on the idea of distributed filesystems. On top of that you have something you don't normally get in a filesystem - you save all historical state, and you comment on what a change in state represents.

Beyond normal SCM functions, this model gives you the ability to do all sorts of fun/crazy things:

- Rewrite historical state to obliterate any record of a certain file
- Rebase your filesystem's state based on changes you've seen from other nodes
- Filter the filesystem to represent the contents differently, for instance only represent a single subdirectory
- Create alternate systems for resolving changes from distributed nodes
- Create alternate formats and distribution mechanisms for representing changes in filesystem state, and workflows for manual or automatic application
- Create a union filesystem representing data outside the distributed filesystem

So its not just that git core is complicated - a lot of the wacky tools are actually built into git, and a lot more are available elsewhere. And there are legitimate reasons to want to do some of the more complicated tasks. Since these tasks are useful but not vital, they wind up being tools in a very complex toolbox.

On top of that, you have problems when trying to teach more than command-line formulas or GUI buttons to get certain tasks done - explaining the full model overwhelms new users. But the porcelain is barely decoration, as the git plumbing underneath is exposed in things like command help.

Going beyond formulas requires not just learning, but some torsional force on one's brain so it may reorient inside your head - you have to learn not just commands, but new ideas. But until you do that, even the commands you use as part of your formulas will have help pages that might as well be written in klingon, because they are written in terms of concepts that you don't understand.

Comment What a useless article (Score 1) 183

Languages don't get open sourced - language implementations do. So a real informative article would talk about why apple would or wouldn't propose Swift to a standards body as a new language.

My understanding (from Apple employee comments, including by Chris Lattner who created Swift) is that the language is evolving in the open now. Version 1.0 is going to be supported by iOS 8 tools, but that doesn't mean there may be several updates even over the next year to fundamental language concepts. Languages evolve from use; the best way to make Swift better is to have people both inside and outside of Apple start using it and providing feedback.

They actually designed the swift implementation to make more rapid evolution of the language possible; there are no components at the OS level or shared by applications. Instead, you bundle your application and dependent libraries with the swift runtime corresponding to the compiler version used to compile every swift thing in that bundle. In exchange for more space used by duplicating libraries, they can actually let you ship and support older swift code that might not even compile with the newest tools due to language changes.

In that environment of rapid innovation, attempting to standardize the language or to promote alternate implementations would be insane. However, these are both things which I've seen hints are desired once the language calms down. If Swift is proposed as a new language to a standards body, it is incredibly likely that Apple would also give components of their Swift implementation to the LLVM project.

Comment Re:Good point, except... (Score 4, Interesting) 220

It is a technical discussion. Unless you are prepared to provide feedback on how to make a more private/anonymous protocol which can serve as a drop-in replacement for HTTP 1.1, "normal users" will just serve as background noise.

PHK's biggest issue IMHO is that HTTP/2 will break his software (Varnish), by requiring things his internal architecture can't really deal with (TLS).

Slashdot Top Deals

Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman

Working...