Better than the debt of a changed language/library that allows for multiple and confusing variations thanks to not removing those features (syntax, keywords, functions). It makes looking at old documentation difficult (it's wrong now), but also means that outdated guides aren't still correct (so they'll get culled or corrected more quickly) and we won't have the OpenGL situation.
I just spent a while reading about both stride and for ... in, and I feel like there are any number of cases where I would rather use a C-style for loop.
which is somewhat general (sequences include lists, dicts, strings, tuples, generators, text files and more [2]), and it covers a wide range [1] of use cases.
[1] Pun not intended.
[2] Basically, any iterable. This include custom iterables you can define, which can then be iterated over using the same standard for loop. A unifying feature of the language:
"The use of iterators pervades and unifies Python."
Theres only a case here where iterating over a parent/child relationship, and testing for nullability, its more clear with the c-style for than with a while loop:
// old
for x: Thing? = thing; x != nil; x = x.parent {
...
}
// and now
var x: Thing? = thing
while x != nil {
...
x = x.parent
}
It was the only case i've really missed it.. unless theres a better way to do it that im not aware of..
But the for c-style loop for numbers is really not needed
I am not sure if there is a name for this type of function, so I called it someFunction:
func someFunction<T>(initial: T, next: T -> T?) -> T
{
var current = initial
while true
{
switch next(current)
{
case .Some(let value):
current = value
case .None:
return current
}
}
}
Now you can express that idea generally, e.g.:
extension UIView
{
var rootView: UIView
{
return someFunction(self, next: { view in view.superview })
}
}
I also didn't test it, so it might not work.
Of course, it would be more Swifty to create a "Parentable" protocol and write that as an extension of it!
I’m not sure you’d really want the crap-fest that is Xcode’s code. It has so many bugs and issues that it’s a better idea to completely dump it and either start over or give up and adopt something like AppCode, like Google did with Android Studio. Making developer tools is just not Apple’s forte and Xcode’s sad state of quality and performance is clear indication of that.
I’m thoroughly convinced that Apple has an internal-only IDE that they use that is far better than Xcode and is actually functional, much like the internal Radar tool. There is no way Apple’s engineers could get any work done if they use Xcode.
Or, they should start charging money for it so they could justify spending resources on the dev tools. One of the reasons (among many) that Visual Studio is still the king of all IDEs is because Microsoft charges money for the serious bits of it (Pro and higher).
I think you're seriously overstating the issues with Xcode. There are bugs and annoyances, but things have gotten better over the years. It's not as great as Visual Studio, but it's far from horrible. Remember, we live in a world with Eclipse.
Is Eclipse still growing exponentially? I remember Ganymede -> Helios increasing 2MM LOC, Helios -> Indigo 4MM LOC, and Indigo -> Juno 8MM LOC. I couldn't even get Luna to run, and haven't checked back in on it since then. The foundation started to bundle up too much stuff in the distributed versions.
If AppCode ran on other platforms and became a Swift IDE that would be great honestly, not sure how long before JetBrains attempts this. As things stand those of us curious for Swift without any access to Apple products are left with just plain text-editors.
Technically, LLVM started as a research project at UIUC, and then Apple hired the principals and adopted the project in 2005. The LLVM website is still hosted by UIUC, and Google and other companies are also significant contributors.
Maintaining and growing an existing tool with its existing developers who you bought in is a good thing and to be applauded, but doesn't necessarily mean the company is good at tooling in general. The cultural requirements are very different.
>I’m thoroughly convinced that Apple has an internal-only IDE that they use that is far better than Xcode and is actually functional, much like the internal Radar tool.
That's an interesting point and it makes a lot of sense. With the scale of the codebases a lot of them are working on I also don't see how they could be productive while working in XCode. And also XCode could not be this buggy and broken if it had internal developers working with it and constantly reporting bugs.
How does it make a lot of sense? If Apple had a tool that was better than Xcode, why would they hide it from the public? They have proven themselves to be quite motivated to provide developers with good tools and frankly I find the idea that they keep a better tool hidden away ridiculous.
thought_alarm got it right. The experienced developers probably use open source editors / debuggers, unsuitable for the masses. Not an Apple-only tool, but still not XCode.
The experienced developers at Apple are no different than the experienced developers elsewhere. They use the LLDB command-line and write their code in Emacs.
I've never liked Visual Studio, and the last time I worked on a serious Windows product most of the experienced developers used WinDbg and cordbg rather than the neutered Visual Studio debugger. And some guys still wrote their code in Visual Studio 6 rather than the newer .NET IDEs.
My problem with Xcode today is that it's too much like Visual Studio. I'll take Xcode 3 with LLDB any day.
Command-line tools are great but graphical displays can be useful, too. The real problem is that pane/window management on OSes is years behind where it should be.
What I want is a way to take any view I please, from any application, and arrange it anywhere in a standard way with keyboard support and sensible omissions of chrome. If this means 65% of my screen is terminals, 20% web browsers, 10% some graphical view from Xcode and 5% notifications, that should be perfect fine. Instead, the most the Mac has been able to cobble together is a simple split screen view and that is only for Full Screen.
And, we also have: Xcode with its own completely custom and quirky pane/tab management scheme, terminals with their own pane/tab scheme, browsers with their own tabs, etc. Individual applications continue to feel some need to over-engineer their own pane/window management to compensate for lack of system support.
There are some signs of hope though. The direction Apple is going with Mac view controllers could theoretically put them in a position to finally turn individual views into first-class citizens that would be feasible to interleave arbitrarily across applications. At that point, command-line tools could integrate very nicely in arbitrary ways with elements that really benefit from being graphical. We’ll see.
I have been using https://www.spectacleapp.com/ for a while now, and it has performed like a champ. Easy window resizing and organization with keyboard shortcuts.
That is not my experience at all using Xcode professionally for the past 3+ years, and Visual Studio for over 7 years. Most of the complaints I've heard from colleagues about Xcode seemed from using unofficial 3rd party plugins, or Xcode's inferior c++ support for massive projects haphazardly ported form windows.
Xcode for iOS and Mac development has been the most productive IDE I've used professionally, not without its flaws, and unintuitive nuances, but continually improving. Yearly major ticket feature additions like UI Unit testing shows me Apple is still heavily investing in developer tools.
I find Xcode quite a joy to use. It seems well laid-out, not a lot of UI chrome, easy to find the things you need and get things out of the way when you don't. Code completion, debugging, it's all pretty great for me. Not sure if the degree of your hate for it is accurate.
I agree. I don't even need very permissive license, just to look at sources would be enough. Sometimes I have to lurk around internet corners just to find out simple things which would require few minutes with source code access. It's so frustrating after Java environment where almost everything is available in source code.
The "source" is almost out there. Attaching the debugger to a 64-bit simulator and putting a breakpoint on Apple methods and functions, you can effortlessly read the disassembler code output by lldb/Xcode. I have fixed and learned countless UIKit-related bugs like that.
As someone who refused to sink any significant time into Swift until they open-sourced it, I have found it to be the most productive statically-typed, native language out there. Its type system feels like the best of C# and Rust, while it feels that the speed at which one can pick it up is not that much greater than that of Go despite being a much richer language, (I've started learning in January and am at the level now where I can take on a fairly complex Swift project and feel comfortable about being able to finish it in time, plus I now use Swift for almost any programming task, 90% of them at least).
Plus, you have to give Apple credit for getting the open-source release right, (GitHub, pull requests, proposals, mailing lists, frequent dev builds, Linux support - I guess Chris Lattner has been the one driving this, but I have to give credit to Craig Federighi and Tim Cook for letting him do it.)
The only part that frustrates me is that SourceKit seems to crash every other minute for no apparent reason - but that is no fault of the language itself.
Swift is the first piece of Apple software I'm genuinely excited for.
Congrats to everyone who contributed to the 2.2 release
e.g.? I've only just scratched the surface of Rust and dismissed C# as a Java clone (but maybe I shouldn't have?). What's some examples of the best of Swift that you see?
One case where C# is far superior to Java is generics.
Generics were a cutting-edge feature in 2005. Microsoft took the opportunity to start from scratch, and released the .Net Framework 2.0 without backwards-compatibility, and with full support for generics. A List<String> is actually a List of String.
When Sun released Java 5, they didn't want to disrupt the established Java ecosystem. Their implementation is called "type erasure". As an example, List<String> is actually just List<Object>, with automatic runtime typecasting to String. https://docs.oracle.com/javase/tutorial/java/generics/erasur...
Java's solution works well enough, but it breaks down in certain scenarios, such as multiple levels of generics. For example, when getting an element from a List<List<String>>, Object is not cast to List<String> (which doesn't really exist), but merely List.
When does it matter what an element from a List<List<String>> is cast to at runtime? In a properly-written statically-typed program, types are a compile-time construct (ignoring the machinery of dynamic linking and method call semantics in particular implementations, which don't matter to the programmer), and though you may use them at runtime via reflection, I would argue that 99% of the time that you do, you're writing bad code. http://stackoverflow.com/questions/20918650/what-are-the-ben...
Type erasure introduces limitations on what you can do at runtime that forces a developer to write code to workaround it. For example, in Java you can't write a generic method that instantiates an object based on the type of the generic. The workaround is typically to pass in the Class type as an additional parameter to the method, which in theory should not be necessary. A lot of JVM-based languages are required to introduce additional complexity in the language to simulate reified generics (e.g. Scala's Manifest/TypeTag classes).
> A lot of JVM-based languages are required to introduce additional complexity in the language to simulate reified generics (e.g. Scala's Manifest/TypeTag classes).
I'm not sure how this makes sense. These tags are just standard context bounds, which are extremely useful and quite awesome.
You make it sound as if these tags were some kind of special feature added to the language, or context bounds were solely invented to support these tags.
> For example, in Java you can't write a generic method that instantiates an object based on the type of the generic. The workaround is typically to pass in the Class type as an additional parameter to the method, which in theory should not be necessary.
If a method needs to instantiate an object, the normal technique is to accept a factory function as a parameter. You can do the same thing with type-erased generics.
C# decided to create a shortcut for calling the constructor of a generic type parameter. But, for example, you can't call static methods of a generic type parameter (and a constructor is really just a slightly special static method).
Passing in the class type for instantiating a new instance is not what you should do in your applications. You don't know at compile time if the class you pass in has a default constructor, so your program can fail at runtime. As others have stated, the right thing to do is pass in a factory object. C# solves this by adding even more cruft to the language in the form of a "new constraint" that tells the compiler to ensure that the type has a default constructor. https://msdn.microsoft.com/en-us/library/sd2w2ew5.aspx
It was still a language feature even if it wasn't available 100% bug free in all C++ compilers.
C code also used to break left and right long after C90 was approved.
I had to use K&R C style code in 1999 because the HP-UX compiler at a customer location didn't knew any better, but that didn't mean other C features weren't available elsewhere.
> I had to use K&R C style code in 1999 because the HP-UX compiler at a customer location didn't knew any better, but that didn't mean other C features weren't available elsewhere.
Curious, what did you need to do specifically? Parameter declarations weren't inlined?
But anyway, C, being smaller, breaks in fewer ways
Templates are not proper generics. Templates can be used to emulate generics, but they are not the same thing at all. Templates are not first-class citizen of the type system (they don't survive to the typechecking phase), while generics are. You cannot write a generic list implementation in C++ and have it typechecked.
I'd like to hear more about that because I'm not sure I understand. Can you give an example for something you cannot do in C++ in a type safe way that you can do in C#, Java or Swift?
I already gave one. You can't write a generic list implementation and make the compiler prove your code is sound (according to the rules of the C++ type system) for any valid type argument value.
I'm absolutely aware of enable_if, type traits and SFINAE. But they do not address the concern I raised here. The things you mention come to play on template instantiation, after the concrete (non-generic) types are already known.
The problem I mention is that with templates you cannot type check generic code. I can put whatever nonsense enable_ifs on my template declaration and the compiler does not check if they are satisfied by the implementation.
You can write the following C++ code and C++ allows it:
This is perfectly fine for a macro system. But this is not how truly generic type system would work. If templates were proper generics, the typechecker would immediately refuse this to compile saying something like:
"Error: I can't prove T has the bar() member."
> C++ templates are Turing complete, you can validate whatever you feel like at compile time.
So please write a template metaprogram that validates if a given C++ class (input to the program, given as a template argument) matches a table schema in the database system (the table name and connection string are also given as template arguments). For fetching the schema, you have to connect to the DB, of course at compile time. If the schema does not match, the compilation should fail ;)
Because whoever wrote foo () was too lazy to make use of type traits and validate that T has a method called bar with zero arguments.
Do you want an example how to write it properly?
With or without the upcoming concepts TS already in GCC 6.0?
Also this example would require T to be an interface with a bar method in C#. Do you also want to the the variant with MI and pure abstract classes in C+?
> Because whoever wrote foo () was too lazy to make use of type traits and validate that T has a method called bar with zero arguments.
In a proper generic type system, the compiler validates it, not the programmer. Even if you constrain the type using type traits, the compiler would not check if the implementation satisfies the constraints. I can put a type trait for existence of bar() and then another programmer may rename bar() to baz() forgetting to update the constraint and the code will still compile fine.
I don't think concepts are even necessary to do what pkolaczk wants to do, which is (I think) to constrain the argument to a particular interface, say Bar:
The body of the template won't be typechecked until the instantiation of the template. This is different than in C#. If I replaced arg.bar with arg.baz in C#, the generic type definition would not compile, even if I never use it. In C++ I can't write a template and have it typechecked for all possible input types satisfying the type constraints, in C# I can. So C++ type system is weaker than that of C#.
I see what you mean, but uninstantiated also means unused. So we're not talking about anything that could possibly lead to runtime errors. It's not an issue with type safety.
It definitely has a downside for the development process, especially when it comes to writing libraries. But it is also to some degree inevitable if you want structural typing. Maybe there is a better way to do it though.
I think of templates as an automated copy+paste mechanism. C++ templates can bloat the compiled executable pretty significantly... If you define a generic Foo<String> and Foo<Widget>, C++ templates will generate two separate binary implementations. C# will use the same implementation, and perform type checks using reflection at runtime.
Further support for the idea that C++ templates are an automated copy+paste mechanism is that you're allowed to give templates arguments that are not types.
It is not how you think of them, rather what is possible to do with their expressiveness.
C# type checks imply a performance hit and are an implementation detail. Nothing prevents a C# compiler to choose another one. It has nothing to do with generics vs templates.
For example Modula-3 and Ada compilers use the same approach as C++ for code generation of their generics.
So where is that example of something that can only be written with C# generics, but not with C++ templates?
It is not the case of what can only be written, but what can be written and typechecked. C# generics offer much stronger type safety for library writers than C++ templates.
C++ templates are not type-checked. C# (and Java, and Scala and Haskell) generics are.
No, they are not. This code compiles fine, despite an obvious non-generic type-error. You may add whatever number of type traits, constexprs, etc there, and it will still compile fine as long as syntax is ok.
#include <string>
template <typename T>
void foo(const T& arg) {
int x = std::string("int expected");
}
$ g++ -c template.cpp
$ // see, no error
Templates are only syntax-checked. The type checker is not even executed on the non-generic code inside of templates. The type checker will be executed after the template is instantiated (expanded). At that point, generic types do not exist. There exist only concrete types.
Sure, you can type-check them for particular type arguments. But you can't type-check them generally at the generic level and you have absolutely no guarantee that your library code is free of type errors. Not a problem if the goal is to produce the final executable, but a big problem for a library writer, who doesn't control the inputs (in this case: the types provided by the user of the library).
And AFAIK C++17 concepts do not address this problem, really. I can constrain my input types with them, and the calling code will be forced to conform to them (and the compiler will present a nice error message if it doesn't), but there is still no checking on the other side - that is if the template implementation is correct assuming these constraints. I can publicly declare my code requires T.bar(), then shamelessly call T.baz() in the template implementation and the compiler will not catch it.
This is like a Python program. You don't know if it type-checks before you run it, but even if you run it once or twice and it was fine, that doesn't guarantee there are no type errors.
The code line int x = std::string("int expected"); has zero relation with any of the template arguments.
So a programmer error that doesn't have anything to do with the types provided for the template.
Sure it will be caught in C#, because its build model assumes the existence of modules and everything is compiled to binary.
In C++ a similar compilation error would occur when compiling the translation unit into a library where the template is instantiated.
Of course, most templates being header only the error will only occur when instating it, but it will still blow on compilation and prevent the final generation of the exe, dll being produced.
Also errors related to semantic type check, independent of template arguments is relatively easy to achieve with unit tests.
I still fail to see how a generic system that doesn't offer partial specialization or meta-programming as being more powerful than templates.
I never said more powerful. I said stronger. In C++ you need unit tests to check something I can have statically proven in C#. And obviously you can't instantiate your template for all possible valid input types, because this number can be infinite.
Monomorphisation is the name of the technique of producing a different version of the code for each set of type parameters that are used in the program. C++ and Rust use monomorphisation instead of doing runtime checks because they're trading off slightly bigger binaries for greater speed.
By not doing runtime checks you get to skip that work at runtime, obviously, but you also get to enable other optimizations like inlining the monomorphised version.
Templates are a macro system. Macro systems are often Turing-complete. But if being Turing-complete was the only important thing in programming, then we'd all code in assembly and never look forward. Most programming languages are Turing-complete, but this doesn't mean they are practically equivalent for every job. You know, Brainfuck is also Turing-complete, but you'd be probably pissed-off if I said heavy-templated C++ code readability is often close to that of Brainfuck.
Macro systems can be very powerful, but they are also quite hard to use. It is 2016 and error messages in C++ templates are still inferior to the messages you get in C#, Java or Scala generics, despite templates existing for much longer.
C++ templates are also not the very best at metaprogramming either. Take any macro system like the ones found in LISPs, Scala or Template Haskell - they are much more powerful and consistent with the rest of the language. I can code Scala metaprograms in Scala or LISP metaprograms in LISP. But I can't code C++ metaprograms in C++, I have to use this weird duck-typed functional template language which doesn't have even loops or conditionals.
> That weird duck typed functional template language runs circles around C# and Java generics
This sentence doesn't make much sense. Comparing oranges and apples. It is like saying Scala macros are better than Scala generics. C++ templates are neither great at metaprogramming (there are much better macro systems in other languages out there) nor great at generics (Java, C# or Swift generics are not state-of-the-art either, but in some cases I mentioned they are better).
One case where Java generics are far superior to C# (actually CLR) is implementing more advanced generics on top of JVM thanks to erasure. C# generics are too weak to express concepts found in Scala or Haskell type system directly, but at the same time too strong to serve as a base for a standalone implementation of such type systems.
Having worked with both for several years, I would rate C# as a much better language than Java. The language by itself is noticeably better, but the difference is even more pronounced if you include the ecosystem -- Visual Studio vs. Java IDEs, the class libraries, ASP.NET MVC vs. Struts and its ilk. I would check it out if you have the need to do any Windows-related programming. (Not sure how great the support is outside Windows.)
Uh, when was the last time you worked with Java? Struts isn't a popular framework anymore and hasn't been for awhile.
IntelliJ absolutely trounces VSS and some combination of Spring Boot, DropWizard or Vert.x blows ASP.NET MVC away. Not to mention the whole ecosystem is a hell of a lot more open. There is a library for just about anything under the sun.
Enterprise environments tend to be very conservative when it comes to stuff they let you install or even use. Often you can't just drop JARs in there, never mind use your own JRE. So you're often stuck with technology that sites like these consider quite ancient…
It gets even worse on desktops, as sysadmins might be able to isolate a server enough to allow some "new" tech, but vetting a new Java version or library for a few thousand office desktops is a task nobody really wants to do. So I wouldn't be surprised to still see some Java 1.4 Swing apps in use at big insurance or pharma companies. (And if I'd had to pick between that or do a web app that supports their IE8 browsers…)
"Enterprise environments" also have to be very conservative about security issues - which often means they're forced to update to currently supported versions of software. Java 8 is the only version currently receiving security updates.
The same thing applies to many other software packages, including browsers, Linux and Spring. Sane IA folks don't like to deploy known security holes.
It sounds like you're dealing with some backwards-thinking folk. ;-)
We are talking about enterprise here, so backwards-thinking is part of the package. And if you're big enough, you can get by with outdated standard software, either by hiring special consultants or by costly vendor support. I'm pretty sure you can "convince" Oracle to accept your money.
The alternative is auditing all your installed software packages with Java dependencies. Re-hire the agency that did that small Swing client 8 years ago. Hire someone completely new to reverse engineer another client because the original company went belly up. Ad infinitum, ad nauseam.
No wonder they'll do software cryonics.
This is getting better slightly in recent years, when you no longer have that many desktop clients and utilities, as upgrading servers is way easier than building new default images for all your desktop clients.
You are really dating yourself with Struts. That's early 2000s Java tech. Intellij, Java 1.8 and Spring Boot are really nice tools that you're missing out on.
Ah that could definitely be. Back when I switched from Java to C# there was a big difference, even just from having access to lambdas, LINQ, sane generics, etc. But it sounds like Java has gotten better on all fronts, which is great. The main thing I wanted to get across is that while C# has its roots in cloning Java, it ended up being far more than just a clone.
It definitely looks like that, but I'll take C# over Java any day
Java API looks like it was built by the worse bureaucrats they could find and one piece doesn't fit another except in a very specific (non-obvious) way
Some of the things off the top of my head in no particular order; protocols, (closer to traits than interfaces), Optional types, (elsewhere no null types), pattern matching (if let, case let), guards, (so you can cover your preconditions nicely), immutable let bindings first, var variables second, (with mutability being tied to the binding outsite of reference types/classes), tuples, lazy evaluation, flexible closure syntax, fairly powerful type inference, enums as tagged unions, (or as standard C enums if you want), extensions - even for core structures if you need it - straighforward way to define custom or overload existing operators, type system powerful enough to be able to implement a fairly convincing Functor, Applicative or Monad without much effort, structs AND classes, most things are value types...
But most importantly to me, Swift is composed in such a way that it just 'clicks' for me, ie many times many times I can guess how something is likely called or how it will behave without looking at the docs and I have a solid chance of being right - that 'intuitiveness' is something that is lacking in many other languages I've used over the years.
In regards to C#, by now it is definitely not just a Java clone anymore, in particular saner type system and much more functional features edge it for me over Java, plus the speed of evolution is much greater in the C# land.
If you want to see how C# and Java differ but are tied to the JVM, try Kotlin: http://kotlinlang.org - it's fairly similar in feel to C# and has 100% Java compatibility.
I love Swift dearly - I spent two years in Objective C land, after 8 years of C# and 10-ish years of C++ pain, and started using Swift day to day from Swift 1.2. But the current version have one big gaping hole: generic protocols are utter shit. For the uninitiated: Swift generic protocols don't have generic parameters, they have type constraints. Which means that a function can't return generic protocol. Which is the stupidest thing ever.
There's a way to dance around that restriction, by making an intermediate class to do type erasure by hand (why I should do that? That's compiler's job), but still - Swift crew are obviously very talented bunch with a good taste, how they allowed such nonsense from the start?
PS I don't want to sound too negative, Swift replaced C# as my favorite language, 95% of the time it's joy to use (especially after Objective C, I never agreed with that language), it's just - the generic protocol thing drives me mad.
Yeah, somewhat related to that; it's not currently possible to have typealias for a type with generic parameters, one has to wrap it in a struct or an enum, however Swift is very much not done and they're catching up quickly, so I'm optimistic, especially now that we can see and affect what's coming next.
Awesome!
This is what I'm talking about; now that Swift is open-source we can see which improvements have landed and what is coming next.
Thanks for the link.
i can't believe how much people here on HN love swift! do you guys really love stuff like implicitly unwrapped optionals and awkward syntax where you need exclamation marks all over the place. not to mention their insanely complicated use of enumerations. what about a completely half-baked standard libraries where even basic string operations such as doing a substring are unnecessarily complicated and verbose? i simply cannot see any real basis for all the love for swift.
This only exists for objective-c introp, and the creators are actively trying to find ways to get rid of it. On the other hand, in nearly every other language, all pointers would be considered implicitly unwrapped optionals, while in Swift you get optionals built in (food for thought).
>awkward syntax where you need exclamation marks all
Oh come on, syntax does not define a language. If they used a different character or an operator, would you be more happy? Either way, it does take some getting used to but eventually it feels natural.
>insanely complicated use of enumerations
What?! This is one of my favorite features! You can represent so many things with an enum and it can make your code much safer. My favorite two examples are representing JSON as an enum, and the fact that Swift's Optional is actually just an enum with cases .none and .some(T).
>basic string operations such as doing a substring are unnecessarily complicated and verbose
I somewhat agree with you on this. They have their reasons (mostly because strings can have varying sizes, so indexing a utf8 string, for example, can give unexpected results) but I still wish they did something about it.
118 comments
[ 2.9 ms ] story [ 175 ms ] threadhttps://github.com/apple/swift-evolution/blob/master/proposa...
https://github.com/apple/swift-evolution/blob/master/proposa...
In Swift 3.0 they'll remove the deprecated syntaxes.
https://github.com/apple/swift-evolution/blob/master/proposa...
https://github.com/apple/swift-evolution/blob/master/proposa...
I just spent a while reading about both stride and for ... in, and I feel like there are any number of cases where I would rather use a C-style for loop.
for i in range(10):
instead.
for item in sequence:
which is somewhat general (sequences include lists, dicts, strings, tuples, generators, text files and more [2]), and it covers a wide range [1] of use cases.
[1] Pun not intended.
[2] Basically, any iterable. This include custom iterables you can define, which can then be iterated over using the same standard for loop. A unifying feature of the language:
"The use of iterators pervades and unifies Python."
https://docs.python.org/2/tutorial/classes.html#iterators
Could you use a while loop instead?
I feel like (as long as the numerical case optimizes to the same thing) the for-in loop (and occasional use of the while loop) is clearer.
// old
for x: Thing? = thing; x != nil; x = x.parent {
}// and now
var x: Thing? = thing
while x != nil {
}It was the only case i've really missed it.. unless theres a better way to do it that im not aware of..
But the for c-style loop for numbers is really not needed
Of course, it would be more Swifty to create a "Parentable" protocol and write that as an extension of it!
I’m thoroughly convinced that Apple has an internal-only IDE that they use that is far better than Xcode and is actually functional, much like the internal Radar tool. There is no way Apple’s engineers could get any work done if they use Xcode.
Or, they should start charging money for it so they could justify spending resources on the dev tools. One of the reasons (among many) that Visual Studio is still the king of all IDEs is because Microsoft charges money for the serious bits of it (Pro and higher).
I'm sorry, but LLVM?
That's an interesting point and it makes a lot of sense. With the scale of the codebases a lot of them are working on I also don't see how they could be productive while working in XCode. And also XCode could not be this buggy and broken if it had internal developers working with it and constantly reporting bugs.
personally, I'm the kind of guy with a "vim 4 life" tattoo, so I don't really know why people put up with crappy IDEs...
I've never liked Visual Studio, and the last time I worked on a serious Windows product most of the experienced developers used WinDbg and cordbg rather than the neutered Visual Studio debugger. And some guys still wrote their code in Visual Studio 6 rather than the newer .NET IDEs.
My problem with Xcode today is that it's too much like Visual Studio. I'll take Xcode 3 with LLDB any day.
What I want is a way to take any view I please, from any application, and arrange it anywhere in a standard way with keyboard support and sensible omissions of chrome. If this means 65% of my screen is terminals, 20% web browsers, 10% some graphical view from Xcode and 5% notifications, that should be perfect fine. Instead, the most the Mac has been able to cobble together is a simple split screen view and that is only for Full Screen.
And, we also have: Xcode with its own completely custom and quirky pane/tab management scheme, terminals with their own pane/tab scheme, browsers with their own tabs, etc. Individual applications continue to feel some need to over-engineer their own pane/window management to compensate for lack of system support.
There are some signs of hope though. The direction Apple is going with Mac view controllers could theoretically put them in a position to finally turn individual views into first-class citizens that would be feasible to interleave arbitrarily across applications. At that point, command-line tools could integrate very nicely in arbitrary ways with elements that really benefit from being graphical. We’ll see.
Yup! They're free! I have found Apple's developer ecosystem to be fantastic overall.
Xcode for iOS and Mac development has been the most productive IDE I've used professionally, not without its flaws, and unintuitive nuances, but continually improving. Yearly major ticket feature additions like UI Unit testing shows me Apple is still heavily investing in developer tools.
You mean by still not being able to provide an working experience to the NDK users, three years later?
Or by redoing their plugins for Android Studio 2.0, forcing devs that rely on something stable to still be on Android Studio 1.5?
Also by having each release be a bug party that make people at /r/androiddev/ wonder if they ever test what they release?
The only part that frustrates me is that SourceKit seems to crash every other minute for no apparent reason - but that is no fault of the language itself.
Swift is the first piece of Apple software I'm genuinely excited for. Congrats to everyone who contributed to the 2.2 release
e.g.? I've only just scratched the surface of Rust and dismissed C# as a Java clone (but maybe I shouldn't have?). What's some examples of the best of Swift that you see?
Generics were a cutting-edge feature in 2005. Microsoft took the opportunity to start from scratch, and released the .Net Framework 2.0 without backwards-compatibility, and with full support for generics. A List<String> is actually a List of String.
When Sun released Java 5, they didn't want to disrupt the established Java ecosystem. Their implementation is called "type erasure". As an example, List<String> is actually just List<Object>, with automatic runtime typecasting to String. https://docs.oracle.com/javase/tutorial/java/generics/erasur...
Java's solution works well enough, but it breaks down in certain scenarios, such as multiple levels of generics. For example, when getting an element from a List<List<String>>, Object is not cast to List<String> (which doesn't really exist), but merely List.
C#'s implementation of generics became even more sophisticated with C#4, which introduced covariance and contravariance. https://msdn.microsoft.com/en-us/library/ee207183.aspx
Generics have been around since at least the early '80s.
Another interesting failed prototype on the JVM was the language "Pizza" https://en.wikipedia.org/wiki/Pizza_%28programming_language%...
https://en.wikibooks.org/wiki/Ada_Programming/Generics
http://www.cs.dartmouth.edu/reports/TR86-104.pdf
(From 1984.)
I'm not sure how this makes sense. These tags are just standard context bounds, which are extremely useful and quite awesome.
You make it sound as if these tags were some kind of special feature added to the language, or context bounds were solely invented to support these tags.
If a method needs to instantiate an object, the normal technique is to accept a factory function as a parameter. You can do the same thing with type-erased generics.
C# decided to create a shortcut for calling the constructor of a generic type parameter. But, for example, you can't call static methods of a generic type parameter (and a constructor is really just a slightly special static method).
I was already using C++ templates in 1994 with Borland C++ for Windows 3.1!
Ada, CLU and ML go back to the late 70's / early 80's.
It certainly worked at the time, for that specific compiler
C code also used to break left and right long after C90 was approved.
I had to use K&R C style code in 1999 because the HP-UX compiler at a customer location didn't knew any better, but that didn't mean other C features weren't available elsewhere.
Curious, what did you need to do specifically? Parameter declarations weren't inlined?
But anyway, C, being smaller, breaks in fewer ways
In those days HP-UX C compiler was still transitioning between K&R and ANSI standards.
We could only properly compile without strange errors while using K&R function declarations.
If memory serves me right, it was the first HP-UX release having support for 64bit file systems.
C++ templates are Turing complete, you can validate whatever you feel like at compile time.
You can write the following C++ code and C++ allows it:
<template typename T> void foo(const T& arg) { arg.bar(); }
This is perfectly fine for a macro system. But this is not how truly generic type system would work. If templates were proper generics, the typechecker would immediately refuse this to compile saying something like: "Error: I can't prove T has the bar() member."
> C++ templates are Turing complete, you can validate whatever you feel like at compile time.
So please write a template metaprogram that validates if a given C++ class (input to the program, given as a template argument) matches a table schema in the database system (the table name and connection string are also given as template arguments). For fetching the schema, you have to connect to the DB, of course at compile time. If the schema does not match, the compilation should fail ;)
Do you want an example how to write it properly?
With or without the upcoming concepts TS already in GCC 6.0?
Also this example would require T to be an interface with a bar method in C#. Do you also want to the the variant with MI and pure abstract classes in C+?
In a proper generic type system, the compiler validates it, not the programmer. Even if you constrain the type using type traits, the compiler would not check if the implementation satisfies the constraints. I can put a type trait for existence of bar() and then another programmer may rename bar() to baz() forgetting to update the constraint and the code will still compile fine.
I do admit that I need to update myself with what GCC 6.0 allows vs the letter of the TS.
It definitely has a downside for the development process, especially when it comes to writing libraries. But it is also to some degree inevitable if you want structural typing. Maybe there is a better way to do it though.
Further support for the idea that C++ templates are an automated copy+paste mechanism is that you're allowed to give templates arguments that are not types.
Further reading: https://msdn.microsoft.com/en-us/library/c6cyy67b.aspx
C# type checks imply a performance hit and are an implementation detail. Nothing prevents a C# compiler to choose another one. It has nothing to do with generics vs templates.
For example Modula-3 and Ada compilers use the same approach as C++ for code generation of their generics.
So where is that example of something that can only be written with C# generics, but not with C++ templates?
A github gist maybe?
That is what enable_if, type traits, if constexpr and eventually concepts allow for.
Uninstantiated templates are dead code that will be stripped anyway.
Sure, you can type-check them for particular type arguments. But you can't type-check them generally at the generic level and you have absolutely no guarantee that your library code is free of type errors. Not a problem if the goal is to produce the final executable, but a big problem for a library writer, who doesn't control the inputs (in this case: the types provided by the user of the library).
And AFAIK C++17 concepts do not address this problem, really. I can constrain my input types with them, and the calling code will be forced to conform to them (and the compiler will present a nice error message if it doesn't), but there is still no checking on the other side - that is if the template implementation is correct assuming these constraints. I can publicly declare my code requires T.bar(), then shamelessly call T.baz() in the template implementation and the compiler will not catch it.
This is like a Python program. You don't know if it type-checks before you run it, but even if you run it once or twice and it was fine, that doesn't guarantee there are no type errors.
The code line int x = std::string("int expected"); has zero relation with any of the template arguments.
So a programmer error that doesn't have anything to do with the types provided for the template.
Sure it will be caught in C#, because its build model assumes the existence of modules and everything is compiled to binary.
In C++ a similar compilation error would occur when compiling the translation unit into a library where the template is instantiated.
Of course, most templates being header only the error will only occur when instating it, but it will still blow on compilation and prevent the final generation of the exe, dll being produced.
Also errors related to semantic type check, independent of template arguments is relatively easy to achieve with unit tests.
I still fail to see how a generic system that doesn't offer partial specialization or meta-programming as being more powerful than templates.
By not doing runtime checks you get to skip that work at runtime, obviously, but you also get to enable other optimizations like inlining the monomorphised version.
Macro systems can be very powerful, but they are also quite hard to use. It is 2016 and error messages in C++ templates are still inferior to the messages you get in C#, Java or Scala generics, despite templates existing for much longer.
C++ templates are also not the very best at metaprogramming either. Take any macro system like the ones found in LISPs, Scala or Template Haskell - they are much more powerful and consistent with the rest of the language. I can code Scala metaprograms in Scala or LISP metaprograms in LISP. But I can't code C++ metaprograms in C++, I have to use this weird duck-typed functional template language which doesn't have even loops or conditionals.
I have experience in compiler design and C#, Java and C++ are my tools of trade. So I know their generics systems pretty well.
Maybe if I get bored during Easter I can bother to provide your safe list.
This sentence doesn't make much sense. Comparing oranges and apples. It is like saying Scala macros are better than Scala generics. C++ templates are neither great at metaprogramming (there are much better macro systems in other languages out there) nor great at generics (Java, C# or Swift generics are not state-of-the-art either, but in some cases I mentioned they are better).
IntelliJ absolutely trounces VSS and some combination of Spring Boot, DropWizard or Vert.x blows ASP.NET MVC away. Not to mention the whole ecosystem is a hell of a lot more open. There is a library for just about anything under the sun.
It gets even worse on desktops, as sysadmins might be able to isolate a server enough to allow some "new" tech, but vetting a new Java version or library for a few thousand office desktops is a task nobody really wants to do. So I wouldn't be surprised to still see some Java 1.4 Swing apps in use at big insurance or pharma companies. (And if I'd had to pick between that or do a web app that supports their IE8 browsers…)
The same thing applies to many other software packages, including browsers, Linux and Spring. Sane IA folks don't like to deploy known security holes.
It sounds like you're dealing with some backwards-thinking folk. ;-)
The alternative is auditing all your installed software packages with Java dependencies. Re-hire the agency that did that small Swing client 8 years ago. Hire someone completely new to reverse engineer another client because the original company went belly up. Ad infinitum, ad nauseam.
No wonder they'll do software cryonics.
This is getting better slightly in recent years, when you no longer have that many desktop clients and utilities, as upgrading servers is way easier than building new default images for all your desktop clients.
It definitely looks like that, but I'll take C# over Java any day
Java API looks like it was built by the worse bureaucrats they could find and one piece doesn't fit another except in a very specific (non-obvious) way
But most importantly to me, Swift is composed in such a way that it just 'clicks' for me, ie many times many times I can guess how something is likely called or how it will behave without looking at the docs and I have a solid chance of being right - that 'intuitiveness' is something that is lacking in many other languages I've used over the years.
In regards to C#, by now it is definitely not just a Java clone anymore, in particular saner type system and much more functional features edge it for me over Java, plus the speed of evolution is much greater in the C# land. If you want to see how C# and Java differ but are tied to the JVM, try Kotlin: http://kotlinlang.org - it's fairly similar in feel to C# and has 100% Java compatibility.
There's a way to dance around that restriction, by making an intermediate class to do type erasure by hand (why I should do that? That's compiler's job), but still - Swift crew are obviously very talented bunch with a good taste, how they allowed such nonsense from the start?
PS I don't want to sound too negative, Swift replaced C# as my favorite language, 95% of the time it's joy to use (especially after Objective C, I never agreed with that language), it's just - the generic protocol thing drives me mad.
> error: opening import file for module 'SwiftShims': No such file or directory
Apparently the problem with GCC ABI break hasn't been tackled yet.
https://bugs.swift.org/browse/SR-23
As info, the only workaround is to rebuild Swift from scratch.
This only exists for objective-c introp, and the creators are actively trying to find ways to get rid of it. On the other hand, in nearly every other language, all pointers would be considered implicitly unwrapped optionals, while in Swift you get optionals built in (food for thought).
>awkward syntax where you need exclamation marks all
Oh come on, syntax does not define a language. If they used a different character or an operator, would you be more happy? Either way, it does take some getting used to but eventually it feels natural.
>insanely complicated use of enumerations
What?! This is one of my favorite features! You can represent so many things with an enum and it can make your code much safer. My favorite two examples are representing JSON as an enum, and the fact that Swift's Optional is actually just an enum with cases .none and .some(T).
>basic string operations such as doing a substring are unnecessarily complicated and verbose
I somewhat agree with you on this. They have their reasons (mostly because strings can have varying sizes, so indexing a utf8 string, for example, can give unexpected results) but I still wish they did something about it.