Slashdot Mirror


Why Apple and Google Made Their Own Programming Languages

Gamoid writes: This Business Insider article looks into the state of Google Go and Apple Swift, highlighting what the two languages have in common — and why tech companies would bother involving themselves in the programming language holy wars. From the article: "One fringe benefit for Google and Apple is that making your own programming language makes recruitment easier — for instance, since it builds a lot of its own server applications in Go, Google is more likely to hire a developer who's already proficient in the language since she would need less training."

48 of 260 comments (clear)

  1. Re:That last sentence makes no sense by should_be_linear · · Score: 4, Funny

    That sentence is actually valid in Brainfuck language.

    --
    839*929
  2. BI == Business Idiots by sribe · · Score: 4, Insightful

    Really. That last sentence proves it. They have no fucking idea what different languages are good for, or not.

    1. Re:BI == Business Idiots by TheRaven64 · · Score: 5, Interesting

      Right. Apple created Swift because Objective-C was a nice language for the requirements of '90s computing, but is starting to be limited by its C heritage. They needed a more modern language that interoperates very well with Objective-C (because they have a lot of legacy Objective-C code that isn't going away any time soon) and this required making a new language because there weren't any good contenders available. MacRuby is the closest, but falls short in a number of areas.

      Google didn't create Go as the result of some corporate masterplan, a small team at Google created it and managed to get buy-in from some other groups at Google. It's still far from the most widely used language for new projects inside Google, but it does have some advantages (though is slightly let down by Rob Pike's refusal to accept that some people who are not Rob Pike have had good ideas in the last 30 years).

      The recruiting thing can't really work. It would only really make sense if people would learn a cool language and then discover that there are very few places where they can work and use it. This is sort-of true for something like Erlang or Smalltalk, but Swift is fairly widely used by people developing for iOS and OS X (and would probably not be worth Apple's effort in developing it if it weren't). If the language is successful enough that enough people are learning it to significantly affect the pool of potential applicants for a company the size of Apple or Google, then enough other companies are likely to be using it that it isn't a significant benefit.

      --
      I am TheRaven on Soylent News
    2. Re: BI == Business Idiots by Aighearach · · Score: 2

      If you're targeting C++/Java developers with a new language, then if you're successful you do indeed get less interest over time from that group. Those who agreed left and joined you; those that stayed will like your offering less than average; the remaining non-converts become less receptive to you over time. This is true even assuming nobody ever changes their opinion; they either liked the new thing when they saw it, or not.

      The case where interest "increases" is where they are saying, "awwww, how cute... but don't expect me to use it." They don't hate it, they're willing to talk reasonably about the shortcomings, but they're also probably never go to use it seriously. These people can be persuaded to agree it is less bad after making changes to be more like them, but they're not going to actually switch anyways.

      You don't do much better on your technical complaints. Are exceptions a thing that is the same between languages now? No? No. The semantics are often quite different. You can't just assume it works the same in a new language as the old one. It is not predictable based on the naming. You have re-learn and memorize the semantics for every language. Naming a new set of semantics something different, that isn't already overloaded, increases jargon quality within their language, both for new people, and for people who use multiple languages. And it doesn't change the amount you have to learn; the familiar language doesn't mean you can skip parts because you know how it works in another language.

      As for user-defined types, that is a specific feature that has advantages and disadvantages either way. There are real reasons to make the choices they did for the niche their language intends to serve. You don't attempt to make any case that their choice is somehow undesirable for that niche.

      You really seem to not understand coding practices. Things like DRY, as an old-timer I can say yeah, I don't understand it either. We already had the teaching that code re-use is good. DRY just seems to take the lesson, adopt a pithy cliche phrasing of it, and then throw out the actual lessons and substitute a rule of thumb. Do you always want to avoid repetition? No, only the vast majority of the time. There are times when it is bad. How would a youngster who only grew up with DRY reconcile that? There is no provision in the way it is taught to determine when it is applicable. Easy to remember, sure. But if you can't remember you want to maximize code re-use, cliches aren't going to save you. The only way to use these sorts of modern ideas is to ignore them whenever they don't look useful, which actually means you can ignore them before you start, and just follow traditional best practices instead. Those will lead you to ask how much code re-use you want, and then implement it. Usually that prevent repetition, except where it wasn't desired. ;)

    3. Re: BI == Business Idiots by Anonymous Coward · · Score: 3, Interesting

      Pike being a dick about what GO is, is analogous to Torvalds being the kernels gate keeper.

      And if Pike had the general credibility and design sense of Torvalds then there'd be no issue, of course. In fairness, Torvalds' job is easier because cloning a UNIX kernel is the least interesting design space imaginable: you just do what was done before, but better. Designing a new language is harder.

      Still, the problem remains, that Pike is no Torvalds. Yes he did some good stuff a long time ago. But Go sucks.

      Go sucks because (in no real order)

      1. There is no debugger that is worth a damn. GDB is barely functional. Pike's view is that this is unlikely to ever change because gdb would need to understand the Go runtime and the Go guys don't seem to be building their own debugger.

      2. The compiler is only fast because it doesn't do a lot of things modern compilers are expected to do.

      3. You can't write generic code, but because this is such a stupid limitation, the built in functions are generic. So you can write them as long as you are Rob Pike, essentially.

      4. Go code doesn't use exceptions. It uses error codes instead. This makes lots of code into a giant clusterfuck of "if err != nil" type checks that nest horribly, are incredibly verbose, are easy to miss out and which destroy any chance of getting useful stack traces when something goes wrong.

      5. Go does not seem to know who it is for. Pike has claimed Google needs it because Googlers are idiots who "are not capable of understanding a brilliant language". No shit he really said this - I guess that didn't do much for his popularity inside the googleplex. Originally he said it was a "systems language" and then tried to retcon it as "by systems we mean web servers at Google", a definition of systems that nobody else uses.

      6. Go has no versioning system: you import packages by referring to github paths and it just grabs whatever is at git master (ya rly)

      7. CPU profiling is a joke. It doesn't work at all on MacOS.

      8. It's basically reinventing Java and the JVM but very slowly, and whilst loudly proclaiming it's totes different because static linking! Except now they're adding dynamic linking too.

      9. The GC is a decade or so behind the cutting edge

      10. The Go Gopher is creepy

    4. Re: BI == Business Idiots by zbobet2012 · · Score: 3
      Man how did an AC manage to get this posted upvoted?

      1. There is a custom debugger for go: https://github.com/derekparker.... Also worrying this much about debuggers is kind of sad, what will happen when you literally can't use one or it doesn't help? Oh you have never done embedded or distributed work I see.

      2. Nope (also [citation needed]). The go compiler is fast because it doesn't use modules/header files. See the C++ working group on the subject to understand why it is so slow: http://llvm.org/devmtg/2012-11...

      3. "Built in functions". The built in "generics" are not functions, they are data types. And no you probably don't need them.

      4. I'm sorry you don't catch your exceptions. Your coworkers are too.

      5. A definition of systems that tons of people use.

      6. Godeps. Or like 30 other ones. Java and C++ don't come with a version system either, but you probably assumed Maven was part of the core. 7. Guys CPU profiling for a server side language doesn't work on OSX (except it does).

      8. Go doesn't have a virtual (byte code interpreted) runtime, so its nothing like the JVM. And yes every language has a runtime. I mean literally what?

      9. Nothing of value here folks.

      10. Or here.

      There are things wrong with Go, but none of these are them. In fact this post shows such a stunning lack of understanding about programming languages it worries me.

    5. Re: BI == Business Idiots by OrangeTide · · Score: 2, Insightful

      There are things wrong with Go, but none of these are them. In fact this post shows such a stunning lack of understanding about programming languages it worries me.

      Sadly, this is typical in the industry.

      I'm a C kernel guy who has to wrestle with a lot of application developers who assume I don't know anything about "the cutting edge" because C lacks pretty much every feature they claim to depend upon.

      I embraced Go recently, but I got there through Erlang. so my idea on what it's really good at and how to use it is going to be different than someone who is trying to use Go as a replacement for Java or Python.

      --
      “Common sense is not so common.” — Voltaire
  3. Re:Huh? by istartedi · · Score: 5, Insightful

    It weeds out the people who aren't fan-boy enough to become proficient in your proprietary language before you even interview them. TFA cites a lot of other reasons they wrote these languages. This one got crab-apple picked for some reason.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
  4. Re:Multiplatform is king - and Go is multiplatform by ncw · · Score: 5, Informative

    From wikipedia

    Go's "gc" compiler targets the Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD, Plan 9, and Microsoft Windows operating systems and the i386, amd64, ARM and IBM POWER processor architectures/ A second compiler, gccgo, is a GCC frontend.

    So there are two major compilers for Go already, one of which is gcc based which targets just about every platform under the sun. I'm not saying go will run everywhere gcc will compile code because the runtime also needs porting, but it is very cross platform.

    I developed one of my command line apps in Go http://rclone.org/ and I release binaries for it which run on Windows, OS X, Linux, *BSD and even Plan 9 all cross compiled from my Linux workstation.

    --
    Every man for himself, all in favour say "I"
  5. Review of TFA by Matchstick · · Score: 4, Insightful

    This is a bad article; and the submitter, editor, and readers should all feel bad.

  6. Because no one else does by Alomex · · Score: 4, Interesting

    The reason why companies develop new languages is because the ones coming from academia are focused on the wrong things. Product development requires an industrial strength, strongly typed (for the most part) fast language.

    Projects coming from academia are interpreted, JVM based, functional, obsessed with (im)mutability, closures, and lambda functions.

    This is not to say those things are not nice, however they are not central to a programming language as used in large scale industrial systems.

    1. Re:Because no one else does by Wrath0fb0b · · Score: 2

      Closures and lambdas are definitely compatible with strongly typed performant code. C++11 has both and is still very performant (std::function is lightweight enough to toss around, doubly so with reference/move semantics) and as an added bonus with C++14's "auto-goes-everywhere" you get output that's strongly typed without the hassle of naming it. Purists can still opt to explicitly type everything if they prefer of course.

      Similarly, Apple's block extension to C has all of those and is still reasonably performant. Their implementation is a bit slower (all variables captured are ref-counted on the heap) but still very reasonable. Function-objects themselves need to be manually managed/copied around, but that's the legacy of C shining through...

      Totally agree about VMs and the obsession with functional languages though :-)

    2. Re:Because no one else does by radish · · Score: 4, Interesting

      As someone who works on such large scale systems, I disagree. When you need to deal with extremely high concurrency the functional paradigm with immutable structures is a really nice way to reason about problems - I'd say it contributes significantly to reliability over standard threaded imperative code.

      "Fast" is such a vague term as to be meaningless - but I can say that we typically hit the performance limits of something external (network, disk, DB) before the fact that we're in a JVM makes any difference. If your problem is purely compute then maybe it's worth looking at C or golang, but the vast majority of stuff I work on is network services, and compute is not the bottleneck.

      I do 100% agree with the strongly typed bit though :)

      --

      ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

    3. Re:Because no one else does by IamTheRealMike · · Score: 2

      The reason why companies develop new languages is because the ones coming from academia are focused on the wrong things. Product development requires an industrial strength, strongly typed (for the most part) fast language.

      Projects coming from academia are interpreted, JVM based, functional, obsessed with (im)mutability, closures, and lambda functions

      Whilst I don't disagree that academic languages rarely get used directly in industry, one of the world's most successful industrial programming languages is Java, and Java is interpreted, JVM based, and in version 8 got things like functional streams and lambda functions. Still no help with immutability, but value types will partly address that.

      So choosing these features as examples of stuff that's irrelevant to large scale industrial systems seems particularly perverse.

    4. Re:Because no one else does by Daniel+Hoffmann · · Score: 2

      immutability makes me more productive when dealing with concurrent code because I don't need to keep track of any locks on data structures. Anonymous functions make me more productive because I don't need to keep track of a bunch of names for things that I will use only once.

      Really any time I need to "keep track" of something it is draining attention that could be focused on solving the problem instead. The less stuff the language makes me need to remember the better, garbage collection allows me to not keep track of deallocating memory for a comparison. Surely needing to name anonymous functions is a less blatant example compared to deallocating memory but it is the same problem.

    5. Re:Because no one else does by thsths · · Score: 2

      > were you seriously being held back by having to name the function before passing it on as a parameter?

      The point of Lambda-functions is not to avoid a name, but to include the function definition inline in another function call. it makes much shorter code that is much easier to read.

  7. Re:Clueless by vux984 · · Score: 2

    Its not even logical. If the goal is to hire developers who need the least language training, having your own in-house language is the worst way to go. Clearly google and apple should pick the most popular language if that's what they want.

    On the other hand, an in house language probably reduces developer mobility -- they can't go to work for another company if they don't work with common languages.

  8. Re:Dumb argument by TheRaven64 · · Score: 4, Insightful

    Add to that, Go and Swift are pretty small languages. Learning either is something that a moderately competent programmer ought to be able to do in a few weeks. Neither is sufficiently different to other languages that there's a big cognitive jump. The difficult thing is always learning new libraries and frameworks, not learning a new language (well, unless the new language is C++, where after a decade of daily use developers are still not surprised to come across a language feature that they've never seen before).

    --
    I am TheRaven on Soylent News
  9. better language? by Anonymous Coward · · Score: 5, Insightful

    is it really impossible for anyone to believe that a language and toolchain can actually
    make an organization more productive?

    it seems like everyone is so lost in technical marketing that they've forgotten
    about actually programming computers

  10. Re:Huh? by Grishnakh · · Score: 4, Insightful

    Exactly, this doesn't make sense at all for recruiting, it's actually backwards: using your own programming language makes it far more difficult to recruit, because very few people from outside your organization will have any expertise in the language.

  11. Re:Multiplatform is king - and Go is multiplatform by Grishnakh · · Score: 3, Insightful

    It doesn't matter how many platforms Go compiles for; what matters is how much demand there is for Go programmers. Outside of Google, the answer is approximately zero, so it's a bad choice if you're worried about your continuing employability. C++, on the other hand, is used all over the place, so it's a very safe bet.

  12. Re:That last sentence makes no sense by jcr · · Score: 5, Informative

    Anyone who is proficient in Swift has hundreds or thousands of companies outside of Apple looking to hire them. Apple has to compete with every iOS software development shop in the world for those people.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  13. Re:Multiplatform is king by ATMAvatar · · Score: 2

    I hope they guan get visual studio working on other platforms

    To that end, you could try out Visual Studio Code, which was introduced at the build conference this year.

    --
    "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
  14. Typical Business Insider Conspiracy Theory. by engineerErrant · · Score: 2

    The makers of this article clearly have no background in computing, or journalism either for that matter. I'm surprised I didn't see a reference to the Illuminati in there somewhere. Bizarrely, the article doesn't even mention Dart, which is no doubt due to the two-minute Bing search that I'd imagine formed the entirety of their background research.

    When considered against the status quo for their purposes and eras, all of these languages show significant, useful advances in programming. And if we're going to declare all languages that are created by a for-profit corporation invalid, say goodbye to Java, C#, C++, and C. Hell, even the Jacquard Loom was meant to make money.

  15. Re:Multiplatform is king - and Go is multiplatform by Anonymous Coward · · Score: 2, Interesting

    It took me less than a week to learn go. I still don't know all of C++ after two years. Learning Go was not a bad investment: the perspective I learned from it helped me write better C++ and C# code from both a OOP design perspective and threading perspectives, and is also a nice thing for my resume (Maybe is helped me get my option to work for Google, I don't know).

  16. Not recruitment, retention by John+Jorsett · · Score: 3, Insightful

    If you've made your own language, you're more likely to keep your experienced employees because there are fewer places for them to go to if they jump ship. Sure, there will be companies that use the language because they have to develop software for Google or Apple, but the employees are going to be a lot more locked-in than if they were experienced in something more widely used such as C or Python.

    1. Re:Not recruitment, retention by UnknowingFool · · Score: 3, Insightful

      As someone pointed out, that doesn't make sense for retention as Swift is the language that most 3rd party iOS app developers will learn. Apple makes maybe a dozen iOS apps and half of them are free. As for OS X, I can see the same pattern; third party developers are going to outnumber Apple ones.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
  17. There is a minor recruiting benefit, only to "go". by tlambert · · Score: 3, Insightful

    There is a minor recruiting benefit, only to "go".

    WHY SWIFT IS NOT BENEFICIAL:

    Internally, Apple doesn't write a lot of Apps; they might, eventually, convert some of their existing large applications, like Pages or Mail.App, over to Swift; these will largely end up being rewrites. So while knowing Swift might make you better able to get a job at a software house targeting Apple's platforms, it's unlikely to be meaningful in getting a job at Apple.

    On the other hand, one benefit to Apple is that if Swift is not strongly used internally, the demand for App developers is unlikely to hire away Apple engineers out from under Apple, which was a big issue with the Objective C "brain drain" when iPhone and other apps took off. One of the things that Apple did, for example, was not let registered developers who were also Apple employees, take App programming classes held by Apple, for a period of six months after they started offering them to non-Apple employees. So there is an "anti-recruiting away of Apple employees" benefit to Apple.

    WHY GO IS BENEFICIAL:

    The recruiting benefit of "go" is clearer, although even with gccgo, go is not very portable to non-Linux platforms, despite its claimed platform support (for example, the standard libraries *still* have some serious compatibility issues on Mac OS X, despite the fact that almost every Google employee has an Apple laptop).

    One thing that companies like to hire is young people; on the theory that "you can't teach an old dog new tricks", someone who knows "go" is a lot more likely to be younger, rather than older. It's not valid due to the theory, but it is nevertheless valid enough that you can pretty much use it as something of an age filter, and legally get away with doing do.

    Another thing it means is that you're willing to learn new things; a surprising number of people aren't. If you got into software engineering for the money, and you are just using it as a "paycheck continuation program", instead of actually being passionate about it, it's unlikely that you've bothered to take the time to learn "go".

    These are relatively minor benefits, since it doesn't take that long to learn a new language well enough to work in it pretty extensively; so training is not really a benefit, as the article claims.

  18. Re:Huh? by istartedi · · Score: 4, Insightful

    But they don't have a shortage of applicants. They actually want to narrow the field. If that were not the case, Google wouldn't have had (perhaps they still do) such a notoriously difficult interview process.

    Economies of scale are critical here. Only a handful of companies are that big, and that desirable as places to work. So for these behemoths the usual logic is inverted. For them, narrowing the field really does "help recruitment"--the semantics of that phrase are inverted when dealing with relativistic money.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
  19. Re:Huh? by MillionthMonkey · · Score: 4, Insightful

    OTOH, it's easier to retain employees who only know "your" language.

  20. Logic Fail by Art3x · · Score: 3, Insightful
    From the article:

    One fringe benefit for Google and Apple is that making your own programming language makes recruitment easier --- for instance, since it builds a lot of its own server applications in Go, Google is more likely to hire a developer who's already proficient in the language since she would need less training.

    And had Google used C, it would be more likely to hire someone who's good with C, since they would need less training.

  21. Re:Fringe benefit by Jeremi · · Score: 3, Informative

    Of course, C# has a much larger ecosystem, which is also kind of the point.

    Of course, C# is also Microsoft's baby, which is enough to disqualify it from use inside Apple and Google all by itself. Nobody at either of those companies is going to risk relying on Microsoft's intellectual property for anything mission-critical.

    --


    I don't care if it's 90,000 hectares. That lake was not my doing.
  22. How stupid is this argument... by kenh · · Score: 3, Insightful

    "One fringe benefit for Google and Apple is that making your own programming language makes recruitment easier â" for instance, since it builds a lot of its own server applications in Go, Google is more likely to hire a developer who's already proficient in the language since she would need less training."

    Because if they used, for example, Java, when they hired an experienced Java developer they would need MORE training?

    Approximately how large is the pool of 'experienced' Go/Swift programmers outside of Google/Apple?

    --
    Ken
  23. Re:That last sentence makes no sense by Applehu+Akbar · · Score: 3, Informative

    "I'm still scratching my head over the use of "she" instead of "they" in that sentence."

    It's Corpspeak. You have to use a precisely equal number of male and female pronouns, even when that means shifting gender confusingly back and forth throughout your Powerpoint presentation. But if your presentation contains a example of bad procedure, you have to use a male pronoun at that point ("If the nurse were to stick his finger in the 220V socket during Step 5...")

  24. Re:Multiplatform is king - and Go is multiplatform by gbjbaanb · · Score: 3, Insightful

    He means "I tinkered with this new thing and it seemed pretty easy enough, so that was enough - I never needed to use it, so I never found out all the edge cases I know about in the mainstream languages I use every day".

    Its why many people like new languages and things, they think they're simple because they only have to scratch the surface for some simple example and think that's all there is to it.

  25. Re:Multiplatform is king - and Go is multiplatform by west · · Score: 2

    I'd define 'learn' as be able to read 90% of the code that's out there. And yes, I can easily see C++ taking years by that standard.

    "Yes, our code *does* overload the 'space' character, I thought you said you knew C++!" :-).

  26. Re:That last sentence makes no sense by Applehu+Akbar · · Score: 3, Funny

    Welcome! We're always glad to see representatives of HR visit us on Slashdot. Next week as you write a requirement for five years of Swift into that new job posting, you can thank us for having inspired you in your quest for offense-free skill categories.

  27. Re:That last sentence makes no sense by Anonymous Coward · · Score: 4, Informative

    Masculine pronouns can be used in the gender neutral sense in English. Feminine pronouns cannot. Posting as AC because I don't want saying obvious fucking truths archived on my slashdot account, thanks to the witch hunts political shitfucks will inevitably engage in.

  28. Re:Multiplatform is king - and Go is multiplatform by Anonymous Coward · · Score: 2, Informative

    He means "I tinkered with this new thing and it seemed pretty easy enough, so that was enough - I never needed to use it, so I never found out all the edge cases I know about in the mainstream languages I use every day".

    No, that's not what I meant. After spending a week learning Go, I wrote a couple of applications in it, but after the first week I was not learning Go, I was learning libraries and patterns.

    Read the Go spec: these is almost nothing to it. The language has ridiculously few features. The main design goal of the language was to make code very readable and maintainable which means all devs basically know the entire language spec.

    Don't read the C++ spec. You don't have time for that and it keeps growing. C++ has lots of features, which is both a good and a bad thing, but not all languages are like that.

  29. Re: Huh? by Anonymous Coward · · Score: 5, Insightful

    Plenty. All of your criteria have little to do with the language and much more to do with the developer. Any properly defined/debugged program is "safe". Any properly optimized program is "performant". "Clear" is just about source code, which means that it's entirely up to the developer.

    ISO 9899:2011.
    ISO 14882:2014E.
    ECMA 334.

    Swift is a "lookalike" to all of these in several ways, especially as that list goes on. The list of languages that aren't ancestral to Swift but that have standards could go on for quite a while longer.

  30. Re: That last sentence makes no sense by Anonymous Coward · · Score: 2, Informative

    Very well, actually. ADA is very good at what it does well, which is creating deterministic code that can be procedurally validated. It was created for a design environment that is the exact, deliberate opposite of Agile. If you think you should build once a day or week, then ADA is not for you. If you can not simulate your live environment because it's a thousand miles up in orbit and a bug costs half a billion dollars and 2 years to the next launch window, ADA is for you. If virtually memory machines are a pointless risk and dynamic memory allocation is anthema, then go for ADA. If not, stay the fuck away, because it will make you a grey beard, one way or another.

  31. Re:Huh? by jrumney · · Score: 3, Insightful

    It reduces the pool of resumes that you have to sort through into just previous employees and liars. Since you know that the previous employees are either no good or have a grudge against the company, you can filter them out and hire the rest for sales.

  32. Re:Huh? by Jeeeb · · Score: 4, Insightful

    Economies of scale are critical here. Only a handful of companies are that big, and that desirable as places to work. So for these behemoths the usual logic is inverted. For them, narrowing the field really does "help recruitment"--the semantics of that phrase are inverted when dealing with relativistic money.

    A filter is only useful though if it removes the bad applicants and leaves the good applicants. Filtering by language (/framework) although common is also a very good way to exclude a significant amount of programming talent on the basis that you don't want to give them a few weeks to get productive in your pet language/framework. I've never interviewed (or applied) at either but both Google and Apple seem to have more farsighted hiring practices than that.

  33. Re:Huh? by Noah+Haders · · Score: 2

    *fewer

  34. I know why Swift exists. by jcr · · Score: 4, Interesting

    ...and it had nothing at all to do with recruitment.

    When Apple came up with the LLVM static analyzer, they became much more aware of just what kind of coding mistakes were costing them the most time and money, and Swift addresses those issues.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  35. Re:That last sentence makes no sense by Livius · · Score: 5, Funny

    Yes, it's very unfair to men that they don't have their own pronouns.

  36. Re:Subtle.. by MechaStreisand · · Score: 2

    Have you not noticed that almost all programmers are men? That means that when you use the word "she", you're saying it only to make a political statement, not because you think it actually describes the situation.

    --
    Disclaimer: IANAL. This post is, however, legal advice, and creates an attorney-client relationship.
  37. Re: Huh? by rjstanford · · Score: 2

    If you won't acknowledge that the language can guide users to make the correct choices then I think you're missing the point. By your definition ASM is safe and clear. Personally I prefer to have projects coded in a language that encourages expressiveness and convention, but that's mainly because most of my time is spent on systems that are designed to live for 15-20 years. Reducing or eliminating maintenance time is more valuable to me than pure wire-level performance. Others may have different trade-offs. You should know your project's goals and choose accordingly.

    --
    You're special forces then? That's great! I just love your olympics!