Slashdot Mirror

You asked, he answered! The creator of Apple's Swift programming language (and a self-described "long-time reader/fan of Slashdot") stopped by on his way to a new job at Tesla just to field questions from Slashdot readers. Read on for Chris's answers... Questions, and my best wishes.
by Volanin

Since you're the creator of LLVM, I'd like to know, in your opinion what's the greatest advantage of LLVM/Clang over the traditional and established GNU GCC compiler. Also, what's the greatest advantage of GNU GCC (or if you'd prefer, any other compiler) over LLVM/Clang, something that you'd like to "port" someday?

CL: GCC and LLVM/Clang have had a mutually beneficial relationship for years. Clang's early lead in terms of compiler error message expressivity has led the GCC developers to improve their error messages, and obviously GCC provides a very high bar to meet when LLVM and Clang were being brought up. It is important to keep in mind that GCC doesn't have to lose for Clang to win (or visa versa). Also, I haven't used GCC for many years, that said, since you asked I'll try to answer to the best of my knowledge:

From my understanding, for a C or C++ programmer on Linux, the code generated by GCC and Clang is comparable (each win some cases and lose other cases). Both compilers have a similar feature set (e.g. OpenMP is supported by both). Clang compiles code significantly faster than GCC in many cases, still generates slightly better errors and warning messages than GCC, and is usually a bit ahead in terms of support for the C++ standard. That said, the most significant benefit is improved compile time.

Going one level deeper, the most significant benefit I see of the LLVM optimizer and code generator over GCC is its architecture and design. LLVM is built with a modular library-based design, which has allowed it to be used in a variety of ways that we didn't anticipate. For example, it has been used by movie studios to JIT compile and optimize shaders used in special effects, has been used to optimize database queries, and LLVM is used as the code generator for a much wider range of source languages than GCC.

Similarly, the most significant benefit of Clang is that it is also modular. It specifically tackles problems related to IDE integration (including code completion, syntax highlighting, etc) and has a mature and vibrant tooling ecosystem build around it. Clang's design (e.g. lack of pervasive global variables) also allows it to be used at runtime, for example in OpenCL and CUDA implementations.

The greatest advantage I can see of GCC over LLVM/Clang is that it is the default compiler on almost all Linux distributions, and of course Linux is an incredibly important for developers. I'd love to see more Linux distributions start shipping Clang by default. Finally, GCC provides an Ada frontend, and I'm not aware of a supported solution for Ada + LLVM.

Future of LLVM?
by mveloso

Where do you see LLVM going?

CL: There are lots of things going on, driven by the amazing community of developers (which is growing like crazy) driving forward the llvm.org projects. LLVM is now used pervasively across the industry, by companies like Apple, Intel, AMD, Nvidia, Qualcomm, Google, Sony, Facebook, ARM, Microsoft, FreeBSD, and more. I'd love for it to be used more widely on Windows and Linux.

At the same time, I expect to see LLVM to continue to improve in a ton of different ways. For example, ThinLTO is an extremely promising approach that promises to bring scalable link time optimization to everyone, potentially replacing the default for -O3 builds. Similarly, there is work going on to speed up compile times, add support for the Microsoft PDB debug information format, and too many other things to mention here. It is an incredibly exciting time. If you're interested in a taste of what is happening, take a look at the proceedings from the recent 2016 LLVM Developer Meeting.

Finally, the LLVM Project continues to expand. Relatively recent additions include llgo (a Go frontend) and lld (a faster linker than "Gold"), and there are rumors that a Fortran frontend may soon join the fold.

The Mythical Compiler -VLIW
by Anonymous Coward

Is there any hope for VLIW architectures? The general consensus seems to be that Itanium tanked because the compiler technology wasn't able to make the leap needed. Linus complained about the Itanium ISA exposing the pipelines to assembly developers. What are the challenges from a compiler writers perspective with VLIW?

CL: I can't speak to why Itanium failed (I suspect that many non-technical issues like business decisions and schedule impacted it), but VLIW is hardly dead. VLIW designs are actively used in some modern GPUs and is widely used in DSPs - one example supported by LLVM is the Qualcomm Hexagon chip. The major challenge when compiling for a VLIW architecture is that the compiler needs good profile information, so it has an accurate idea of the dynamic behavior of the program.

How much of Swift is Based on Groovy?
by Anonymous Coward

So how much of Swift was inspired by Groovy? Both come from more high-end languages and look and act almost identical.

CL: It is an intentional design point of Swift that it look and feel "familiar" to folks coming from many other languages: not just Groovy. Feeling familiar and eliminating unnecessary differences from other programming languages is a way of reducing barriers of entry to start programming in Swift. It is also clearly true that many other languages syntactically influence each other, so you see convergence of ideas coming from many different places.

That said, I think it is a stretch to say that Swift and Groovy look and act "identical", except in some very narrow cases. The goal of Swift is simply to be as great as possible, it is not trying to imitate some other programming language.

C#
by Anonymous Coward

What do you think about Microsoft and C# versus the merits of Swift?

CL: I have a ton of respect for C#, Rust, and many other languages, and Swift certainly benefited by being able to observe their evolution over time. As such, there are a lot of similarities between these languages, and it isn't an accident.

Comparing languages is difficult in this format, because a lot of the answers come down to "it depends on what you're trying to do", but I'll give it a shot. C# has the obvious benefit of working with the .NET ecosystem, whereas Swift is stronger at working in existing C and Objective-C ecosystems like Cocoa and POSIX.

From a language level, Swift has a more general type system than C# does, offers more advanced value types, protocol extensions, etc. Swift also has advantages in mobile use cases because ARC requires significantly less memory than garbage collected languages for a given workload. On the other hand, C# has a number of cool features that Swift lacks, like async/await, LINQ, etc.

Rust
by Anonymous Coward

Chris, what are your general thoughts about Rust as a programming language?

CL: I'm a huge Rust fan: I think that it is a great language and its community is amazing. Rust has a clear lead over Swift in the system programming space (e.g. for writing kernels and device drivers) and I consider it one of the very few candidates that could lead to displacing C and C++ with a more safe programming language.

That said, Swift has advantages in terms of more developers using it, a more mature IDE story, and offers a much shallower learning curve for new developers. It is also very likely that a future version of Swift will introduce move-only types and a full ownership model, which will make Swift a lot more interesting in the system programming space.

BASIC
by jo7hs2

As someone who has been involved with the development of programming languages, do you think it is still possible to come up with a modern-day replacement for BASIC that can operate in modern GUI environments?

It seems like all attempts since we went GUI (aside from maybe early VisualBASIC and Hypercard) have been too complicated, and all attempts have been platform-specific or abandoned. With the emphasis on coding in schools, it seems like it would be helpful to have a good, simple, introductory language like we had in BASIC.

CL: It's probably a huge shock, but I think Swift could be this language. If you have an iPad, you should try out the free Swift Playgrounds app, which is aimed to teach people about programming, assuming no prior experience. I think it would be great for Swift to expand to provide a VisualBASIC-like scripting solution for GUI apps as well.

Cross-platform
by psergiu

How cross-platform is Swift? Are the GUI libraries platform-dependent or independent? I.E.: Can I write a single Swift program with a GUI that will compile, work the same and look similar on multiple platforms: Linux, Mac OS, Real Unix-es & BSDs, AIX, Windows?

CL: Swift is Open Source, has a vibrant community with hundreds of contributors, and builds on the proven LLVM and Clang technology stack. The Swift community has ported Swift itself to many different platforms beyond Apple platforms: it runs on various Linux distros and work is underway by various people to port it to Android, Windows, various BSDs, and even IBM mainframes.

That said, Swift does not provide a GUI layer, so you need to use native technologies to do so. Swift helps by providing great support for interoperating with existing C code (and will hopefully expand to support C++ and other languages in the future). It is possible for someone to design and build a cross platform GUI layer, but I'm not aware of any serious efforts to do so.

Exception Handling
by andywest

Why did Swift NOT have exception handling in the first couple of versions?

CL: Swift 1 (released in 2014) didn't include an error handling model simply because it wasn't ready in time: it was added in Swift 2 (2015). Swift 2 included a number of great improvements that weren't ready for Swift 1, including protocol extensions. Protocol extensions dramatically expanded the design space of what you can do with Swift, bringing a new era of "protocol oriented programming". That said, even Swift 3 (2016) is still missing a ton of great things we hope to add over the coming years: there is a long and exciting road ahead! See questions below for more details.

Why are strings passed by value?
by Anonymous Coward

Strings are immutable pass-by-reference objects in most modern languages. Why did you make this decision?

CL: Swift uses value semantics for all of its "built in" collections, including String, Array, Dictionary, etc. This provides a number of great advantages by improving efficiency (permitting in-place updating instead of requiring reallocation), eliminating large classes of bugs related to unanticipated sharing (someone mutates your collection when you are using it), and defines away a class of concurrency issues. Strings are perhaps the simplest of any of these cases, but they get the efficiency and other benefits.

If you're interested in more detail, there is a wealth of good information about the benefits of value vs reference types online. One great place to start is the "Building Better Apps with Value Types in Swift" talk from WWDC 2015.

As a language designer
by superwiz

Since you have been involved with 2 lauded languages, you are in a good position to answer the following question: "are modern languages forced to rely on language run-time to compensate for the facilities lacking in modern operating systems?" In other words, have the languages tried to compensate for the fact that there are no new OS-level light-weight paradigms to take advantage of multi-core processors?

CL: I'm not sure exactly what you mean here, but yes: if an OS provides functionality, there is no reason for a language runtime to replicate it, so runtimes really only exist to supplement what the OS provides. That said, the line between the OS and libraries is a very blurry one: Grand Central Dispatch (GCD) is a great example, because it is a combination of user space code, kernel primitives, and more all designed together.

Parallelism
by bill_mcgonigle

Say, about fifteen years ago, there was huge buzz about how languages and compilers were going to take care of the "Moore's Law Problem" by automating the parallelism of every task that could be broken up. With single-static assignment trees and the like the programmer was going to be freed from manually doing the parallelism.

With manufacturers starting to turn out 32- and 64-core chips, I'm wondering how well did we did on that front. I don't see a ton of software automatically not pegging a core on my CPU's. The ones that aren't quite as bad are mostly just doing a fork() in 2017. Did we get anywhere? Are we almost there? Is software just not compiled right now? Did it turn out to be harder than expected? Were languages not up to the task? Is hardware (e.g. memory access architectures) insufficient? Was the possibility oversold in the first place?

CL: I can't provide a global answer, but clearly parallelism is being well utilized in some "easy" cases (e.g. speeding up build time of large software, speed of 3d rendering, etc). Also, while large machines are available, most computers are only running machines with 1-4 cores (e.g. mobile phones and laptops), which means that most software doesn't have to cope with the prospects of 32-core machines⦠yet.

Looking forward, I am skeptical of the promises of overly magic solutions like compiler auto-parallelization of single threaded code. These "heroic" approaches can work on specific benchmarks and other narrow situations, but don't lead to a predictable and reliable programmer model. For example, a good result would be for you to use one of these systems and get a 32x speedup on your codebase. A really bad result would be to then make a minor change or bug fix to your code, and find out that it caused a 32x slowdown by defeating the prior compiler optimization. Magic solutions are problematic because they don't provide programmer control.

As such, my preferred approach is for the programming language to provide expressive ways for the programmer to describe their parallelism, and then allow the compiler and runtime to efficiently optimize it. Things like actor models, OpenMP, C++ AMP, and goroutines seem like the best approach. I expect concurrency to be an active area of development in the Swift language, and hope that the first pieces of the story will land in Swift 5 (2018).

Any insight into language design choices?
by EMB Numbers

I am a 25+ year Objective-C programmer and among other topics, I teach "Mobile App Development" and "Comparative Languages" at a university. I confess to being perplexed by some Swift language design decisions. For example,

• Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
• Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"

CL: These two questions get to the root of Swift "current and future". In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead. Recall that Swift is only a bit over two years old at this point: Swift 1.0 was released in September 2014.

If you compare Swift to other popular contemporary programming languages (e.g. Python, Java/C#, C/C++, Javascript, Objective-C, etc) a major difference is that Swift was designed for generality: these languages were initially designed for a specific niche and use case and then organically growing out.

In contrast, Swift was designed from the start to eventually span the gamut from scripting language to systems programming, and its underlying design choices anticipate the day when all the pieces come together. This is no small feat, because it requires pulling together the strengths of each of these languages into a single coherent whole, while balancing out the tradeoffs forced by each of them.

For example, if you compare Swift 3 to scripting languages like Python, Perl, and Ruby, I think that Swift is already as expressive, teachable, and easy to learn as a scripting language, and it includes a REPL and support for #! scripts. That said, there are obvious missing holes, like no regular expression literals, no multi-line string literals, and poor support for functionality like command line argument processing - Swift needs to be more "batteries included".

If you compare Swift 3 to systems programming languages with C/C++ or Rust, then I think there is a lot to like: Swift provides full low-level memory control through its "unsafe" APIs (e.g. you can directly call malloc and free with no overhead from Swift, if that is what you want to do). Swift also has a much lighter weight runtime than many other high level languages (e.g. no tracing Garbage Collector or threading runtime is required). That said, it has a number of holes in the story: no support for memory mapped I/O, no support for inline assembly, etc. More significantly, getting low-level control of memory requires dropping down to the Unsafe APIs, which provide a very C/C++ level of control, but also provides the C/C++ level lack of memory safety. I'm optimistic that the ongoing work to bring an ownership model to Swift will provide the kinds of safety and performance that Rust offers in this space.

If you compare Swift 3 to general application level languages like Java, I think it is already pretty great (and has been proven by its rapid adoption in the iOS ecosystem). The server space has very similar needs to general app development, but both would really benefit from a concurrency model (which I expect to be an important focus of Swift 5).

Beyond these areas of investment there is no shortage of ideas for other things to add over time. For example, the dynamic reflection capabilities you mention need to be baked out, and many people are interested in things like pre/post-conditions, language support for typestate, further improvements to the generics system, improved submodules/namespacing, a hygienic macro system, tail calls, and so much more.

There is a long and exciting road ahead for Swift development, and one of the most important features was a key part of Swift 3: unlike in the past, we expect Swift to be extremely source compatible going forward. These new capabilities should be addable to the language and runtime without breaking code. If you are interested in following along or getting involved with Swift development, I highly encourage you to check out the swift-evolution mailing list and project on GitHub.

Any hope for more productive programming?
by Kohath

I work in the semiconductor industry and our ASIC designs have seen a few large jumps in productivity:

• Transistors and custom layouts transitioned to standard cell flows and automated P&R.
• Design using logic blocks transitioned to synthesized design using RTL with HDLs.
• Most recently, we are synthesizing circuits directly from C language.

In the same timeframe, programming has remained more or less the same as it always was. New languages offer only incremental productivity improvements, and most of the big problems from 10 or 20 years ago remain big problems.

Do you know of any initiatives that could produce a step-function increase (say 5-10x) in coding productivity for average engineers?

CL: There have been a number of attempts to make a "big leap" in programmer productivity over the years, including visual programming languages, fourth-generation" programming languages, and others. That said, in terms of broad impact on the industry, none of these have been as successful as the widespread rise of "package" ecosystems (like Perl's CPAN, Ruby Gems, NPM in Javascript, and many others), which allow rapid reuse of other people's code. When I compare the productivity of a modern software developer using these systems, I think it is easy to see a 10x improvement in coding productivity, compared to a C or C++ programmer 10 years ago.

Swift embraces this direction with its builtin package manager "SwiftPM". Just as the Swift language learns from other languages, SwiftPM is designed with an awareness of other package ecosystems and attempts to assemble their best ideas into a single coherent vision. SwiftPM also provides a portable build system, allowing development and deployment of cross-platform Swift packages. SwiftPM is still comparatively early on in design, but has some heavy hitters behind it, particularly those involved in the various Swift for the Server initiatives. You might also be interested in the online package catalog hosted by IBM.

Looking ahead, even though a bit cliche, I'd have to say that machine learning techniques (convolutional neural nets and deep neural nets for example) really are changing the world by making formerly impossible things merely "hard". While it currently seems that you need a team of Ph.D's to apply and develop these techniques, when they become better understood and developed, I expect them to be more widely accessible to the rest of us. Another really interesting recent development is the idea of "word vectors," which is a pretty cool area to geek out on.

You asked, he answered! The creator of Apple's Swift programming language (and a self-described "long-time reader/fan of Slashdot") stopped by on his way to a new job at Tesla just to field questions from Slashdot readers. Read on for Chris's answers... Questions, and my best wishes.
by Volanin

Since you're the creator of LLVM, I'd like to know, in your opinion what's the greatest advantage of LLVM/Clang over the traditional and established GNU GCC compiler. Also, what's the greatest advantage of GNU GCC (or if you'd prefer, any other compiler) over LLVM/Clang, something that you'd like to "port" someday?

CL: GCC and LLVM/Clang have had a mutually beneficial relationship for years. Clang's early lead in terms of compiler error message expressivity has led the GCC developers to improve their error messages, and obviously GCC provides a very high bar to meet when LLVM and Clang were being brought up. It is important to keep in mind that GCC doesn't have to lose for Clang to win (or visa versa). Also, I haven't used GCC for many years, that said, since you asked I'll try to answer to the best of my knowledge:

From my understanding, for a C or C++ programmer on Linux, the code generated by GCC and Clang is comparable (each win some cases and lose other cases). Both compilers have a similar feature set (e.g. OpenMP is supported by both). Clang compiles code significantly faster than GCC in many cases, still generates slightly better errors and warning messages than GCC, and is usually a bit ahead in terms of support for the C++ standard. That said, the most significant benefit is improved compile time.

Going one level deeper, the most significant benefit I see of the LLVM optimizer and code generator over GCC is its architecture and design. LLVM is built with a modular library-based design, which has allowed it to be used in a variety of ways that we didn't anticipate. For example, it has been used by movie studios to JIT compile and optimize shaders used in special effects, has been used to optimize database queries, and LLVM is used as the code generator for a much wider range of source languages than GCC.

Similarly, the most significant benefit of Clang is that it is also modular. It specifically tackles problems related to IDE integration (including code completion, syntax highlighting, etc) and has a mature and vibrant tooling ecosystem build around it. Clang's design (e.g. lack of pervasive global variables) also allows it to be used at runtime, for example in OpenCL and CUDA implementations.

The greatest advantage I can see of GCC over LLVM/Clang is that it is the default compiler on almost all Linux distributions, and of course Linux is an incredibly important for developers. I'd love to see more Linux distributions start shipping Clang by default. Finally, GCC provides an Ada frontend, and I'm not aware of a supported solution for Ada + LLVM.

Future of LLVM?
by mveloso

Where do you see LLVM going?

CL: There are lots of things going on, driven by the amazing community of developers (which is growing like crazy) driving forward the llvm.org projects. LLVM is now used pervasively across the industry, by companies like Apple, Intel, AMD, Nvidia, Qualcomm, Google, Sony, Facebook, ARM, Microsoft, FreeBSD, and more. I'd love for it to be used more widely on Windows and Linux.

At the same time, I expect to see LLVM to continue to improve in a ton of different ways. For example, ThinLTO is an extremely promising approach that promises to bring scalable link time optimization to everyone, potentially replacing the default for -O3 builds. Similarly, there is work going on to speed up compile times, add support for the Microsoft PDB debug information format, and too many other things to mention here. It is an incredibly exciting time. If you're interested in a taste of what is happening, take a look at the proceedings from the recent 2016 LLVM Developer Meeting.

Finally, the LLVM Project continues to expand. Relatively recent additions include llgo (a Go frontend) and lld (a faster linker than "Gold"), and there are rumors that a Fortran frontend may soon join the fold.

The Mythical Compiler -VLIW
by Anonymous Coward

Is there any hope for VLIW architectures? The general consensus seems to be that Itanium tanked because the compiler technology wasn't able to make the leap needed. Linus complained about the Itanium ISA exposing the pipelines to assembly developers. What are the challenges from a compiler writers perspective with VLIW?

CL: I can't speak to why Itanium failed (I suspect that many non-technical issues like business decisions and schedule impacted it), but VLIW is hardly dead. VLIW designs are actively used in some modern GPUs and is widely used in DSPs - one example supported by LLVM is the Qualcomm Hexagon chip. The major challenge when compiling for a VLIW architecture is that the compiler needs good profile information, so it has an accurate idea of the dynamic behavior of the program.

How much of Swift is Based on Groovy?
by Anonymous Coward

So how much of Swift was inspired by Groovy? Both come from more high-end languages and look and act almost identical.

CL: It is an intentional design point of Swift that it look and feel "familiar" to folks coming from many other languages: not just Groovy. Feeling familiar and eliminating unnecessary differences from other programming languages is a way of reducing barriers of entry to start programming in Swift. It is also clearly true that many other languages syntactically influence each other, so you see convergence of ideas coming from many different places.

That said, I think it is a stretch to say that Swift and Groovy look and act "identical", except in some very narrow cases. The goal of Swift is simply to be as great as possible, it is not trying to imitate some other programming language.

C#
by Anonymous Coward

What do you think about Microsoft and C# versus the merits of Swift?

CL: I have a ton of respect for C#, Rust, and many other languages, and Swift certainly benefited by being able to observe their evolution over time. As such, there are a lot of similarities between these languages, and it isn't an accident.

Comparing languages is difficult in this format, because a lot of the answers come down to "it depends on what you're trying to do", but I'll give it a shot. C# has the obvious benefit of working with the .NET ecosystem, whereas Swift is stronger at working in existing C and Objective-C ecosystems like Cocoa and POSIX.

From a language level, Swift has a more general type system than C# does, offers more advanced value types, protocol extensions, etc. Swift also has advantages in mobile use cases because ARC requires significantly less memory than garbage collected languages for a given workload. On the other hand, C# has a number of cool features that Swift lacks, like async/await, LINQ, etc.

Rust
by Anonymous Coward

Chris, what are your general thoughts about Rust as a programming language?

CL: I'm a huge Rust fan: I think that it is a great language and its community is amazing. Rust has a clear lead over Swift in the system programming space (e.g. for writing kernels and device drivers) and I consider it one of the very few candidates that could lead to displacing C and C++ with a more safe programming language.

That said, Swift has advantages in terms of more developers using it, a more mature IDE story, and offers a much shallower learning curve for new developers. It is also very likely that a future version of Swift will introduce move-only types and a full ownership model, which will make Swift a lot more interesting in the system programming space.

BASIC
by jo7hs2

As someone who has been involved with the development of programming languages, do you think it is still possible to come up with a modern-day replacement for BASIC that can operate in modern GUI environments?

It seems like all attempts since we went GUI (aside from maybe early VisualBASIC and Hypercard) have been too complicated, and all attempts have been platform-specific or abandoned. With the emphasis on coding in schools, it seems like it would be helpful to have a good, simple, introductory language like we had in BASIC.

CL: It's probably a huge shock, but I think Swift could be this language. If you have an iPad, you should try out the free Swift Playgrounds app, which is aimed to teach people about programming, assuming no prior experience. I think it would be great for Swift to expand to provide a VisualBASIC-like scripting solution for GUI apps as well.

Cross-platform
by psergiu

How cross-platform is Swift? Are the GUI libraries platform-dependent or independent? I.E.: Can I write a single Swift program with a GUI that will compile, work the same and look similar on multiple platforms: Linux, Mac OS, Real Unix-es & BSDs, AIX, Windows?

CL: Swift is Open Source, has a vibrant community with hundreds of contributors, and builds on the proven LLVM and Clang technology stack. The Swift community has ported Swift itself to many different platforms beyond Apple platforms: it runs on various Linux distros and work is underway by various people to port it to Android, Windows, various BSDs, and even IBM mainframes.

That said, Swift does not provide a GUI layer, so you need to use native technologies to do so. Swift helps by providing great support for interoperating with existing C code (and will hopefully expand to support C++ and other languages in the future). It is possible for someone to design and build a cross platform GUI layer, but I'm not aware of any serious efforts to do so.

Exception Handling
by andywest

Why did Swift NOT have exception handling in the first couple of versions?

CL: Swift 1 (released in 2014) didn't include an error handling model simply because it wasn't ready in time: it was added in Swift 2 (2015). Swift 2 included a number of great improvements that weren't ready for Swift 1, including protocol extensions. Protocol extensions dramatically expanded the design space of what you can do with Swift, bringing a new era of "protocol oriented programming". That said, even Swift 3 (2016) is still missing a ton of great things we hope to add over the coming years: there is a long and exciting road ahead! See questions below for more details.

Why are strings passed by value?
by Anonymous Coward

Strings are immutable pass-by-reference objects in most modern languages. Why did you make this decision?

CL: Swift uses value semantics for all of its "built in" collections, including String, Array, Dictionary, etc. This provides a number of great advantages by improving efficiency (permitting in-place updating instead of requiring reallocation), eliminating large classes of bugs related to unanticipated sharing (someone mutates your collection when you are using it), and defines away a class of concurrency issues. Strings are perhaps the simplest of any of these cases, but they get the efficiency and other benefits.

If you're interested in more detail, there is a wealth of good information about the benefits of value vs reference types online. One great place to start is the "Building Better Apps with Value Types in Swift" talk from WWDC 2015.

As a language designer
by superwiz

Since you have been involved with 2 lauded languages, you are in a good position to answer the following question: "are modern languages forced to rely on language run-time to compensate for the facilities lacking in modern operating systems?" In other words, have the languages tried to compensate for the fact that there are no new OS-level light-weight paradigms to take advantage of multi-core processors?

CL: I'm not sure exactly what you mean here, but yes: if an OS provides functionality, there is no reason for a language runtime to replicate it, so runtimes really only exist to supplement what the OS provides. That said, the line between the OS and libraries is a very blurry one: Grand Central Dispatch (GCD) is a great example, because it is a combination of user space code, kernel primitives, and more all designed together.

Parallelism
by bill_mcgonigle

Say, about fifteen years ago, there was huge buzz about how languages and compilers were going to take care of the "Moore's Law Problem" by automating the parallelism of every task that could be broken up. With single-static assignment trees and the like the programmer was going to be freed from manually doing the parallelism.

With manufacturers starting to turn out 32- and 64-core chips, I'm wondering how well did we did on that front. I don't see a ton of software automatically not pegging a core on my CPU's. The ones that aren't quite as bad are mostly just doing a fork() in 2017. Did we get anywhere? Are we almost there? Is software just not compiled right now? Did it turn out to be harder than expected? Were languages not up to the task? Is hardware (e.g. memory access architectures) insufficient? Was the possibility oversold in the first place?

CL: I can't provide a global answer, but clearly parallelism is being well utilized in some "easy" cases (e.g. speeding up build time of large software, speed of 3d rendering, etc). Also, while large machines are available, most computers are only running machines with 1-4 cores (e.g. mobile phones and laptops), which means that most software doesn't have to cope with the prospects of 32-core machines⦠yet.

Looking forward, I am skeptical of the promises of overly magic solutions like compiler auto-parallelization of single threaded code. These "heroic" approaches can work on specific benchmarks and other narrow situations, but don't lead to a predictable and reliable programmer model. For example, a good result would be for you to use one of these systems and get a 32x speedup on your codebase. A really bad result would be to then make a minor change or bug fix to your code, and find out that it caused a 32x slowdown by defeating the prior compiler optimization. Magic solutions are problematic because they don't provide programmer control.

As such, my preferred approach is for the programming language to provide expressive ways for the programmer to describe their parallelism, and then allow the compiler and runtime to efficiently optimize it. Things like actor models, OpenMP, C++ AMP, and goroutines seem like the best approach. I expect concurrency to be an active area of development in the Swift language, and hope that the first pieces of the story will land in Swift 5 (2018).

Any insight into language design choices?
by EMB Numbers

I am a 25+ year Objective-C programmer and among other topics, I teach "Mobile App Development" and "Comparative Languages" at a university. I confess to being perplexed by some Swift language design decisions. For example,

• Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
• Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"

CL: These two questions get to the root of Swift "current and future". In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead. Recall that Swift is only a bit over two years old at this point: Swift 1.0 was released in September 2014.

If you compare Swift to other popular contemporary programming languages (e.g. Python, Java/C#, C/C++, Javascript, Objective-C, etc) a major difference is that Swift was designed for generality: these languages were initially designed for a specific niche and use case and then organically growing out.

In contrast, Swift was designed from the start to eventually span the gamut from scripting language to systems programming, and its underlying design choices anticipate the day when all the pieces come together. This is no small feat, because it requires pulling together the strengths of each of these languages into a single coherent whole, while balancing out the tradeoffs forced by each of them.

For example, if you compare Swift 3 to scripting languages like Python, Perl, and Ruby, I think that Swift is already as expressive, teachable, and easy to learn as a scripting language, and it includes a REPL and support for #! scripts. That said, there are obvious missing holes, like no regular expression literals, no multi-line string literals, and poor support for functionality like command line argument processing - Swift needs to be more "batteries included".

If you compare Swift 3 to systems programming languages with C/C++ or Rust, then I think there is a lot to like: Swift provides full low-level memory control through its "unsafe" APIs (e.g. you can directly call malloc and free with no overhead from Swift, if that is what you want to do). Swift also has a much lighter weight runtime than many other high level languages (e.g. no tracing Garbage Collector or threading runtime is required). That said, it has a number of holes in the story: no support for memory mapped I/O, no support for inline assembly, etc. More significantly, getting low-level control of memory requires dropping down to the Unsafe APIs, which provide a very C/C++ level of control, but also provides the C/C++ level lack of memory safety. I'm optimistic that the ongoing work to bring an ownership model to Swift will provide the kinds of safety and performance that Rust offers in this space.

If you compare Swift 3 to general application level languages like Java, I think it is already pretty great (and has been proven by its rapid adoption in the iOS ecosystem). The server space has very similar needs to general app development, but both would really benefit from a concurrency model (which I expect to be an important focus of Swift 5).

Beyond these areas of investment there is no shortage of ideas for other things to add over time. For example, the dynamic reflection capabilities you mention need to be baked out, and many people are interested in things like pre/post-conditions, language support for typestate, further improvements to the generics system, improved submodules/namespacing, a hygienic macro system, tail calls, and so much more.

There is a long and exciting road ahead for Swift development, and one of the most important features was a key part of Swift 3: unlike in the past, we expect Swift to be extremely source compatible going forward. These new capabilities should be addable to the language and runtime without breaking code. If you are interested in following along or getting involved with Swift development, I highly encourage you to check out the swift-evolution mailing list and project on GitHub.

Any hope for more productive programming?
by Kohath

I work in the semiconductor industry and our ASIC designs have seen a few large jumps in productivity:

• Transistors and custom layouts transitioned to standard cell flows and automated P&R.
• Design using logic blocks transitioned to synthesized design using RTL with HDLs.
• Most recently, we are synthesizing circuits directly from C language.

In the same timeframe, programming has remained more or less the same as it always was. New languages offer only incremental productivity improvements, and most of the big problems from 10 or 20 years ago remain big problems.

Do you know of any initiatives that could produce a step-function increase (say 5-10x) in coding productivity for average engineers?

CL: There have been a number of attempts to make a "big leap" in programmer productivity over the years, including visual programming languages, fourth-generation" programming languages, and others. That said, in terms of broad impact on the industry, none of these have been as successful as the widespread rise of "package" ecosystems (like Perl's CPAN, Ruby Gems, NPM in Javascript, and many others), which allow rapid reuse of other people's code. When I compare the productivity of a modern software developer using these systems, I think it is easy to see a 10x improvement in coding productivity, compared to a C or C++ programmer 10 years ago.

Swift embraces this direction with its builtin package manager "SwiftPM". Just as the Swift language learns from other languages, SwiftPM is designed with an awareness of other package ecosystems and attempts to assemble their best ideas into a single coherent vision. SwiftPM also provides a portable build system, allowing development and deployment of cross-platform Swift packages. SwiftPM is still comparatively early on in design, but has some heavy hitters behind it, particularly those involved in the various Swift for the Server initiatives. You might also be interested in the online package catalog hosted by IBM.

Looking ahead, even though a bit cliche, I'd have to say that machine learning techniques (convolutional neural nets and deep neural nets for example) really are changing the world by making formerly impossible things merely "hard". While it currently seems that you need a team of Ph.D's to apply and develop these techniques, when they become better understood and developed, I expect them to be more widely accessible to the rest of us. Another really interesting recent development is the idea of "word vectors," which is a pretty cool area to geek out on.

You asked, he answered! The creator of Apple's Swift programming language (and a self-described "long-time reader/fan of Slashdot") stopped by on his way to a new job at Tesla just to field questions from Slashdot readers. Read on for Chris's answers... Questions, and my best wishes.
by Volanin

Since you're the creator of LLVM, I'd like to know, in your opinion what's the greatest advantage of LLVM/Clang over the traditional and established GNU GCC compiler. Also, what's the greatest advantage of GNU GCC (or if you'd prefer, any other compiler) over LLVM/Clang, something that you'd like to "port" someday?

CL: GCC and LLVM/Clang have had a mutually beneficial relationship for years. Clang's early lead in terms of compiler error message expressivity has led the GCC developers to improve their error messages, and obviously GCC provides a very high bar to meet when LLVM and Clang were being brought up. It is important to keep in mind that GCC doesn't have to lose for Clang to win (or visa versa). Also, I haven't used GCC for many years, that said, since you asked I'll try to answer to the best of my knowledge:

From my understanding, for a C or C++ programmer on Linux, the code generated by GCC and Clang is comparable (each win some cases and lose other cases). Both compilers have a similar feature set (e.g. OpenMP is supported by both). Clang compiles code significantly faster than GCC in many cases, still generates slightly better errors and warning messages than GCC, and is usually a bit ahead in terms of support for the C++ standard. That said, the most significant benefit is improved compile time.

Going one level deeper, the most significant benefit I see of the LLVM optimizer and code generator over GCC is its architecture and design. LLVM is built with a modular library-based design, which has allowed it to be used in a variety of ways that we didn't anticipate. For example, it has been used by movie studios to JIT compile and optimize shaders used in special effects, has been used to optimize database queries, and LLVM is used as the code generator for a much wider range of source languages than GCC.

Similarly, the most significant benefit of Clang is that it is also modular. It specifically tackles problems related to IDE integration (including code completion, syntax highlighting, etc) and has a mature and vibrant tooling ecosystem build around it. Clang's design (e.g. lack of pervasive global variables) also allows it to be used at runtime, for example in OpenCL and CUDA implementations.

The greatest advantage I can see of GCC over LLVM/Clang is that it is the default compiler on almost all Linux distributions, and of course Linux is an incredibly important for developers. I'd love to see more Linux distributions start shipping Clang by default. Finally, GCC provides an Ada frontend, and I'm not aware of a supported solution for Ada + LLVM.

Future of LLVM?
by mveloso

Where do you see LLVM going?

CL: There are lots of things going on, driven by the amazing community of developers (which is growing like crazy) driving forward the llvm.org projects. LLVM is now used pervasively across the industry, by companies like Apple, Intel, AMD, Nvidia, Qualcomm, Google, Sony, Facebook, ARM, Microsoft, FreeBSD, and more. I'd love for it to be used more widely on Windows and Linux.

At the same time, I expect to see LLVM to continue to improve in a ton of different ways. For example, ThinLTO is an extremely promising approach that promises to bring scalable link time optimization to everyone, potentially replacing the default for -O3 builds. Similarly, there is work going on to speed up compile times, add support for the Microsoft PDB debug information format, and too many other things to mention here. It is an incredibly exciting time. If you're interested in a taste of what is happening, take a look at the proceedings from the recent 2016 LLVM Developer Meeting.

Finally, the LLVM Project continues to expand. Relatively recent additions include llgo (a Go frontend) and lld (a faster linker than "Gold"), and there are rumors that a Fortran frontend may soon join the fold.

The Mythical Compiler -VLIW
by Anonymous Coward

Is there any hope for VLIW architectures? The general consensus seems to be that Itanium tanked because the compiler technology wasn't able to make the leap needed. Linus complained about the Itanium ISA exposing the pipelines to assembly developers. What are the challenges from a compiler writers perspective with VLIW?

CL: I can't speak to why Itanium failed (I suspect that many non-technical issues like business decisions and schedule impacted it), but VLIW is hardly dead. VLIW designs are actively used in some modern GPUs and is widely used in DSPs - one example supported by LLVM is the Qualcomm Hexagon chip. The major challenge when compiling for a VLIW architecture is that the compiler needs good profile information, so it has an accurate idea of the dynamic behavior of the program.

How much of Swift is Based on Groovy?
by Anonymous Coward

So how much of Swift was inspired by Groovy? Both come from more high-end languages and look and act almost identical.

CL: It is an intentional design point of Swift that it look and feel "familiar" to folks coming from many other languages: not just Groovy. Feeling familiar and eliminating unnecessary differences from other programming languages is a way of reducing barriers of entry to start programming in Swift. It is also clearly true that many other languages syntactically influence each other, so you see convergence of ideas coming from many different places.

That said, I think it is a stretch to say that Swift and Groovy look and act "identical", except in some very narrow cases. The goal of Swift is simply to be as great as possible, it is not trying to imitate some other programming language.

C#
by Anonymous Coward

What do you think about Microsoft and C# versus the merits of Swift?

CL: I have a ton of respect for C#, Rust, and many other languages, and Swift certainly benefited by being able to observe their evolution over time. As such, there are a lot of similarities between these languages, and it isn't an accident.

Comparing languages is difficult in this format, because a lot of the answers come down to "it depends on what you're trying to do", but I'll give it a shot. C# has the obvious benefit of working with the .NET ecosystem, whereas Swift is stronger at working in existing C and Objective-C ecosystems like Cocoa and POSIX.

From a language level, Swift has a more general type system than C# does, offers more advanced value types, protocol extensions, etc. Swift also has advantages in mobile use cases because ARC requires significantly less memory than garbage collected languages for a given workload. On the other hand, C# has a number of cool features that Swift lacks, like async/await, LINQ, etc.

Rust
by Anonymous Coward

Chris, what are your general thoughts about Rust as a programming language?

CL: I'm a huge Rust fan: I think that it is a great language and its community is amazing. Rust has a clear lead over Swift in the system programming space (e.g. for writing kernels and device drivers) and I consider it one of the very few candidates that could lead to displacing C and C++ with a more safe programming language.

That said, Swift has advantages in terms of more developers using it, a more mature IDE story, and offers a much shallower learning curve for new developers. It is also very likely that a future version of Swift will introduce move-only types and a full ownership model, which will make Swift a lot more interesting in the system programming space.

BASIC
by jo7hs2

As someone who has been involved with the development of programming languages, do you think it is still possible to come up with a modern-day replacement for BASIC that can operate in modern GUI environments?

It seems like all attempts since we went GUI (aside from maybe early VisualBASIC and Hypercard) have been too complicated, and all attempts have been platform-specific or abandoned. With the emphasis on coding in schools, it seems like it would be helpful to have a good, simple, introductory language like we had in BASIC.

CL: It's probably a huge shock, but I think Swift could be this language. If you have an iPad, you should try out the free Swift Playgrounds app, which is aimed to teach people about programming, assuming no prior experience. I think it would be great for Swift to expand to provide a VisualBASIC-like scripting solution for GUI apps as well.

Cross-platform
by psergiu

How cross-platform is Swift? Are the GUI libraries platform-dependent or independent? I.E.: Can I write a single Swift program with a GUI that will compile, work the same and look similar on multiple platforms: Linux, Mac OS, Real Unix-es & BSDs, AIX, Windows?

CL: Swift is Open Source, has a vibrant community with hundreds of contributors, and builds on the proven LLVM and Clang technology stack. The Swift community has ported Swift itself to many different platforms beyond Apple platforms: it runs on various Linux distros and work is underway by various people to port it to Android, Windows, various BSDs, and even IBM mainframes.

That said, Swift does not provide a GUI layer, so you need to use native technologies to do so. Swift helps by providing great support for interoperating with existing C code (and will hopefully expand to support C++ and other languages in the future). It is possible for someone to design and build a cross platform GUI layer, but I'm not aware of any serious efforts to do so.

Exception Handling
by andywest

Why did Swift NOT have exception handling in the first couple of versions?

CL: Swift 1 (released in 2014) didn't include an error handling model simply because it wasn't ready in time: it was added in Swift 2 (2015). Swift 2 included a number of great improvements that weren't ready for Swift 1, including protocol extensions. Protocol extensions dramatically expanded the design space of what you can do with Swift, bringing a new era of "protocol oriented programming". That said, even Swift 3 (2016) is still missing a ton of great things we hope to add over the coming years: there is a long and exciting road ahead! See questions below for more details.

Why are strings passed by value?
by Anonymous Coward

Strings are immutable pass-by-reference objects in most modern languages. Why did you make this decision?

CL: Swift uses value semantics for all of its "built in" collections, including String, Array, Dictionary, etc. This provides a number of great advantages by improving efficiency (permitting in-place updating instead of requiring reallocation), eliminating large classes of bugs related to unanticipated sharing (someone mutates your collection when you are using it), and defines away a class of concurrency issues. Strings are perhaps the simplest of any of these cases, but they get the efficiency and other benefits.

If you're interested in more detail, there is a wealth of good information about the benefits of value vs reference types online. One great place to start is the "Building Better Apps with Value Types in Swift" talk from WWDC 2015.

As a language designer
by superwiz

Since you have been involved with 2 lauded languages, you are in a good position to answer the following question: "are modern languages forced to rely on language run-time to compensate for the facilities lacking in modern operating systems?" In other words, have the languages tried to compensate for the fact that there are no new OS-level light-weight paradigms to take advantage of multi-core processors?

CL: I'm not sure exactly what you mean here, but yes: if an OS provides functionality, there is no reason for a language runtime to replicate it, so runtimes really only exist to supplement what the OS provides. That said, the line between the OS and libraries is a very blurry one: Grand Central Dispatch (GCD) is a great example, because it is a combination of user space code, kernel primitives, and more all designed together.

Parallelism
by bill_mcgonigle

Say, about fifteen years ago, there was huge buzz about how languages and compilers were going to take care of the "Moore's Law Problem" by automating the parallelism of every task that could be broken up. With single-static assignment trees and the like the programmer was going to be freed from manually doing the parallelism.

With manufacturers starting to turn out 32- and 64-core chips, I'm wondering how well did we did on that front. I don't see a ton of software automatically not pegging a core on my CPU's. The ones that aren't quite as bad are mostly just doing a fork() in 2017. Did we get anywhere? Are we almost there? Is software just not compiled right now? Did it turn out to be harder than expected? Were languages not up to the task? Is hardware (e.g. memory access architectures) insufficient? Was the possibility oversold in the first place?

CL: I can't provide a global answer, but clearly parallelism is being well utilized in some "easy" cases (e.g. speeding up build time of large software, speed of 3d rendering, etc). Also, while large machines are available, most computers are only running machines with 1-4 cores (e.g. mobile phones and laptops), which means that most software doesn't have to cope with the prospects of 32-core machines⦠yet.

Looking forward, I am skeptical of the promises of overly magic solutions like compiler auto-parallelization of single threaded code. These "heroic" approaches can work on specific benchmarks and other narrow situations, but don't lead to a predictable and reliable programmer model. For example, a good result would be for you to use one of these systems and get a 32x speedup on your codebase. A really bad result would be to then make a minor change or bug fix to your code, and find out that it caused a 32x slowdown by defeating the prior compiler optimization. Magic solutions are problematic because they don't provide programmer control.

As such, my preferred approach is for the programming language to provide expressive ways for the programmer to describe their parallelism, and then allow the compiler and runtime to efficiently optimize it. Things like actor models, OpenMP, C++ AMP, and goroutines seem like the best approach. I expect concurrency to be an active area of development in the Swift language, and hope that the first pieces of the story will land in Swift 5 (2018).

Any insight into language design choices?
by EMB Numbers

I am a 25+ year Objective-C programmer and among other topics, I teach "Mobile App Development" and "Comparative Languages" at a university. I confess to being perplexed by some Swift language design decisions. For example,

• Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
• Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"

CL: These two questions get to the root of Swift "current and future". In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead. Recall that Swift is only a bit over two years old at this point: Swift 1.0 was released in September 2014.

If you compare Swift to other popular contemporary programming languages (e.g. Python, Java/C#, C/C++, Javascript, Objective-C, etc) a major difference is that Swift was designed for generality: these languages were initially designed for a specific niche and use case and then organically growing out.

In contrast, Swift was designed from the start to eventually span the gamut from scripting language to systems programming, and its underlying design choices anticipate the day when all the pieces come together. This is no small feat, because it requires pulling together the strengths of each of these languages into a single coherent whole, while balancing out the tradeoffs forced by each of them.

For example, if you compare Swift 3 to scripting languages like Python, Perl, and Ruby, I think that Swift is already as expressive, teachable, and easy to learn as a scripting language, and it includes a REPL and support for #! scripts. That said, there are obvious missing holes, like no regular expression literals, no multi-line string literals, and poor support for functionality like command line argument processing - Swift needs to be more "batteries included".

If you compare Swift 3 to systems programming languages with C/C++ or Rust, then I think there is a lot to like: Swift provides full low-level memory control through its "unsafe" APIs (e.g. you can directly call malloc and free with no overhead from Swift, if that is what you want to do). Swift also has a much lighter weight runtime than many other high level languages (e.g. no tracing Garbage Collector or threading runtime is required). That said, it has a number of holes in the story: no support for memory mapped I/O, no support for inline assembly, etc. More significantly, getting low-level control of memory requires dropping down to the Unsafe APIs, which provide a very C/C++ level of control, but also provides the C/C++ level lack of memory safety. I'm optimistic that the ongoing work to bring an ownership model to Swift will provide the kinds of safety and performance that Rust offers in this space.

If you compare Swift 3 to general application level languages like Java, I think it is already pretty great (and has been proven by its rapid adoption in the iOS ecosystem). The server space has very similar needs to general app development, but both would really benefit from a concurrency model (which I expect to be an important focus of Swift 5).

Beyond these areas of investment there is no shortage of ideas for other things to add over time. For example, the dynamic reflection capabilities you mention need to be baked out, and many people are interested in things like pre/post-conditions, language support for typestate, further improvements to the generics system, improved submodules/namespacing, a hygienic macro system, tail calls, and so much more.

There is a long and exciting road ahead for Swift development, and one of the most important features was a key part of Swift 3: unlike in the past, we expect Swift to be extremely source compatible going forward. These new capabilities should be addable to the language and runtime without breaking code. If you are interested in following along or getting involved with Swift development, I highly encourage you to check out the swift-evolution mailing list and project on GitHub.

Any hope for more productive programming?
by Kohath

I work in the semiconductor industry and our ASIC designs have seen a few large jumps in productivity:

• Transistors and custom layouts transitioned to standard cell flows and automated P&R.
• Design using logic blocks transitioned to synthesized design using RTL with HDLs.
• Most recently, we are synthesizing circuits directly from C language.

In the same timeframe, programming has remained more or less the same as it always was. New languages offer only incremental productivity improvements, and most of the big problems from 10 or 20 years ago remain big problems.

Do you know of any initiatives that could produce a step-function increase (say 5-10x) in coding productivity for average engineers?

CL: There have been a number of attempts to make a "big leap" in programmer productivity over the years, including visual programming languages, fourth-generation" programming languages, and others. That said, in terms of broad impact on the industry, none of these have been as successful as the widespread rise of "package" ecosystems (like Perl's CPAN, Ruby Gems, NPM in Javascript, and many others), which allow rapid reuse of other people's code. When I compare the productivity of a modern software developer using these systems, I think it is easy to see a 10x improvement in coding productivity, compared to a C or C++ programmer 10 years ago.

Swift embraces this direction with its builtin package manager "SwiftPM". Just as the Swift language learns from other languages, SwiftPM is designed with an awareness of other package ecosystems and attempts to assemble their best ideas into a single coherent vision. SwiftPM also provides a portable build system, allowing development and deployment of cross-platform Swift packages. SwiftPM is still comparatively early on in design, but has some heavy hitters behind it, particularly those involved in the various Swift for the Server initiatives. You might also be interested in the online package catalog hosted by IBM.

Looking ahead, even though a bit cliche, I'd have to say that machine learning techniques (convolutional neural nets and deep neural nets for example) really are changing the world by making formerly impossible things merely "hard". While it currently seems that you need a team of Ph.D's to apply and develop these techniques, when they become better understood and developed, I expect them to be more widely accessible to the rest of us. Another really interesting recent development is the idea of "word vectors," which is a pretty cool area to geek out on.

You asked, he answered! The creator of Apple's Swift programming language (and a self-described "long-time reader/fan of Slashdot") stopped by on his way to a new job at Tesla just to field questions from Slashdot readers. Read on for Chris's answers... Questions, and my best wishes.
by Volanin

Since you're the creator of LLVM, I'd like to know, in your opinion what's the greatest advantage of LLVM/Clang over the traditional and established GNU GCC compiler. Also, what's the greatest advantage of GNU GCC (or if you'd prefer, any other compiler) over LLVM/Clang, something that you'd like to "port" someday?

CL: GCC and LLVM/Clang have had a mutually beneficial relationship for years. Clang's early lead in terms of compiler error message expressivity has led the GCC developers to improve their error messages, and obviously GCC provides a very high bar to meet when LLVM and Clang were being brought up. It is important to keep in mind that GCC doesn't have to lose for Clang to win (or visa versa). Also, I haven't used GCC for many years, that said, since you asked I'll try to answer to the best of my knowledge:

From my understanding, for a C or C++ programmer on Linux, the code generated by GCC and Clang is comparable (each win some cases and lose other cases). Both compilers have a similar feature set (e.g. OpenMP is supported by both). Clang compiles code significantly faster than GCC in many cases, still generates slightly better errors and warning messages than GCC, and is usually a bit ahead in terms of support for the C++ standard. That said, the most significant benefit is improved compile time.

Going one level deeper, the most significant benefit I see of the LLVM optimizer and code generator over GCC is its architecture and design. LLVM is built with a modular library-based design, which has allowed it to be used in a variety of ways that we didn't anticipate. For example, it has been used by movie studios to JIT compile and optimize shaders used in special effects, has been used to optimize database queries, and LLVM is used as the code generator for a much wider range of source languages than GCC.

Similarly, the most significant benefit of Clang is that it is also modular. It specifically tackles problems related to IDE integration (including code completion, syntax highlighting, etc) and has a mature and vibrant tooling ecosystem build around it. Clang's design (e.g. lack of pervasive global variables) also allows it to be used at runtime, for example in OpenCL and CUDA implementations.

The greatest advantage I can see of GCC over LLVM/Clang is that it is the default compiler on almost all Linux distributions, and of course Linux is an incredibly important for developers. I'd love to see more Linux distributions start shipping Clang by default. Finally, GCC provides an Ada frontend, and I'm not aware of a supported solution for Ada + LLVM.

Future of LLVM?
by mveloso

Where do you see LLVM going?

CL: There are lots of things going on, driven by the amazing community of developers (which is growing like crazy) driving forward the llvm.org projects. LLVM is now used pervasively across the industry, by companies like Apple, Intel, AMD, Nvidia, Qualcomm, Google, Sony, Facebook, ARM, Microsoft, FreeBSD, and more. I'd love for it to be used more widely on Windows and Linux.

At the same time, I expect to see LLVM to continue to improve in a ton of different ways. For example, ThinLTO is an extremely promising approach that promises to bring scalable link time optimization to everyone, potentially replacing the default for -O3 builds. Similarly, there is work going on to speed up compile times, add support for the Microsoft PDB debug information format, and too many other things to mention here. It is an incredibly exciting time. If you're interested in a taste of what is happening, take a look at the proceedings from the recent 2016 LLVM Developer Meeting.

Finally, the LLVM Project continues to expand. Relatively recent additions include llgo (a Go frontend) and lld (a faster linker than "Gold"), and there are rumors that a Fortran frontend may soon join the fold.

The Mythical Compiler -VLIW
by Anonymous Coward

Is there any hope for VLIW architectures? The general consensus seems to be that Itanium tanked because the compiler technology wasn't able to make the leap needed. Linus complained about the Itanium ISA exposing the pipelines to assembly developers. What are the challenges from a compiler writers perspective with VLIW?

CL: I can't speak to why Itanium failed (I suspect that many non-technical issues like business decisions and schedule impacted it), but VLIW is hardly dead. VLIW designs are actively used in some modern GPUs and is widely used in DSPs - one example supported by LLVM is the Qualcomm Hexagon chip. The major challenge when compiling for a VLIW architecture is that the compiler needs good profile information, so it has an accurate idea of the dynamic behavior of the program.

How much of Swift is Based on Groovy?
by Anonymous Coward

So how much of Swift was inspired by Groovy? Both come from more high-end languages and look and act almost identical.

CL: It is an intentional design point of Swift that it look and feel "familiar" to folks coming from many other languages: not just Groovy. Feeling familiar and eliminating unnecessary differences from other programming languages is a way of reducing barriers of entry to start programming in Swift. It is also clearly true that many other languages syntactically influence each other, so you see convergence of ideas coming from many different places.

That said, I think it is a stretch to say that Swift and Groovy look and act "identical", except in some very narrow cases. The goal of Swift is simply to be as great as possible, it is not trying to imitate some other programming language.

C#
by Anonymous Coward

What do you think about Microsoft and C# versus the merits of Swift?

CL: I have a ton of respect for C#, Rust, and many other languages, and Swift certainly benefited by being able to observe their evolution over time. As such, there are a lot of similarities between these languages, and it isn't an accident.

Comparing languages is difficult in this format, because a lot of the answers come down to "it depends on what you're trying to do", but I'll give it a shot. C# has the obvious benefit of working with the .NET ecosystem, whereas Swift is stronger at working in existing C and Objective-C ecosystems like Cocoa and POSIX.

From a language level, Swift has a more general type system than C# does, offers more advanced value types, protocol extensions, etc. Swift also has advantages in mobile use cases because ARC requires significantly less memory than garbage collected languages for a given workload. On the other hand, C# has a number of cool features that Swift lacks, like async/await, LINQ, etc.

Rust
by Anonymous Coward

Chris, what are your general thoughts about Rust as a programming language?

CL: I'm a huge Rust fan: I think that it is a great language and its community is amazing. Rust has a clear lead over Swift in the system programming space (e.g. for writing kernels and device drivers) and I consider it one of the very few candidates that could lead to displacing C and C++ with a more safe programming language.

That said, Swift has advantages in terms of more developers using it, a more mature IDE story, and offers a much shallower learning curve for new developers. It is also very likely that a future version of Swift will introduce move-only types and a full ownership model, which will make Swift a lot more interesting in the system programming space.

BASIC
by jo7hs2

As someone who has been involved with the development of programming languages, do you think it is still possible to come up with a modern-day replacement for BASIC that can operate in modern GUI environments?

It seems like all attempts since we went GUI (aside from maybe early VisualBASIC and Hypercard) have been too complicated, and all attempts have been platform-specific or abandoned. With the emphasis on coding in schools, it seems like it would be helpful to have a good, simple, introductory language like we had in BASIC.

CL: It's probably a huge shock, but I think Swift could be this language. If you have an iPad, you should try out the free Swift Playgrounds app, which is aimed to teach people about programming, assuming no prior experience. I think it would be great for Swift to expand to provide a VisualBASIC-like scripting solution for GUI apps as well.

Cross-platform
by psergiu

How cross-platform is Swift? Are the GUI libraries platform-dependent or independent? I.E.: Can I write a single Swift program with a GUI that will compile, work the same and look similar on multiple platforms: Linux, Mac OS, Real Unix-es & BSDs, AIX, Windows?

CL: Swift is Open Source, has a vibrant community with hundreds of contributors, and builds on the proven LLVM and Clang technology stack. The Swift community has ported Swift itself to many different platforms beyond Apple platforms: it runs on various Linux distros and work is underway by various people to port it to Android, Windows, various BSDs, and even IBM mainframes.

That said, Swift does not provide a GUI layer, so you need to use native technologies to do so. Swift helps by providing great support for interoperating with existing C code (and will hopefully expand to support C++ and other languages in the future). It is possible for someone to design and build a cross platform GUI layer, but I'm not aware of any serious efforts to do so.

Exception Handling
by andywest

Why did Swift NOT have exception handling in the first couple of versions?

CL: Swift 1 (released in 2014) didn't include an error handling model simply because it wasn't ready in time: it was added in Swift 2 (2015). Swift 2 included a number of great improvements that weren't ready for Swift 1, including protocol extensions. Protocol extensions dramatically expanded the design space of what you can do with Swift, bringing a new era of "protocol oriented programming". That said, even Swift 3 (2016) is still missing a ton of great things we hope to add over the coming years: there is a long and exciting road ahead! See questions below for more details.

Why are strings passed by value?
by Anonymous Coward

Strings are immutable pass-by-reference objects in most modern languages. Why did you make this decision?

CL: Swift uses value semantics for all of its "built in" collections, including String, Array, Dictionary, etc. This provides a number of great advantages by improving efficiency (permitting in-place updating instead of requiring reallocation), eliminating large classes of bugs related to unanticipated sharing (someone mutates your collection when you are using it), and defines away a class of concurrency issues. Strings are perhaps the simplest of any of these cases, but they get the efficiency and other benefits.

If you're interested in more detail, there is a wealth of good information about the benefits of value vs reference types online. One great place to start is the "Building Better Apps with Value Types in Swift" talk from WWDC 2015.

As a language designer
by superwiz

Since you have been involved with 2 lauded languages, you are in a good position to answer the following question: "are modern languages forced to rely on language run-time to compensate for the facilities lacking in modern operating systems?" In other words, have the languages tried to compensate for the fact that there are no new OS-level light-weight paradigms to take advantage of multi-core processors?

CL: I'm not sure exactly what you mean here, but yes: if an OS provides functionality, there is no reason for a language runtime to replicate it, so runtimes really only exist to supplement what the OS provides. That said, the line between the OS and libraries is a very blurry one: Grand Central Dispatch (GCD) is a great example, because it is a combination of user space code, kernel primitives, and more all designed together.

Parallelism
by bill_mcgonigle

Say, about fifteen years ago, there was huge buzz about how languages and compilers were going to take care of the "Moore's Law Problem" by automating the parallelism of every task that could be broken up. With single-static assignment trees and the like the programmer was going to be freed from manually doing the parallelism.

With manufacturers starting to turn out 32- and 64-core chips, I'm wondering how well did we did on that front. I don't see a ton of software automatically not pegging a core on my CPU's. The ones that aren't quite as bad are mostly just doing a fork() in 2017. Did we get anywhere? Are we almost there? Is software just not compiled right now? Did it turn out to be harder than expected? Were languages not up to the task? Is hardware (e.g. memory access architectures) insufficient? Was the possibility oversold in the first place?

CL: I can't provide a global answer, but clearly parallelism is being well utilized in some "easy" cases (e.g. speeding up build time of large software, speed of 3d rendering, etc). Also, while large machines are available, most computers are only running machines with 1-4 cores (e.g. mobile phones and laptops), which means that most software doesn't have to cope with the prospects of 32-core machines⦠yet.

Looking forward, I am skeptical of the promises of overly magic solutions like compiler auto-parallelization of single threaded code. These "heroic" approaches can work on specific benchmarks and other narrow situations, but don't lead to a predictable and reliable programmer model. For example, a good result would be for you to use one of these systems and get a 32x speedup on your codebase. A really bad result would be to then make a minor change or bug fix to your code, and find out that it caused a 32x slowdown by defeating the prior compiler optimization. Magic solutions are problematic because they don't provide programmer control.

As such, my preferred approach is for the programming language to provide expressive ways for the programmer to describe their parallelism, and then allow the compiler and runtime to efficiently optimize it. Things like actor models, OpenMP, C++ AMP, and goroutines seem like the best approach. I expect concurrency to be an active area of development in the Swift language, and hope that the first pieces of the story will land in Swift 5 (2018).

Any insight into language design choices?
by EMB Numbers

I am a 25+ year Objective-C programmer and among other topics, I teach "Mobile App Development" and "Comparative Languages" at a university. I confess to being perplexed by some Swift language design decisions. For example,

• Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
• Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"

CL: These two questions get to the root of Swift "current and future". In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead. Recall that Swift is only a bit over two years old at this point: Swift 1.0 was released in September 2014.

If you compare Swift to other popular contemporary programming languages (e.g. Python, Java/C#, C/C++, Javascript, Objective-C, etc) a major difference is that Swift was designed for generality: these languages were initially designed for a specific niche and use case and then organically growing out.

In contrast, Swift was designed from the start to eventually span the gamut from scripting language to systems programming, and its underlying design choices anticipate the day when all the pieces come together. This is no small feat, because it requires pulling together the strengths of each of these languages into a single coherent whole, while balancing out the tradeoffs forced by each of them.

For example, if you compare Swift 3 to scripting languages like Python, Perl, and Ruby, I think that Swift is already as expressive, teachable, and easy to learn as a scripting language, and it includes a REPL and support for #! scripts. That said, there are obvious missing holes, like no regular expression literals, no multi-line string literals, and poor support for functionality like command line argument processing - Swift needs to be more "batteries included".

If you compare Swift 3 to systems programming languages with C/C++ or Rust, then I think there is a lot to like: Swift provides full low-level memory control through its "unsafe" APIs (e.g. you can directly call malloc and free with no overhead from Swift, if that is what you want to do). Swift also has a much lighter weight runtime than many other high level languages (e.g. no tracing Garbage Collector or threading runtime is required). That said, it has a number of holes in the story: no support for memory mapped I/O, no support for inline assembly, etc. More significantly, getting low-level control of memory requires dropping down to the Unsafe APIs, which provide a very C/C++ level of control, but also provides the C/C++ level lack of memory safety. I'm optimistic that the ongoing work to bring an ownership model to Swift will provide the kinds of safety and performance that Rust offers in this space.

If you compare Swift 3 to general application level languages like Java, I think it is already pretty great (and has been proven by its rapid adoption in the iOS ecosystem). The server space has very similar needs to general app development, but both would really benefit from a concurrency model (which I expect to be an important focus of Swift 5).

Beyond these areas of investment there is no shortage of ideas for other things to add over time. For example, the dynamic reflection capabilities you mention need to be baked out, and many people are interested in things like pre/post-conditions, language support for typestate, further improvements to the generics system, improved submodules/namespacing, a hygienic macro system, tail calls, and so much more.

There is a long and exciting road ahead for Swift development, and one of the most important features was a key part of Swift 3: unlike in the past, we expect Swift to be extremely source compatible going forward. These new capabilities should be addable to the language and runtime without breaking code. If you are interested in following along or getting involved with Swift development, I highly encourage you to check out the swift-evolution mailing list and project on GitHub.

Any hope for more productive programming?
by Kohath

I work in the semiconductor industry and our ASIC designs have seen a few large jumps in productivity:

• Transistors and custom layouts transitioned to standard cell flows and automated P&R.
• Design using logic blocks transitioned to synthesized design using RTL with HDLs.
• Most recently, we are synthesizing circuits directly from C language.

In the same timeframe, programming has remained more or less the same as it always was. New languages offer only incremental productivity improvements, and most of the big problems from 10 or 20 years ago remain big problems.

Do you know of any initiatives that could produce a step-function increase (say 5-10x) in coding productivity for average engineers?

CL: There have been a number of attempts to make a "big leap" in programmer productivity over the years, including visual programming languages, fourth-generation" programming languages, and others. That said, in terms of broad impact on the industry, none of these have been as successful as the widespread rise of "package" ecosystems (like Perl's CPAN, Ruby Gems, NPM in Javascript, and many others), which allow rapid reuse of other people's code. When I compare the productivity of a modern software developer using these systems, I think it is easy to see a 10x improvement in coding productivity, compared to a C or C++ programmer 10 years ago.

Swift embraces this direction with its builtin package manager "SwiftPM". Just as the Swift language learns from other languages, SwiftPM is designed with an awareness of other package ecosystems and attempts to assemble their best ideas into a single coherent vision. SwiftPM also provides a portable build system, allowing development and deployment of cross-platform Swift packages. SwiftPM is still comparatively early on in design, but has some heavy hitters behind it, particularly those involved in the various Swift for the Server initiatives. You might also be interested in the online package catalog hosted by IBM.

Looking ahead, even though a bit cliche, I'd have to say that machine learning techniques (convolutional neural nets and deep neural nets for example) really are changing the world by making formerly impossible things merely "hard". While it currently seems that you need a team of Ph.D's to apply and develop these techniques, when they become better understood and developed, I expect them to be more widely accessible to the rest of us. Another really interesting recent development is the idea of "word vectors," which is a pretty cool area to geek out on.

You asked, he answered! The creator of Apple's Swift programming language (and a self-described "long-time reader/fan of Slashdot") stopped by on his way to a new job at Tesla just to field questions from Slashdot readers. Read on for Chris's answers... Questions, and my best wishes.
by Volanin

Since you're the creator of LLVM, I'd like to know, in your opinion what's the greatest advantage of LLVM/Clang over the traditional and established GNU GCC compiler. Also, what's the greatest advantage of GNU GCC (or if you'd prefer, any other compiler) over LLVM/Clang, something that you'd like to "port" someday?

CL: GCC and LLVM/Clang have had a mutually beneficial relationship for years. Clang's early lead in terms of compiler error message expressivity has led the GCC developers to improve their error messages, and obviously GCC provides a very high bar to meet when LLVM and Clang were being brought up. It is important to keep in mind that GCC doesn't have to lose for Clang to win (or visa versa). Also, I haven't used GCC for many years, that said, since you asked I'll try to answer to the best of my knowledge:

From my understanding, for a C or C++ programmer on Linux, the code generated by GCC and Clang is comparable (each win some cases and lose other cases). Both compilers have a similar feature set (e.g. OpenMP is supported by both). Clang compiles code significantly faster than GCC in many cases, still generates slightly better errors and warning messages than GCC, and is usually a bit ahead in terms of support for the C++ standard. That said, the most significant benefit is improved compile time.

Going one level deeper, the most significant benefit I see of the LLVM optimizer and code generator over GCC is its architecture and design. LLVM is built with a modular library-based design, which has allowed it to be used in a variety of ways that we didn't anticipate. For example, it has been used by movie studios to JIT compile and optimize shaders used in special effects, has been used to optimize database queries, and LLVM is used as the code generator for a much wider range of source languages than GCC.

Similarly, the most significant benefit of Clang is that it is also modular. It specifically tackles problems related to IDE integration (including code completion, syntax highlighting, etc) and has a mature and vibrant tooling ecosystem build around it. Clang's design (e.g. lack of pervasive global variables) also allows it to be used at runtime, for example in OpenCL and CUDA implementations.

The greatest advantage I can see of GCC over LLVM/Clang is that it is the default compiler on almost all Linux distributions, and of course Linux is an incredibly important for developers. I'd love to see more Linux distributions start shipping Clang by default. Finally, GCC provides an Ada frontend, and I'm not aware of a supported solution for Ada + LLVM.

Future of LLVM?
by mveloso

Where do you see LLVM going?

CL: There are lots of things going on, driven by the amazing community of developers (which is growing like crazy) driving forward the llvm.org projects. LLVM is now used pervasively across the industry, by companies like Apple, Intel, AMD, Nvidia, Qualcomm, Google, Sony, Facebook, ARM, Microsoft, FreeBSD, and more. I'd love for it to be used more widely on Windows and Linux.

At the same time, I expect to see LLVM to continue to improve in a ton of different ways. For example, ThinLTO is an extremely promising approach that promises to bring scalable link time optimization to everyone, potentially replacing the default for -O3 builds. Similarly, there is work going on to speed up compile times, add support for the Microsoft PDB debug information format, and too many other things to mention here. It is an incredibly exciting time. If you're interested in a taste of what is happening, take a look at the proceedings from the recent 2016 LLVM Developer Meeting.

Finally, the LLVM Project continues to expand. Relatively recent additions include llgo (a Go frontend) and lld (a faster linker than "Gold"), and there are rumors that a Fortran frontend may soon join the fold.

The Mythical Compiler -VLIW
by Anonymous Coward

Is there any hope for VLIW architectures? The general consensus seems to be that Itanium tanked because the compiler technology wasn't able to make the leap needed. Linus complained about the Itanium ISA exposing the pipelines to assembly developers. What are the challenges from a compiler writers perspective with VLIW?

CL: I can't speak to why Itanium failed (I suspect that many non-technical issues like business decisions and schedule impacted it), but VLIW is hardly dead. VLIW designs are actively used in some modern GPUs and is widely used in DSPs - one example supported by LLVM is the Qualcomm Hexagon chip. The major challenge when compiling for a VLIW architecture is that the compiler needs good profile information, so it has an accurate idea of the dynamic behavior of the program.

How much of Swift is Based on Groovy?
by Anonymous Coward

So how much of Swift was inspired by Groovy? Both come from more high-end languages and look and act almost identical.

CL: It is an intentional design point of Swift that it look and feel "familiar" to folks coming from many other languages: not just Groovy. Feeling familiar and eliminating unnecessary differences from other programming languages is a way of reducing barriers of entry to start programming in Swift. It is also clearly true that many other languages syntactically influence each other, so you see convergence of ideas coming from many different places.

That said, I think it is a stretch to say that Swift and Groovy look and act "identical", except in some very narrow cases. The goal of Swift is simply to be as great as possible, it is not trying to imitate some other programming language.

C#
by Anonymous Coward

What do you think about Microsoft and C# versus the merits of Swift?

CL: I have a ton of respect for C#, Rust, and many other languages, and Swift certainly benefited by being able to observe their evolution over time. As such, there are a lot of similarities between these languages, and it isn't an accident.

Comparing languages is difficult in this format, because a lot of the answers come down to "it depends on what you're trying to do", but I'll give it a shot. C# has the obvious benefit of working with the .NET ecosystem, whereas Swift is stronger at working in existing C and Objective-C ecosystems like Cocoa and POSIX.

From a language level, Swift has a more general type system than C# does, offers more advanced value types, protocol extensions, etc. Swift also has advantages in mobile use cases because ARC requires significantly less memory than garbage collected languages for a given workload. On the other hand, C# has a number of cool features that Swift lacks, like async/await, LINQ, etc.

Rust
by Anonymous Coward

Chris, what are your general thoughts about Rust as a programming language?

CL: I'm a huge Rust fan: I think that it is a great language and its community is amazing. Rust has a clear lead over Swift in the system programming space (e.g. for writing kernels and device drivers) and I consider it one of the very few candidates that could lead to displacing C and C++ with a more safe programming language.

That said, Swift has advantages in terms of more developers using it, a more mature IDE story, and offers a much shallower learning curve for new developers. It is also very likely that a future version of Swift will introduce move-only types and a full ownership model, which will make Swift a lot more interesting in the system programming space.

BASIC
by jo7hs2

As someone who has been involved with the development of programming languages, do you think it is still possible to come up with a modern-day replacement for BASIC that can operate in modern GUI environments?

It seems like all attempts since we went GUI (aside from maybe early VisualBASIC and Hypercard) have been too complicated, and all attempts have been platform-specific or abandoned. With the emphasis on coding in schools, it seems like it would be helpful to have a good, simple, introductory language like we had in BASIC.

CL: It's probably a huge shock, but I think Swift could be this language. If you have an iPad, you should try out the free Swift Playgrounds app, which is aimed to teach people about programming, assuming no prior experience. I think it would be great for Swift to expand to provide a VisualBASIC-like scripting solution for GUI apps as well.

Cross-platform
by psergiu

How cross-platform is Swift? Are the GUI libraries platform-dependent or independent? I.E.: Can I write a single Swift program with a GUI that will compile, work the same and look similar on multiple platforms: Linux, Mac OS, Real Unix-es & BSDs, AIX, Windows?

CL: Swift is Open Source, has a vibrant community with hundreds of contributors, and builds on the proven LLVM and Clang technology stack. The Swift community has ported Swift itself to many different platforms beyond Apple platforms: it runs on various Linux distros and work is underway by various people to port it to Android, Windows, various BSDs, and even IBM mainframes.

That said, Swift does not provide a GUI layer, so you need to use native technologies to do so. Swift helps by providing great support for interoperating with existing C code (and will hopefully expand to support C++ and other languages in the future). It is possible for someone to design and build a cross platform GUI layer, but I'm not aware of any serious efforts to do so.

Exception Handling
by andywest

Why did Swift NOT have exception handling in the first couple of versions?

CL: Swift 1 (released in 2014) didn't include an error handling model simply because it wasn't ready in time: it was added in Swift 2 (2015). Swift 2 included a number of great improvements that weren't ready for Swift 1, including protocol extensions. Protocol extensions dramatically expanded the design space of what you can do with Swift, bringing a new era of "protocol oriented programming". That said, even Swift 3 (2016) is still missing a ton of great things we hope to add over the coming years: there is a long and exciting road ahead! See questions below for more details.

Why are strings passed by value?
by Anonymous Coward

Strings are immutable pass-by-reference objects in most modern languages. Why did you make this decision?

CL: Swift uses value semantics for all of its "built in" collections, including String, Array, Dictionary, etc. This provides a number of great advantages by improving efficiency (permitting in-place updating instead of requiring reallocation), eliminating large classes of bugs related to unanticipated sharing (someone mutates your collection when you are using it), and defines away a class of concurrency issues. Strings are perhaps the simplest of any of these cases, but they get the efficiency and other benefits.

If you're interested in more detail, there is a wealth of good information about the benefits of value vs reference types online. One great place to start is the "Building Better Apps with Value Types in Swift" talk from WWDC 2015.

As a language designer
by superwiz

Since you have been involved with 2 lauded languages, you are in a good position to answer the following question: "are modern languages forced to rely on language run-time to compensate for the facilities lacking in modern operating systems?" In other words, have the languages tried to compensate for the fact that there are no new OS-level light-weight paradigms to take advantage of multi-core processors?

CL: I'm not sure exactly what you mean here, but yes: if an OS provides functionality, there is no reason for a language runtime to replicate it, so runtimes really only exist to supplement what the OS provides. That said, the line between the OS and libraries is a very blurry one: Grand Central Dispatch (GCD) is a great example, because it is a combination of user space code, kernel primitives, and more all designed together.

Parallelism
by bill_mcgonigle

Say, about fifteen years ago, there was huge buzz about how languages and compilers were going to take care of the "Moore's Law Problem" by automating the parallelism of every task that could be broken up. With single-static assignment trees and the like the programmer was going to be freed from manually doing the parallelism.

With manufacturers starting to turn out 32- and 64-core chips, I'm wondering how well did we did on that front. I don't see a ton of software automatically not pegging a core on my CPU's. The ones that aren't quite as bad are mostly just doing a fork() in 2017. Did we get anywhere? Are we almost there? Is software just not compiled right now? Did it turn out to be harder than expected? Were languages not up to the task? Is hardware (e.g. memory access architectures) insufficient? Was the possibility oversold in the first place?

CL: I can't provide a global answer, but clearly parallelism is being well utilized in some "easy" cases (e.g. speeding up build time of large software, speed of 3d rendering, etc). Also, while large machines are available, most computers are only running machines with 1-4 cores (e.g. mobile phones and laptops), which means that most software doesn't have to cope with the prospects of 32-core machines⦠yet.

Looking forward, I am skeptical of the promises of overly magic solutions like compiler auto-parallelization of single threaded code. These "heroic" approaches can work on specific benchmarks and other narrow situations, but don't lead to a predictable and reliable programmer model. For example, a good result would be for you to use one of these systems and get a 32x speedup on your codebase. A really bad result would be to then make a minor change or bug fix to your code, and find out that it caused a 32x slowdown by defeating the prior compiler optimization. Magic solutions are problematic because they don't provide programmer control.

As such, my preferred approach is for the programming language to provide expressive ways for the programmer to describe their parallelism, and then allow the compiler and runtime to efficiently optimize it. Things like actor models, OpenMP, C++ AMP, and goroutines seem like the best approach. I expect concurrency to be an active area of development in the Swift language, and hope that the first pieces of the story will land in Swift 5 (2018).

Any insight into language design choices?
by EMB Numbers

I am a 25+ year Objective-C programmer and among other topics, I teach "Mobile App Development" and "Comparative Languages" at a university. I confess to being perplexed by some Swift language design decisions. For example,

• Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
• Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"

CL: These two questions get to the root of Swift "current and future". In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead. Recall that Swift is only a bit over two years old at this point: Swift 1.0 was released in September 2014.

If you compare Swift to other popular contemporary programming languages (e.g. Python, Java/C#, C/C++, Javascript, Objective-C, etc) a major difference is that Swift was designed for generality: these languages were initially designed for a specific niche and use case and then organically growing out.

In contrast, Swift was designed from the start to eventually span the gamut from scripting language to systems programming, and its underlying design choices anticipate the day when all the pieces come together. This is no small feat, because it requires pulling together the strengths of each of these languages into a single coherent whole, while balancing out the tradeoffs forced by each of them.

For example, if you compare Swift 3 to scripting languages like Python, Perl, and Ruby, I think that Swift is already as expressive, teachable, and easy to learn as a scripting language, and it includes a REPL and support for #! scripts. That said, there are obvious missing holes, like no regular expression literals, no multi-line string literals, and poor support for functionality like command line argument processing - Swift needs to be more "batteries included".

If you compare Swift 3 to systems programming languages with C/C++ or Rust, then I think there is a lot to like: Swift provides full low-level memory control through its "unsafe" APIs (e.g. you can directly call malloc and free with no overhead from Swift, if that is what you want to do). Swift also has a much lighter weight runtime than many other high level languages (e.g. no tracing Garbage Collector or threading runtime is required). That said, it has a number of holes in the story: no support for memory mapped I/O, no support for inline assembly, etc. More significantly, getting low-level control of memory requires dropping down to the Unsafe APIs, which provide a very C/C++ level of control, but also provides the C/C++ level lack of memory safety. I'm optimistic that the ongoing work to bring an ownership model to Swift will provide the kinds of safety and performance that Rust offers in this space.

If you compare Swift 3 to general application level languages like Java, I think it is already pretty great (and has been proven by its rapid adoption in the iOS ecosystem). The server space has very similar needs to general app development, but both would really benefit from a concurrency model (which I expect to be an important focus of Swift 5).

Beyond these areas of investment there is no shortage of ideas for other things to add over time. For example, the dynamic reflection capabilities you mention need to be baked out, and many people are interested in things like pre/post-conditions, language support for typestate, further improvements to the generics system, improved submodules/namespacing, a hygienic macro system, tail calls, and so much more.

There is a long and exciting road ahead for Swift development, and one of the most important features was a key part of Swift 3: unlike in the past, we expect Swift to be extremely source compatible going forward. These new capabilities should be addable to the language and runtime without breaking code. If you are interested in following along or getting involved with Swift development, I highly encourage you to check out the swift-evolution mailing list and project on GitHub.

Any hope for more productive programming?
by Kohath

I work in the semiconductor industry and our ASIC designs have seen a few large jumps in productivity:

• Transistors and custom layouts transitioned to standard cell flows and automated P&R.
• Design using logic blocks transitioned to synthesized design using RTL with HDLs.
• Most recently, we are synthesizing circuits directly from C language.

In the same timeframe, programming has remained more or less the same as it always was. New languages offer only incremental productivity improvements, and most of the big problems from 10 or 20 years ago remain big problems.

Do you know of any initiatives that could produce a step-function increase (say 5-10x) in coding productivity for average engineers?

CL: There have been a number of attempts to make a "big leap" in programmer productivity over the years, including visual programming languages, fourth-generation" programming languages, and others. That said, in terms of broad impact on the industry, none of these have been as successful as the widespread rise of "package" ecosystems (like Perl's CPAN, Ruby Gems, NPM in Javascript, and many others), which allow rapid reuse of other people's code. When I compare the productivity of a modern software developer using these systems, I think it is easy to see a 10x improvement in coding productivity, compared to a C or C++ programmer 10 years ago.

Swift embraces this direction with its builtin package manager "SwiftPM". Just as the Swift language learns from other languages, SwiftPM is designed with an awareness of other package ecosystems and attempts to assemble their best ideas into a single coherent vision. SwiftPM also provides a portable build system, allowing development and deployment of cross-platform Swift packages. SwiftPM is still comparatively early on in design, but has some heavy hitters behind it, particularly those involved in the various Swift for the Server initiatives. You might also be interested in the online package catalog hosted by IBM.

Looking ahead, even though a bit cliche, I'd have to say that machine learning techniques (convolutional neural nets and deep neural nets for example) really are changing the world by making formerly impossible things merely "hard". While it currently seems that you need a team of Ph.D's to apply and develop these techniques, when they become better understood and developed, I expect them to be more widely accessible to the rest of us. Another really interesting recent development is the idea of "word vectors," which is a pretty cool area to geek out on.

You asked, he answered! The creator of Apple's Swift programming language (and a self-described "long-time reader/fan of Slashdot") stopped by on his way to a new job at Tesla just to field questions from Slashdot readers. Read on for Chris's answers... Questions, and my best wishes.
by Volanin

Since you're the creator of LLVM, I'd like to know, in your opinion what's the greatest advantage of LLVM/Clang over the traditional and established GNU GCC compiler. Also, what's the greatest advantage of GNU GCC (or if you'd prefer, any other compiler) over LLVM/Clang, something that you'd like to "port" someday?

CL: GCC and LLVM/Clang have had a mutually beneficial relationship for years. Clang's early lead in terms of compiler error message expressivity has led the GCC developers to improve their error messages, and obviously GCC provides a very high bar to meet when LLVM and Clang were being brought up. It is important to keep in mind that GCC doesn't have to lose for Clang to win (or visa versa). Also, I haven't used GCC for many years, that said, since you asked I'll try to answer to the best of my knowledge:

From my understanding, for a C or C++ programmer on Linux, the code generated by GCC and Clang is comparable (each win some cases and lose other cases). Both compilers have a similar feature set (e.g. OpenMP is supported by both). Clang compiles code significantly faster than GCC in many cases, still generates slightly better errors and warning messages than GCC, and is usually a bit ahead in terms of support for the C++ standard. That said, the most significant benefit is improved compile time.

Going one level deeper, the most significant benefit I see of the LLVM optimizer and code generator over GCC is its architecture and design. LLVM is built with a modular library-based design, which has allowed it to be used in a variety of ways that we didn't anticipate. For example, it has been used by movie studios to JIT compile and optimize shaders used in special effects, has been used to optimize database queries, and LLVM is used as the code generator for a much wider range of source languages than GCC.

Similarly, the most significant benefit of Clang is that it is also modular. It specifically tackles problems related to IDE integration (including code completion, syntax highlighting, etc) and has a mature and vibrant tooling ecosystem build around it. Clang's design (e.g. lack of pervasive global variables) also allows it to be used at runtime, for example in OpenCL and CUDA implementations.

The greatest advantage I can see of GCC over LLVM/Clang is that it is the default compiler on almost all Linux distributions, and of course Linux is an incredibly important for developers. I'd love to see more Linux distributions start shipping Clang by default. Finally, GCC provides an Ada frontend, and I'm not aware of a supported solution for Ada + LLVM.

Future of LLVM?
by mveloso

Where do you see LLVM going?

CL: There are lots of things going on, driven by the amazing community of developers (which is growing like crazy) driving forward the llvm.org projects. LLVM is now used pervasively across the industry, by companies like Apple, Intel, AMD, Nvidia, Qualcomm, Google, Sony, Facebook, ARM, Microsoft, FreeBSD, and more. I'd love for it to be used more widely on Windows and Linux.

At the same time, I expect to see LLVM to continue to improve in a ton of different ways. For example, ThinLTO is an extremely promising approach that promises to bring scalable link time optimization to everyone, potentially replacing the default for -O3 builds. Similarly, there is work going on to speed up compile times, add support for the Microsoft PDB debug information format, and too many other things to mention here. It is an incredibly exciting time. If you're interested in a taste of what is happening, take a look at the proceedings from the recent 2016 LLVM Developer Meeting.

Finally, the LLVM Project continues to expand. Relatively recent additions include llgo (a Go frontend) and lld (a faster linker than "Gold"), and there are rumors that a Fortran frontend may soon join the fold.

The Mythical Compiler -VLIW
by Anonymous Coward

Is there any hope for VLIW architectures? The general consensus seems to be that Itanium tanked because the compiler technology wasn't able to make the leap needed. Linus complained about the Itanium ISA exposing the pipelines to assembly developers. What are the challenges from a compiler writers perspective with VLIW?

CL: I can't speak to why Itanium failed (I suspect that many non-technical issues like business decisions and schedule impacted it), but VLIW is hardly dead. VLIW designs are actively used in some modern GPUs and is widely used in DSPs - one example supported by LLVM is the Qualcomm Hexagon chip. The major challenge when compiling for a VLIW architecture is that the compiler needs good profile information, so it has an accurate idea of the dynamic behavior of the program.

How much of Swift is Based on Groovy?
by Anonymous Coward

So how much of Swift was inspired by Groovy? Both come from more high-end languages and look and act almost identical.

CL: It is an intentional design point of Swift that it look and feel "familiar" to folks coming from many other languages: not just Groovy. Feeling familiar and eliminating unnecessary differences from other programming languages is a way of reducing barriers of entry to start programming in Swift. It is also clearly true that many other languages syntactically influence each other, so you see convergence of ideas coming from many different places.

That said, I think it is a stretch to say that Swift and Groovy look and act "identical", except in some very narrow cases. The goal of Swift is simply to be as great as possible, it is not trying to imitate some other programming language.

C#
by Anonymous Coward

What do you think about Microsoft and C# versus the merits of Swift?

CL: I have a ton of respect for C#, Rust, and many other languages, and Swift certainly benefited by being able to observe their evolution over time. As such, there are a lot of similarities between these languages, and it isn't an accident.

Comparing languages is difficult in this format, because a lot of the answers come down to "it depends on what you're trying to do", but I'll give it a shot. C# has the obvious benefit of working with the .NET ecosystem, whereas Swift is stronger at working in existing C and Objective-C ecosystems like Cocoa and POSIX.

From a language level, Swift has a more general type system than C# does, offers more advanced value types, protocol extensions, etc. Swift also has advantages in mobile use cases because ARC requires significantly less memory than garbage collected languages for a given workload. On the other hand, C# has a number of cool features that Swift lacks, like async/await, LINQ, etc.

Rust
by Anonymous Coward

Chris, what are your general thoughts about Rust as a programming language?

CL: I'm a huge Rust fan: I think that it is a great language and its community is amazing. Rust has a clear lead over Swift in the system programming space (e.g. for writing kernels and device drivers) and I consider it one of the very few candidates that could lead to displacing C and C++ with a more safe programming language.

That said, Swift has advantages in terms of more developers using it, a more mature IDE story, and offers a much shallower learning curve for new developers. It is also very likely that a future version of Swift will introduce move-only types and a full ownership model, which will make Swift a lot more interesting in the system programming space.

BASIC
by jo7hs2

As someone who has been involved with the development of programming languages, do you think it is still possible to come up with a modern-day replacement for BASIC that can operate in modern GUI environments?

It seems like all attempts since we went GUI (aside from maybe early VisualBASIC and Hypercard) have been too complicated, and all attempts have been platform-specific or abandoned. With the emphasis on coding in schools, it seems like it would be helpful to have a good, simple, introductory language like we had in BASIC.

CL: It's probably a huge shock, but I think Swift could be this language. If you have an iPad, you should try out the free Swift Playgrounds app, which is aimed to teach people about programming, assuming no prior experience. I think it would be great for Swift to expand to provide a VisualBASIC-like scripting solution for GUI apps as well.

Cross-platform
by psergiu

How cross-platform is Swift? Are the GUI libraries platform-dependent or independent? I.E.: Can I write a single Swift program with a GUI that will compile, work the same and look similar on multiple platforms: Linux, Mac OS, Real Unix-es & BSDs, AIX, Windows?

CL: Swift is Open Source, has a vibrant community with hundreds of contributors, and builds on the proven LLVM and Clang technology stack. The Swift community has ported Swift itself to many different platforms beyond Apple platforms: it runs on various Linux distros and work is underway by various people to port it to Android, Windows, various BSDs, and even IBM mainframes.

That said, Swift does not provide a GUI layer, so you need to use native technologies to do so. Swift helps by providing great support for interoperating with existing C code (and will hopefully expand to support C++ and other languages in the future). It is possible for someone to design and build a cross platform GUI layer, but I'm not aware of any serious efforts to do so.

Exception Handling
by andywest

Why did Swift NOT have exception handling in the first couple of versions?

CL: Swift 1 (released in 2014) didn't include an error handling model simply because it wasn't ready in time: it was added in Swift 2 (2015). Swift 2 included a number of great improvements that weren't ready for Swift 1, including protocol extensions. Protocol extensions dramatically expanded the design space of what you can do with Swift, bringing a new era of "protocol oriented programming". That said, even Swift 3 (2016) is still missing a ton of great things we hope to add over the coming years: there is a long and exciting road ahead! See questions below for more details.

Why are strings passed by value?
by Anonymous Coward

Strings are immutable pass-by-reference objects in most modern languages. Why did you make this decision?

CL: Swift uses value semantics for all of its "built in" collections, including String, Array, Dictionary, etc. This provides a number of great advantages by improving efficiency (permitting in-place updating instead of requiring reallocation), eliminating large classes of bugs related to unanticipated sharing (someone mutates your collection when you are using it), and defines away a class of concurrency issues. Strings are perhaps the simplest of any of these cases, but they get the efficiency and other benefits.

If you're interested in more detail, there is a wealth of good information about the benefits of value vs reference types online. One great place to start is the "Building Better Apps with Value Types in Swift" talk from WWDC 2015.

As a language designer
by superwiz

Since you have been involved with 2 lauded languages, you are in a good position to answer the following question: "are modern languages forced to rely on language run-time to compensate for the facilities lacking in modern operating systems?" In other words, have the languages tried to compensate for the fact that there are no new OS-level light-weight paradigms to take advantage of multi-core processors?

CL: I'm not sure exactly what you mean here, but yes: if an OS provides functionality, there is no reason for a language runtime to replicate it, so runtimes really only exist to supplement what the OS provides. That said, the line between the OS and libraries is a very blurry one: Grand Central Dispatch (GCD) is a great example, because it is a combination of user space code, kernel primitives, and more all designed together.

Parallelism
by bill_mcgonigle

Say, about fifteen years ago, there was huge buzz about how languages and compilers were going to take care of the "Moore's Law Problem" by automating the parallelism of every task that could be broken up. With single-static assignment trees and the like the programmer was going to be freed from manually doing the parallelism.

With manufacturers starting to turn out 32- and 64-core chips, I'm wondering how well did we did on that front. I don't see a ton of software automatically not pegging a core on my CPU's. The ones that aren't quite as bad are mostly just doing a fork() in 2017. Did we get anywhere? Are we almost there? Is software just not compiled right now? Did it turn out to be harder than expected? Were languages not up to the task? Is hardware (e.g. memory access architectures) insufficient? Was the possibility oversold in the first place?

CL: I can't provide a global answer, but clearly parallelism is being well utilized in some "easy" cases (e.g. speeding up build time of large software, speed of 3d rendering, etc). Also, while large machines are available, most computers are only running machines with 1-4 cores (e.g. mobile phones and laptops), which means that most software doesn't have to cope with the prospects of 32-core machines⦠yet.

Looking forward, I am skeptical of the promises of overly magic solutions like compiler auto-parallelization of single threaded code. These "heroic" approaches can work on specific benchmarks and other narrow situations, but don't lead to a predictable and reliable programmer model. For example, a good result would be for you to use one of these systems and get a 32x speedup on your codebase. A really bad result would be to then make a minor change or bug fix to your code, and find out that it caused a 32x slowdown by defeating the prior compiler optimization. Magic solutions are problematic because they don't provide programmer control.

As such, my preferred approach is for the programming language to provide expressive ways for the programmer to describe their parallelism, and then allow the compiler and runtime to efficiently optimize it. Things like actor models, OpenMP, C++ AMP, and goroutines seem like the best approach. I expect concurrency to be an active area of development in the Swift language, and hope that the first pieces of the story will land in Swift 5 (2018).

Any insight into language design choices?
by EMB Numbers

I am a 25+ year Objective-C programmer and among other topics, I teach "Mobile App Development" and "Comparative Languages" at a university. I confess to being perplexed by some Swift language design decisions. For example,

• Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
• Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"

CL: These two questions get to the root of Swift "current and future". In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead. Recall that Swift is only a bit over two years old at this point: Swift 1.0 was released in September 2014.

If you compare Swift to other popular contemporary programming languages (e.g. Python, Java/C#, C/C++, Javascript, Objective-C, etc) a major difference is that Swift was designed for generality: these languages were initially designed for a specific niche and use case and then organically growing out.

In contrast, Swift was designed from the start to eventually span the gamut from scripting language to systems programming, and its underlying design choices anticipate the day when all the pieces come together. This is no small feat, because it requires pulling together the strengths of each of these languages into a single coherent whole, while balancing out the tradeoffs forced by each of them.

For example, if you compare Swift 3 to scripting languages like Python, Perl, and Ruby, I think that Swift is already as expressive, teachable, and easy to learn as a scripting language, and it includes a REPL and support for #! scripts. That said, there are obvious missing holes, like no regular expression literals, no multi-line string literals, and poor support for functionality like command line argument processing - Swift needs to be more "batteries included".

If you compare Swift 3 to systems programming languages with C/C++ or Rust, then I think there is a lot to like: Swift provides full low-level memory control through its "unsafe" APIs (e.g. you can directly call malloc and free with no overhead from Swift, if that is what you want to do). Swift also has a much lighter weight runtime than many other high level languages (e.g. no tracing Garbage Collector or threading runtime is required). That said, it has a number of holes in the story: no support for memory mapped I/O, no support for inline assembly, etc. More significantly, getting low-level control of memory requires dropping down to the Unsafe APIs, which provide a very C/C++ level of control, but also provides the C/C++ level lack of memory safety. I'm optimistic that the ongoing work to bring an ownership model to Swift will provide the kinds of safety and performance that Rust offers in this space.

If you compare Swift 3 to general application level languages like Java, I think it is already pretty great (and has been proven by its rapid adoption in the iOS ecosystem). The server space has very similar needs to general app development, but both would really benefit from a concurrency model (which I expect to be an important focus of Swift 5).

Beyond these areas of investment there is no shortage of ideas for other things to add over time. For example, the dynamic reflection capabilities you mention need to be baked out, and many people are interested in things like pre/post-conditions, language support for typestate, further improvements to the generics system, improved submodules/namespacing, a hygienic macro system, tail calls, and so much more.

There is a long and exciting road ahead for Swift development, and one of the most important features was a key part of Swift 3: unlike in the past, we expect Swift to be extremely source compatible going forward. These new capabilities should be addable to the language and runtime without breaking code. If you are interested in following along or getting involved with Swift development, I highly encourage you to check out the swift-evolution mailing list and project on GitHub.

Any hope for more productive programming?
by Kohath

I work in the semiconductor industry and our ASIC designs have seen a few large jumps in productivity:

• Transistors and custom layouts transitioned to standard cell flows and automated P&R.
• Design using logic blocks transitioned to synthesized design using RTL with HDLs.
• Most recently, we are synthesizing circuits directly from C language.

In the same timeframe, programming has remained more or less the same as it always was. New languages offer only incremental productivity improvements, and most of the big problems from 10 or 20 years ago remain big problems.

Do you know of any initiatives that could produce a step-function increase (say 5-10x) in coding productivity for average engineers?

CL: There have been a number of attempts to make a "big leap" in programmer productivity over the years, including visual programming languages, fourth-generation" programming languages, and others. That said, in terms of broad impact on the industry, none of these have been as successful as the widespread rise of "package" ecosystems (like Perl's CPAN, Ruby Gems, NPM in Javascript, and many others), which allow rapid reuse of other people's code. When I compare the productivity of a modern software developer using these systems, I think it is easy to see a 10x improvement in coding productivity, compared to a C or C++ programmer 10 years ago.

Swift embraces this direction with its builtin package manager "SwiftPM". Just as the Swift language learns from other languages, SwiftPM is designed with an awareness of other package ecosystems and attempts to assemble their best ideas into a single coherent vision. SwiftPM also provides a portable build system, allowing development and deployment of cross-platform Swift packages. SwiftPM is still comparatively early on in design, but has some heavy hitters behind it, particularly those involved in the various Swift for the Server initiatives. You might also be interested in the online package catalog hosted by IBM.

Looking ahead, even though a bit cliche, I'd have to say that machine learning techniques (convolutional neural nets and deep neural nets for example) really are changing the world by making formerly impossible things merely "hard". While it currently seems that you need a team of Ph.D's to apply and develop these techniques, when they become better understood and developed, I expect them to be more widely accessible to the rest of us. Another really interesting recent development is the idea of "word vectors," which is a pretty cool area to geek out on.

C++ creator Bjarne Stroustrup is arguing that we can improve code by grounding generic programming in concepts -- what's required by a template's arguments. An anonymous reader quotes Paul Krill's report on a new paper by Stroustrup: In concepts, Stroustrup sees the solution to the interface specification problem that has long dogged C++, the language he founded more than 35 years ago. "The way we write generic code today is simply too different from the way we write other code," Stroustrup says... Currently an ISO technical specification, concepts provide well-specified interfaces to templates without runtime overhead. Concepts, Stroustrup writes, are intended to complete C++'s support for generic programming as initially envisioned. "The purpose of concepts is to fundamentally simplify and improve design. This leads to fewer bugs and clearer -- often shorter -- code"...

Concepts, Stroustrup believes, will greatly ease engineers' ability to write efficient, reliable C++ code... The most obvious effect will be a massive improvement in the quality of error messages, but the most important long-term effect will be found in the flexibility and clarity of code, Stroustrup says. "In particular, having well-specified interfaces allows for simple, general and zero-overhead overloading of templates. That simplifies much generic code"
Concepts are already available in GNU C Compiler 6.2, and Stroustrup wants them to be included in C++ 20. "In my opinion, concepts should have been part of C++ 17, but the committee couldn't reach consensus on that."

In 1962, 24-year-old Donald Knuth began writing The Art of Computer Programming -- and 55 years later, he's still working on it. An anonymous reader quotes Knuth's web site at Stanford: Volume 4B will begin with a special section called 'Mathematical Preliminaries Redux', which extends the 'Mathematical Preliminaries' of Section 1.2 in Volume 1 to things that I didn't know about in the 1960s. Most of this new material deals with probabilities and expectations of random events; there's also an introduction to the theory of martingales.

You can have a sneak preview by looking at the current draft of pre-fascicle 5a (52 pages), last updated 18 January 2017. As usual, rewards will be given to whoever is first to find and report errors or to make valuable suggestions. I'm particularly interested in receiving feedback about the exercises (of which there are 125) and their answers (of which there are 125).
Over the years Knuth gave out over $20,000 in rewards, though most people didn't cash his highly-coveted "hexadecimal checks", and in 2008 Knuth switched to honorary "hexadecimal certificates". In 2014 Knuth complained about the "dumbing down" of computer science history, and his standards remain high. In his most-recent update, 79-year-old Knuth reminds readers that "There's stuff in here that isn't in Wikipedia yet!"

New submitter kugo2006 writes: NASA announced a plan to research 16 Psyche, an asteroid potentially as large as Mars and primarily composed of Iron and Nickel. The rock is unique in that it has an exposed core, likely a result of a series of collisions, according to Lindy Elkins-Tanton, Psyche's principal investigator. The mission's spacecraft would launch in 2023 and arrive in 2030. According to Global News, Elkins-Tanton calculates that the iron in 16 Psyche would be worth $10,000 quadrillion ($10 quintillion).

Six months after the FBI closed the only unsolved air piracy in American aviation history -- after a 45-year investigation -- there's a new clue. An anonymous reader quotes Seattle news station KING: A band of amateur scientists selected by the Seattle FBI to look for clues in the world's most infamous skyjacking may have found new evidence in the 45-year-old case. They're asking for the public's help because of new, potential leads that could link DB Cooper to the Puget Sound aerospace industry in the early 1970s. The scientific team has been analyzing particles removed from the clip-on tie left behind by Cooper after he hijacked a Northwest Orient passenger jet in November 1971. A powerful electron microscope located more than 100,000 particles on old the JCPenny tie. The team has identified particles like Cerium, Strontium Sulfide, and pure titanium.

Tom Kaye, lead researcher for the group calling itself Citizen Sleuths, says the group is intrigued by the finding, because the elements identified were rarely used in 1971, during the time of Cooper's daring leap with a parachute from a passenger jet. One place they were being used was for Boeing's high-tech Super Sonic Transport plane...
Interestingly, it was even a Boeing aircraft that Cooper hijacked, and witnesses say he wasn't nervous on the flight, and seemed familiar with the terrain below.

New submitter drunkdrone writes: "French authorities investigating the EgyptAir crash that killed 66 people last year believe that the plane may have been brought down by an overheating phone battery," reports International Business Times. Investigators say the fire that broke out on the Airbus A320 in May 2016 started in the spot where the co-pilot had stowed his iPad and iPhone 6S, which he placed on top of the instrument panel in the plane's cockpit. From the report: "EgyptAir flight MS804 was traveling from Paris to Cairo when it disappeared from radar on 19 May 2016. Egyptian investigators have speculated that the crash, which killed all 56 passengers, seven crew members and three security personnel on board, was caused by an act of terrorism due to traces of explosives reported to be found on some the victims. Investigators in France have disputed these claims, saying that data recorded from the aircraft around the time it disappeared points to an accidental fire on the right-hand side of the flight deck, next to the co-pilot. According to The Times, CCTV pulled from cameras at Paris' Charles de Gualle airport show that the co-pilot stored a number of personal items above the dashboard, where the first signs of trouble were detected. This included an automated alert indicating a series of malfunctions on the right-hand flight deck window, followed by smoke alerts going off in a toilet and in the avionics area below the cockpit, minutes before the plane vanished."

sandbagger writes: Kodak, the film stock maker, is bringing back the Ektachrome film stock that was the popular alternative to its other product, Kodachrome. The Ektachrome is more sensitive to the cool side of the spectrum as opposed to the warmer Kodachrome. Apparently the product will be back on shelves later this year. âoeThe reintroduction of one of the most iconic films is supported by the growing popularity of analog photography and a resurgence in shooting film,â Kodak Alaris says. âoeResurgence in the popularity of analog photography has created demand for new and old film products alike. Sales of professional photographic films have been steadily rising over the last few years, with professionals and enthusiasts rediscovering the artistic control offered by manual processes and the creative satisfaction of a physical end product.â

MojoKid writes: Over the past couple of years, Dell has been driving a redesign effort of its consumer and commercial product lines and has systematically been updating both design signatures and the technology platforms within them. Dell's premium consumer XPS product line, perhaps more so than any other, has seen the most significant design reinvention with the likes of its XPS 13 and XPS 15 notebook line. At CES 2017, Dell announced the XPS 27 7760 all-in-one PC that has a radically new look that draws at least one design cue from its XPS notebook siblings, specifically with respect to the display bezel, or the lack thereof. Though Dell isn't officially branding the touch-enabled version of XPS 27 with an "InfinityEdge" display, the side and top bezel is cut to a minimum, accentuating a beautiful 4K IPS panel. However, the machine's display might not be the most standout feature of the 2017 Dell XPS 27. Under that display, Dell actually expanded things mechanically to make room not only for a Windows Hello capable camera but a 10 speaker sound system that was designed in conjunction with Grammy Award-winning music producer and audio engineer, JJ Puig, that takes the system's audio reproduction and output capabilities to a whole new level. Its sound system is very accurate with dual 50 watt amplifiers at less than 1% THD (Total Harmonic Distortion) and a 70Hz to 20KHz frequency response. Though the system is currently built on Intel's Skylake platform, Kaby Lake versions are imminent and with discrete AMD Radeon R9 M470X graphics, it has decent gaming and multimedia chops as well.

the_newsbeagle writes: Making micro-machines that work inside the body is tricky, because hard silicon and metal devices can cause problems. So bioengineers are working on soft and squishy gadgets that can be implanted and do useful work. Here's a soft biobot that's modeled on a Swiss watch mechanism called a Geneva drive. With every tick forward, the tiny gizmo releases a dose of drugs. Getting the material properties just right was a challenge. "If your material is collapsing like jello, it's hard to make robots out of it," says inventor Samuel Sia.

dryriver writes: Just a few years ago the future seemed bright for 3D TVs. The 3D film Avatar smashed all box office records. Every Hollywood studio wanted to make big 3D films. The major TV set manufacturers from LG to Phillips to Panasonic all wanted in on the 3D TV action. A 3D disc format called Blu-ray 3D was agreed on. Sony went as far as putting free 3D TVs in popular pubs in London to show Brits how cool watching football ("Soccer" in the U.S.) in Stereo 3D is. Tens of millions of dollars of 3D TV related ads ran on TV stations across the world. 3D Televisions and 3D content was, simply put, the biggest show in town for a while as far as consumer electronics goes. Then the whole circus gradually collapsed -- 3D TVs failed to sell well and create the multi-billion dollar profits anticipated. 3D at home failed to catch on with consumers. Shooting genuine stereo 3D films (not "post conversions") proved to be expensive and technically challenging. Blu-ray 3D was only modestly successful. Even Nvidia's stereo 3D solutions for PC gamers failed. What, in your opinion, went wrong? Were early 3D TV sets too highly priced? Were there too few 3D films and 3D TV stations available to watch (aka "The Content Problem")? Did people hate wearing active/passive plastic 3D glasses in the living room? Was the price of Blu-ray 3D films and Blu-ray 3D players set too high? Was there something wrong with the stereo 3D effect the industry tried to popularize? Did too many people suffer 3D viewing related "headaches," "dizzyness," "eyesight problems," and similar? Was the then -- still quite new -- 1080p HD 2D television simply "good enough" for the average TV viewer? Another related question: If things went so wrong with 3D TVs, what guarantee is there that the new 3D VR/AR trend won't collapse along similar lines as well?

New submitter Netdoctor writes: Fast Radio Bursts (FRB) are massively powerful short-lived radio bursts from far-away sources, and so far a number of theories exist on what generates them. Recently several were detected in the same general location, which adds to the mystery, as any of these pulses would be powerful enough to destroy a source. Since this group of FRBs were detected with single radio telescope dishes, the exact location was difficult to pinpoint. BBC reports here with results from the Very Large Array in New Mexico being trained on the source. From the report: "Outlining their work at a major conference, astronomers say they have now traced the source of one of these bursts to a different galaxy. Dr Chatterjee, from Cornell University, New York, and colleagues used a multi-antenna radio telescope called the Very Large Array (VLA), which had sufficient resolution to precisely determine the location of a flash known as FRB 121102. In 83 hours of observing time over six months in 2016, the VLA detected nine bursts from FRB 121102. In addition to detecting the bright bursts from FRB 121102, the team's observations also revealed an ongoing, persistent source of weaker radio emission in the same region. The flashes and the persistent source must be within 100 light-years of each other, and scientists think they are likely to be either the same object or physically associated with one another. He said some features of the radio source resembled those associated with large black holes. But he said these were typically found only in large galaxies."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Slashdot reader westand writes, "Wikipedia's 5000 most-visited articles of 2016 have been released, and Donald Trump leads the pack." (Though the site's second-most popular article was about a porn site.) The top 5000 pages account for 21.6 billion views, with 42% of those being mobile traffic... After artificial traffic is discounted, election and celebrity deaths feature prominently.
Wikipedia's article about the U.S. presidential election of 2016 also came in at #11, while their articles about Melania Trump and Hillary Clinton came in at #16 and #19, respectively. Other top-20 articles covered deaths in 2016, as well as "Prince (musician)" and David Bowie, with four more articles that covered 2016 superhero movies also reaching the top 20. (Along with "List of Bollywood films of 2016".) The eighth most-popular article was about web scraping, while Wikipedia's 404.php page was actually more popular than any article on the site.

The original submission also points out that 323 million views were covered by The Wikipedia Zero project, in which mobile operators in the Global South ""'zero-rate' access to Wikimedia sites in their billing system, so their subscribers will not incur data charges while accessing Wikipedia and the sister projects on the mobile web or apps." And Wikipedia adds that their list is generated by Andrew G. West, a senior research scientist at Verisign Labs who "is particularly interested in academic collaboration regarding this English Wikipedia dataset."

Initially rejected by several publishers, "Watership Down" (1972) went on to become one of the best-selling fantasy books of all time. Last Saturday the book's author died peacefully at the age of 96. Long-time Slashdot reader haruchai remembers some of the author's other books: In addition to his much-beloved story about anthropomorphic rabbits, Adams penned two fantasy books set in the fictional Beklan Empire, first Shardik (1974) about a hunter pursuing a giant bear he believes to be imbued with divine power, and Maia (1984), a peasant girl sold into slavery who becomes entangled in a war between neighboring countries.
Adams also wrote a collection of short stories called "Tales From Watership Down" in 1996, and the original "Watership Down" was also made into a movie and an animated TV series. In announcing his death, Richard's family also included a quote from the original "Watership Down".

"It seemed to Hazel that he would not be needing his body any more, so he left it lying on the edge of the ditch, but stopped for a moment to watch his rabbits and to try to get used to the extraordinary feeling that strength and speed were flowing inexhaustibly out of him into their sleek young bodies and healthy senses.

"'You needn't worry about them,' said his companion. 'They'll be alright -- and thousands like them.'"

dryriver writes: A few years ago I bought a multiplayer war game called Soldner: Secret Wars that I had never heard of before. (The game is entirely community maintained now and free to download and play at www.soldnersecretwars.de.) The professional reviews completely and utterly destroyed Soldner -- buggy, bad gameplay, no single-player mode, disappointing graphics, server problems and so on. For me and many other players who did give it a chance beyond the first 30 minutes, Soldner turned out to be the most fun, addictive, varied, satisfying and multi-featured multiplayer war game ever. It had innovative features that AAA titles like Battlefield and COD did not have at all at the time -- fully destructible terrain, walls and buildings, cool physics on everything from jeeps flying off mountaintops to Apache helicopters crashing into Hercules transport aircraft, to dozens of trees being blown down by explosions and then blocking an incoming tank's way. Soldner took a patch or three to become fully stable, but then was just fun, fun, fun to play. So much freedom, so much cool stuff you can do in-game, so many options and gadgets you can play with. By contrast, the far, far simpler -- but better looking -- Battlefield, COD, Medal Of Honor, CounterStrike war games got all the critical praise, made the tens of millions in profit per release, became longstanding franchises and are, to this day, not half the fun to play that Soldner is. How does this happen? How does a title like Soldner, that tried to do more new stuff than the other war games combined, get trashed by every reviewer, and then far less innovative and fun to play war games like BF, COD, CS sell tens of millions of copies per release and get rave reviews all around?

schwit1 quotes a report from The Sun: Scientists believe a massive object which could change our understanding of history is hidden beneath the Antarctic ice. The huge and mysterious "anomaly" is thought to be lurking beneath the frozen wastes of an area called Wilkes Land. It stretches for a distance of 151 miles across and has a maximum depth of about 848 meters. Some researchers believe it is the remains of a truly massive asteroid which was more than twice the size of the Chicxulub space rock which wiped out the dinosaurs. If this explanation is true, it could mean this killer asteroid caused the Permian-Triassic extinction event which killed 96 percent of Earth's sea creatures and up to 70 percent of the vertebrate organisms living on land.This "Wilkes Land gravity anomaly" was first uncovered in 2006, when NASA satellites spotted gravitational changes which indicated the presence of a huge object sitting in the middle of a 300 mile wide impact crater.

Mikkeles quotes a report from CBC.ca: Vera Rubin, a pioneering astronomer who helped find powerful evidence of dark matter, has died, her son said Monday. She was 88. Vera Rubin found that galaxies don't quite rotate the way they were predicted, and that lent support to the theory that some other force was at work, namely dark matter. Rubin's scientific achievements earned her numerous awards and honors, including a National Medal of Science presented by then-president Bill Clinton in 1993 "for her pioneering research programs in observational cosmology." She also became the second female astronomer to be elected to the National Academy of Sciences.

earlytime writes: Large scale account hacks such as the billion user Yahoo breach and targeted phishing hacks of gmail accounts during the U.S. election have made 2016 an infamous year for web security. Along comes U2F/web-security keys to address these issues at a critical time. Ars Technica reports that U2F keys "may be the world's best hope against account takeovers": "The Security Keys are based on Universal Second Factor, an open standard that's easy for end users to use and straightforward for engineers to stitch into hardware and websites. When plugged into a standard USB port, the keys provide a 'cryptographic assertion' that's just about impossible for attackers to guess or phish. Accounts can require that cryptographic key in addition to a normal user password when users log in. Google, Dropbox, GitHub, and other sites have already implemented the standard into their platforms. After more than two years of public implementation and internal study, Google security architects have declared Security Keys their preferred form of two-factor authentication. The architects based their assessment on the ease of using and deploying keys, the security it provided against phishing and other types of password attacks, and the lack of privacy trade-offs that accompany some other forms of two-factor authentication."

The researchers wrote in a recently published report: "We have shipped support for Security Keys in the Chrome browser, have deployed it within Google's internal sign-in system, and have enabled Security Keys as an available second factor in Google's Web services. In this work, we demonstrate that Security Keys lead to both an increased level of security and user satisfaction as well as cheaper support cost."

An anonymous reader writes: The entire Steam domain seems to be down for everyone. The websites and Steam clients won't connect. No word from Steam on Twitter or Reddit about the outage. The status page of Steam as well as third-party monitoring sites have confirmed the outage. A tweet from an unofficial Steam Status page says, "100% of #Steam connection manager servers are still down."

Wikipedia has revealed its most edited articles of 2016. Believe it or not, the two most edited articles of the year were for Deaths in 2016, which was edited 18,230 times, and Donald Trump, with 8,933 edits as of December 21. NPR reports: Some are completely unsurprising -- like the articles about Brexit, the Panama Papers, the Orlando nightclub shooting, and other recent and controversial news topics. The popularity of editing others is somewhat more mysterious: like the article for RuPaul's Drag Race, and one for a fictional character named Beverley Gray -- the subject of a series of 26 mystery stories written between 1934 and 1955. The article on Vincent Van Gogh was also edited thousands of times in 2016, as editors reportedly sought to clarify misunderstandings about the artist in hopes of achieving "featured" status for the page. The most edited article by far was for Deaths in 2016, which was edited 18,230 times. David Bowie, Janet Reno, Gwen Ifill, Leonard Cohen, Fidel Castro, Muhammad Ali, John Glenn and Prince are among the notable people who died this year. Donald Trump's entry was second, with 8,933 edits as of Dec. 21. If history is any indication, there's a good chance the president-elect's Wikipedia page will come under even more scrutiny: The Wikimedia Foundation revealed earlier this year that George W Bush's article has the most edits of any article in English in the history of the site, with 45,862 revisions at last count.

Wikipedia has revealed its most edited articles of 2016. Believe it or not, the two most edited articles of the year were for Deaths in 2016, which was edited 18,230 times, and Donald Trump, with 8,933 edits as of December 21. NPR reports: Some are completely unsurprising -- like the articles about Brexit, the Panama Papers, the Orlando nightclub shooting, and other recent and controversial news topics. The popularity of editing others is somewhat more mysterious: like the article for RuPaul's Drag Race, and one for a fictional character named Beverley Gray -- the subject of a series of 26 mystery stories written between 1934 and 1955. The article on Vincent Van Gogh was also edited thousands of times in 2016, as editors reportedly sought to clarify misunderstandings about the artist in hopes of achieving "featured" status for the page. The most edited article by far was for Deaths in 2016, which was edited 18,230 times. David Bowie, Janet Reno, Gwen Ifill, Leonard Cohen, Fidel Castro, Muhammad Ali, John Glenn and Prince are among the notable people who died this year. Donald Trump's entry was second, with 8,933 edits as of Dec. 21. If history is any indication, there's a good chance the president-elect's Wikipedia page will come under even more scrutiny: The Wikimedia Foundation revealed earlier this year that George W Bush's article has the most edits of any article in English in the history of the site, with 45,862 revisions at last count.

Wikipedia has revealed its most edited articles of 2016. Believe it or not, the two most edited articles of the year were for Deaths in 2016, which was edited 18,230 times, and Donald Trump, with 8,933 edits as of December 21. NPR reports: Some are completely unsurprising -- like the articles about Brexit, the Panama Papers, the Orlando nightclub shooting, and other recent and controversial news topics. The popularity of editing others is somewhat more mysterious: like the article for RuPaul's Drag Race, and one for a fictional character named Beverley Gray -- the subject of a series of 26 mystery stories written between 1934 and 1955. The article on Vincent Van Gogh was also edited thousands of times in 2016, as editors reportedly sought to clarify misunderstandings about the artist in hopes of achieving "featured" status for the page. The most edited article by far was for Deaths in 2016, which was edited 18,230 times. David Bowie, Janet Reno, Gwen Ifill, Leonard Cohen, Fidel Castro, Muhammad Ali, John Glenn and Prince are among the notable people who died this year. Donald Trump's entry was second, with 8,933 edits as of Dec. 21. If history is any indication, there's a good chance the president-elect's Wikipedia page will come under even more scrutiny: The Wikimedia Foundation revealed earlier this year that George W Bush's article has the most edits of any article in English in the history of the site, with 45,862 revisions at last count.

Wikipedia has revealed its most edited articles of 2016. Believe it or not, the two most edited articles of the year were for Deaths in 2016, which was edited 18,230 times, and Donald Trump, with 8,933 edits as of December 21. NPR reports: Some are completely unsurprising -- like the articles about Brexit, the Panama Papers, the Orlando nightclub shooting, and other recent and controversial news topics. The popularity of editing others is somewhat more mysterious: like the article for RuPaul's Drag Race, and one for a fictional character named Beverley Gray -- the subject of a series of 26 mystery stories written between 1934 and 1955. The article on Vincent Van Gogh was also edited thousands of times in 2016, as editors reportedly sought to clarify misunderstandings about the artist in hopes of achieving "featured" status for the page. The most edited article by far was for Deaths in 2016, which was edited 18,230 times. David Bowie, Janet Reno, Gwen Ifill, Leonard Cohen, Fidel Castro, Muhammad Ali, John Glenn and Prince are among the notable people who died this year. Donald Trump's entry was second, with 8,933 edits as of Dec. 21. If history is any indication, there's a good chance the president-elect's Wikipedia page will come under even more scrutiny: The Wikimedia Foundation revealed earlier this year that George W Bush's article has the most edits of any article in English in the history of the site, with 45,862 revisions at last count.

Wikipedia has revealed its most edited articles of 2016. Believe it or not, the two most edited articles of the year were for Deaths in 2016, which was edited 18,230 times, and Donald Trump, with 8,933 edits as of December 21. NPR reports: Some are completely unsurprising -- like the articles about Brexit, the Panama Papers, the Orlando nightclub shooting, and other recent and controversial news topics. The popularity of editing others is somewhat more mysterious: like the article for RuPaul's Drag Race, and one for a fictional character named Beverley Gray -- the subject of a series of 26 mystery stories written between 1934 and 1955. The article on Vincent Van Gogh was also edited thousands of times in 2016, as editors reportedly sought to clarify misunderstandings about the artist in hopes of achieving "featured" status for the page. The most edited article by far was for Deaths in 2016, which was edited 18,230 times. David Bowie, Janet Reno, Gwen Ifill, Leonard Cohen, Fidel Castro, Muhammad Ali, John Glenn and Prince are among the notable people who died this year. Donald Trump's entry was second, with 8,933 edits as of Dec. 21. If history is any indication, there's a good chance the president-elect's Wikipedia page will come under even more scrutiny: The Wikimedia Foundation revealed earlier this year that George W Bush's article has the most edits of any article in English in the history of the site, with 45,862 revisions at last count.

Wikipedia has revealed its most edited articles of 2016. Believe it or not, the two most edited articles of the year were for Deaths in 2016, which was edited 18,230 times, and Donald Trump, with 8,933 edits as of December 21. NPR reports: Some are completely unsurprising -- like the articles about Brexit, the Panama Papers, the Orlando nightclub shooting, and other recent and controversial news topics. The popularity of editing others is somewhat more mysterious: like the article for RuPaul's Drag Race, and one for a fictional character named Beverley Gray -- the subject of a series of 26 mystery stories written between 1934 and 1955. The article on Vincent Van Gogh was also edited thousands of times in 2016, as editors reportedly sought to clarify misunderstandings about the artist in hopes of achieving "featured" status for the page. The most edited article by far was for Deaths in 2016, which was edited 18,230 times. David Bowie, Janet Reno, Gwen Ifill, Leonard Cohen, Fidel Castro, Muhammad Ali, John Glenn and Prince are among the notable people who died this year. Donald Trump's entry was second, with 8,933 edits as of Dec. 21. If history is any indication, there's a good chance the president-elect's Wikipedia page will come under even more scrutiny: The Wikimedia Foundation revealed earlier this year that George W Bush's article has the most edits of any article in English in the history of the site, with 45,862 revisions at last count.

An anonymous reader writes: Last week, WordPress security firm WordFence revealed it detected over 1.65 million brute-force attacks originating from an ISP in Ukraine that generated more malicious traffic than GoDaddy, OVH, and Rostelecom, put together. A week later, after news of WordFence's findings came to light, Ukrainian users have tracked down the ISP to a company called SKS-Lugan in the city of Alchevs'k, in an area controlled by pro-Russian forces in eastern Ukraine. All clues point to the fact that the ISP's owners are using the chaos created by the Russian military intervention in Ukraine to host cyber-crime operations on their servers. Some of the criminal activities the ISP hosts, besides servers for launching brute-force attacks, include command-and-control servers for the Locky ransomware, [email, comment, and forum] spam botnets, illegal streaming sites, DDoS stressers, carding sites, several banking trojans (Vawtrack, Tinba), and infostealers (Pony, Neurevt). UPDATE 12/22/16: The headline and summary have been updated to reflect the fact that Ukraine is fighting a Russian invasion, and is not in a "civil war," as mentioned in the source.

An anonymous reader quotes a report from ABC News: The Obama administration has failed to renegotiate portions of an international arms control arrangement to make it easier to export tools related to hacking and surveillance software -- technologies that can be exploited by bad actors, but are also used to secure computer networks. The rare U.S. move to push for revisions to a 2013 rule was derailed earlier this month at an annual meeting in Vienna, where officials from 41 countries that signed onto it were meeting. That leaves it up to President-elect Donald Trump's administration whether the U.S. will seek revisions again next year. U.S. officials had wanted more precise language to control the spread of such hacking tools without the unintended negative consequences for national cybersecurity and research that industry groups and lawmakers have complained about for months. Critics have argued that the current language, while well meaning, broadly sweeps up research tools and technologies used to create or otherwise support hacking and surveillance software. As one of those 41 member countries of the 1996 Wassenaar Arrangement, which governs the highly technical world of export controls for arms and certain technologies, the United States agreed to restrict tools related to cyber "intrusion software" that could fall into the hands of repressive regimes. The voluntary arrangement relies on unanimous agreement to abide by its rules on export controls for hundreds of items, including arms such as tanks or military aircraft and "dual-use" technologies such as advanced radar that can be used for both peaceful and military means.

EzInKy writes: The BBC and others are reporting the results of a study that women's brains do in fact change during pregnancy. BBC reports: "Pregnancy reduces grey matter in specific parts of a woman's brain, helping her bond with her baby and prepare for the demands of motherhood. Scans of 25 first-time mums showed these structural brain changes lasted for at least two years after giving birth. European researchers said the scale of brain changes during pregnancy were akin to those seen during adolescence. But they found no evidence of women's memory deteriorating. This study, from researchers at the Universitat Autonoma de Barcelona and Leiden University and published in Nature Neuroscience, looked at the brain scans of women before they became pregnant, soon after they gave birth, and two years later, to see how the brain changed. And they compared these women's brains with those of 19 first-time fathers, 17 men without children and 20 women who had never given birth. The researchers found 'substantial' reductions in the volume of grey matter in the brains of first-time mothers. The grey matter changes occurred in areas of the brain involved in social interactions used for attributing thoughts and feelings to other people -- known as 'theory-of-mind' tasks. The researchers thought this would give new mothers an advantage in various ways - help them recognize the needs of their child, be more aware of potential social threats and become more attached to their baby." Thanks Mom! As for first-time fathers, the researchers found no changes in their grey matter.

An anonymous reader quotes a report from ZDNet: People buying new computers and devices in South Carolina would be blocked from accessing porn under a newly proposed law. A bill, pre-filed earlier this month by state lawmaker Bill Chumley, is called the Human Trafficking Prevention Act, and would require computer makers and sellers to install filters that would prevent users from accessing porn and other sexual material. The aim is to prevent access to sites that facilitate prostitution and trafficking, Chumley told a local newspaper this weekend, which the state has struggled to curtail in recent years. "If we could have manufacturers install filters that would be shipped to South Carolina, then anything that children have access on for pornography would be blocked," Chumley reportedly said. "We felt like that would be another way to fight human trafficking."

Reader Andreas Kolbe writes: The fundraising banners on Wikipedia this year are so effective that halfway through its December fundraising campaign, the Wikimedia Foundation has already exceeded its $25 million donations target for the entire month, reports The Register. A few weeks ago, Jimmy Wales promised that the Wikimedia Foundation would "stop the fundraiser if enough money were raised in shorter than the planned time". But there's no sign of the Foundation doing that. When asked about this more recently, a Wikimedia Foundation spokesperson remained non-committal on ending the campaign early. The most recent audited accounts of the Wikimedia Foundation showed net assets of $92 million and revenue of $82 million. None of this money, incidentally, pays for writing or checking Wikipedia content – that's the job of unpaid volunteers – and only $2 million are spent on internet hosting every year.

An anonymous reader writes: It's the year of the Linux desktop getting pwned. Chris Evans (not the red white and blue one) has released a number of linux zero day exploits, the most recent of which employs specially crafted audio files to compromise linux desktop machines. Ars Technica reports: "'I like to prove that vulnerabilities are not just theoretical -- that they are actually exploitable to cause real problems,' Evans told Ars when explaining why he developed -- and released -- an exploit for fully patched systems. 'Unfortunately, there's still the occasional vulnerability disclosure that is met with skepticism about exploitability. I'm helping to stamp that out.' Like Evans' previous Linux zero-day, the proof-of-concept attacks released Tuesday exploit a memory-corruption vulnerability closely tied to GStreamer, a media framework that by default ships with many mainstream Linux distributions. This time, the exploit takes aim at a flaw in a software library alternately known as Game Music Emu and libgme, which is used to emulate music from game consoles. The two audio files are encoded in the SPC music format used in the Super Nintendo Entertainment System console from the 1990s. Both take aim at a heap overflow bug contained in code that emulates the console's Sony SPC700 processor. By changing the .spc extension to .flac and .mp3, GSteamer and Game Music Emu automatically open them."

An anonymous reader writes: It's the year of the Linux desktop getting pwned. Chris Evans (not the red white and blue one) has released a number of linux zero day exploits, the most recent of which employs specially crafted audio files to compromise linux desktop machines. Ars Technica reports: "'I like to prove that vulnerabilities are not just theoretical -- that they are actually exploitable to cause real problems,' Evans told Ars when explaining why he developed -- and released -- an exploit for fully patched systems. 'Unfortunately, there's still the occasional vulnerability disclosure that is met with skepticism about exploitability. I'm helping to stamp that out.' Like Evans' previous Linux zero-day, the proof-of-concept attacks released Tuesday exploit a memory-corruption vulnerability closely tied to GStreamer, a media framework that by default ships with many mainstream Linux distributions. This time, the exploit takes aim at a flaw in a software library alternately known as Game Music Emu and libgme, which is used to emulate music from game consoles. The two audio files are encoded in the SPC music format used in the Super Nintendo Entertainment System console from the 1990s. Both take aim at a heap overflow bug contained in code that emulates the console's Sony SPC700 processor. By changing the .spc extension to .flac and .mp3, GSteamer and Game Music Emu automatically open them."

An anonymous reader writes: It's the year of the Linux desktop getting pwned. Chris Evans (not the red white and blue one) has released a number of linux zero day exploits, the most recent of which employs specially crafted audio files to compromise linux desktop machines. Ars Technica reports: "'I like to prove that vulnerabilities are not just theoretical -- that they are actually exploitable to cause real problems,' Evans told Ars when explaining why he developed -- and released -- an exploit for fully patched systems. 'Unfortunately, there's still the occasional vulnerability disclosure that is met with skepticism about exploitability. I'm helping to stamp that out.' Like Evans' previous Linux zero-day, the proof-of-concept attacks released Tuesday exploit a memory-corruption vulnerability closely tied to GStreamer, a media framework that by default ships with many mainstream Linux distributions. This time, the exploit takes aim at a flaw in a software library alternately known as Game Music Emu and libgme, which is used to emulate music from game consoles. The two audio files are encoded in the SPC music format used in the Super Nintendo Entertainment System console from the 1990s. Both take aim at a heap overflow bug contained in code that emulates the console's Sony SPC700 processor. By changing the .spc extension to .flac and .mp3, GSteamer and Game Music Emu automatically open them."