I prefer PLOW, the Platform, Language, Operating system and Web server stack.
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
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.
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).
Damn, a sub-700-er!
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.
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.
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).
The developer site doesn't authenticate the user; they redirect to another site for that.
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.
b) a darn STANDARD _Binary_ API so I don't have to worry about which _compiler_ AND _platform_ was used,
I'm not quite sure what you mean here. Do you mean generate compiler/platform independent code (some IR like bytecode/LLIR)? Or do you mean ntoh/hton and the like?
h) Provide PROPER 16-bit, 24-bit, and 32-bit characters
i) Fix the darn grammar so that compilers accept UNICODE source
j) Fix the darn grammar so that compilers RECOGNIZE identifiers WITH Unicode characters
Should both be fixed with C++11. Except 24-bit characters, which I've never heard of before.
k) Add a proper exponent operator
l) Add a proper wedge operator, along with inner and outer product operators
Seem rather special-cased here.
m) Add proper multiple return types
You can do this by returning a std::pair, a std::tuple, or a structure you build. However, I don't believe there is an easy syntactic way to split a pair/tuple into multiple local variables.
n) Fix all the times the spec says "undefined" or "implementation dependent". The point of a spec is to SPECIFY what the operations do, NOT to be ambiguous because in some idiotic universe 'char' is not exactly 8-bits.
Never going to happen. Most of those "undefined/implementation dependent" items are features, and compilers take advantage of them to optimize code. It does make some quirky edge cases, but makes a lot of code optimization techniques in use today possible.
When is C++ going to automatic garbage collection WITH the ability to tell the garbage system how many milliseconds you are allowed to use (inclusive from ZERO.)
Do you know a system that does this max time? Because it sounds ridiculously difficult, and would lead to cases where a program would have to fail because it has no memory yet is not allowed to do a full garbage sweep/reclaim.
The problem with that C++ is not that you can't write simple code, but is that the languages makes it easy to write verbose bloated code.
I actually don't believe this is the problem with C++ - you can write verbose, bloated code in most languages. The problem I see is that C++ was made to be as strict a superset of C as possible, and inherited an audience who want full control of things like object size, and memory allocation/deallocation behavior. Because of this, generialized code requires way more knobs to be tweaked than you expect, and templates have evolved to be a hacked-together functional programming language to determine optimal operation. In order to generate an optimal, generic library you have to make the code itself incredibly difficult to maintain.
Although I don't have the means or desire to test it, it is far more likely that they decided most of what people would want to output via HDMI was H.264-encoded video. So they made an interface where H.264 was streamed over the lightning connector, and converted by this adapter to HDMI. Probably both sides use HDCP or similar protections.
The limitations Panic encountered are because the video support in the iPad mini can only h.264 encode the screen (for 'mirroring') at lower-than-1080p resolutions.
But, does it look like a women's hair clip painted gold?
The issue is that people program at a pixel ratio as if it is some measurement of minimal perceived size. If they had just quadrupled the pixels, most websites for instance would expect to scale to fill the larger size, but without any notion of whether the page was being rendered large enough to see.
Not to mention all the people who hard-coded mobile sites based on the horizontal width of the device. Which, btw, still hasn't changed even with the new dimensions.
Accessory manufacturers (particularly case manufacturers) burnt all their bridges with Apple long ago. Since around when the iphone 3gs came out, nobody has gotten any advance notice of new hardware because of all the leaks.
Even now, many of the apple rumors come from case manufacturers who are attempting to bribe employees at the manufacturer for information.
Right now Apple has only even hinted that there may be an iphone 5, and if they are going to deprecate a decade of accessories with a new connector they want to do it on their own terms. There is no way Applw have confirmed or denied the dock connector except perhaps in controlled leaks to the media. Nobody making alarm clock docks is gonna know a damn thing until the rest of us do on the 12th.
How is this any more a flagrant act of GPL violation than a linux install CD (which does not ship source due to space)? The help menu takes you to the project's github repo.