Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

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

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


vs not having generics :-)

different ways of specifying parameters, including named and unnamed parameters

[NSString stringWithFormat: @"%@", value]
[NSString initWithFormat: @"%@" arguments: va_arg]

property declarations, including a multitude of shortcuts

@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).

Comment Re:sad (Score 1) 232

This is because most funding that comes from outside of the local community (from state and federal-level taxes) comes with significant strings attached on what the funds can be used for. This is for example pretty much the only reason most schools even have internet access today - because some program somewhere is funding it.

Realize primary school textbooks actually cost new the same level as college-level textbooks, and the security requirements which are being placed on schools. Moving to an iPad per student not only saves them money (since replacements are built into the cost to schools), but it allows them to eliminate lockers because students no longer have 60 lbs of books issued to them for their classes.

On the flip side, books never really die - they just get too worn for a school to use. But typically these are repaired and given to a school which has less money. And then, scarily, again they are given to schools which have less money (apparently a lot of my old text books which were all third+ hand were being sent to Mississippi - and a significant number of my books in high school were already the same age or older as I was).

The book publishers are not interested in having book licenses be transferrable - instead, a Math book is discounted down to $10 for a student on condition that the book is not transferrable to any other student, and is "theirs for life". New versions are actually pushed out to the book itself digitally, so tricks like you have in college of having the "14th edition" come out with the same text but new problems go away.

This not only starts to create a much more predictable revenue for the book publishers, but will have a trickle-down effect where the poorer schools will have to get in line, since they no longer have a source of repairable books for their classrooms.

Slashdot Top Deals

"Be *excellent* to each other." -- Bill, or Ted, in Bill and Ted's Excellent Adventure