Slashdot Mirror


Why Apple, Google, and FB Have Their Own Programming Languages

An anonymous reader writes: Scott Rosenberg, author of Dreaming in Code dissects Apple's Swift, Google's Go, and other new languages — why they were created, what makes them different, and what they bring (or not) to programmers. "In very specific ways, both Go and Swift exemplify and embody the essences of the companies that built them: the server farm vs. the personal device; the open Web vs. the App Store; a cross-platform world vs. a company town. Of all the divides that distinguish programming languages—compiled or interpreted? static vs. dynamic variable typing? memory-managed/garbage-collected or not?—these might be the ones that matter most today."

21 of 161 comments (clear)

  1. Naming by Anonymous Coward · · Score: 3, Interesting

    So Apple named a language "Swift", Google named a language "Go", and Facebook named a language "Hack"?
    Obviously it's not just the dirty FLOSS hippies who can't come up with decent software names.

    1. Re:Naming by VGPowerlord · · Score: 5, Funny

      Well, I heard* that the name Go was decided upon when an executive at Google needed to think up a name and was looking around his office.

      On his computer at the time was a Chrome browser with the Google homepage open, but a Solitaire window was open in front of it obscuring the right half the page.

      Now, if the Solitaire window was on the other side, we might have the ogle programming language instead!

      * and by "heard" I mean "just made up"

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    2. Re:Naming by DulcetTone · · Score: 3, Insightful

      Some of these are actually good names, e.g. Swift

      --
      tone
  2. Algorithms by Anonymous Coward · · Score: 5, Interesting

    If I give you an algorithm, throw a dart at a page of programming languages to select one and if you cannot implement that algorithm in that language then you are nothing but a code monkey.

    A computer scientist can implement any algorithm in any language.

    Why are these companies using their own languages?

    Coder lockin. That is the only reason to have your own language.

    Work a few years at XYZ company working on their proprietary algorithms in their ABC programming language?

    Good luck getting another job.

    See, they learned the hard way with their stuff in Javascript - common language and coders - uh, I mean Javascript engineers - left for greener pastures because so many other companies were using that language.

    1. Re:Algorithms by tlambert · · Score: 5, Interesting

      If I give you an algorithm, throw a dart at a page of programming languages to select one and if you cannot implement that algorithm in that language then you are nothing but a code monkey.

      A computer scientist can implement any algorithm in any language.

      The "D" language used in writing DTrace scripts does not have loop constructs or recursion, and is not Turing complete. While I can do some pretty astonishing things in "D" that would make your jaw drop, even without looping constructs and recursion, it's pretty easy to come up with things which are impossible to implement in "D".

      So I would say your page of programming languages would, at a minimum, need to be Turing complete programming languages.

    2. Re:Algorithms by caseih · · Score: 3, Informative

      And of course this "D" language is not to be confused with the other "D" language, which is Turing complete.

  3. Missing the Point by Capt.Albatross · · Score: 2, Informative

    While Mr Rosenberg claims that Go is distinguished by its approach to concurrency, his section 'The Essence of Go' is almost entirely devoted to the trivia of braces and semicolons. Yo won't learn anything about Go's approach to concurrency here.

  4. NIH by hawguy · · Score: 2

    I assumed it was a case a Not Invented Here Syndrome.

  5. Are these things catching on? by Marginal+Coward · · Score: 2

    Outside of their respective organizations, I'm not sure these things are really catching on. Adoption of Go seems to have come to a standstill. Uptake of Swift has been kindda slow. And Hack seems to been ignored even by dedicated underground computer hobbyists. As well as lumberjacks.

  6. If languages had mascots by ArcadeMan · · Score: 2, Funny

    Then Red Forman would be the mascot for Swift.

    As in, a swift kick in the ass. Dumbass.

  7. Good reasons for Swift and Go by sideslash · · Score: 3, Interesting

    Swift needed to be created because Objective C stinks, and no other modern language would have fit smoothly into the Smalltalkish legacy of the Cocoa framework. I'm just glad that the Apple fanboys who constitute most of my fellow iOS developers are finally allowed to believe bad things about Objective C, at least now that there's a nice alternative. Made me a little sick before to hear people praising Obj-C while writing reams of ridiculously verbose code that nobody will want to maintain 5 years from now.

    Go is a fantastic language for server side development with concurrency that's not painful to wrap your head around, and is perfect for cloud development in Google's world.

    Won't comment on Facebook Hack, since it's not clear to me why Facebook itself needs to exist. But to each their own...

    1. Re:Good reasons for Swift and Go by Anonymous Coward · · Score: 2, Insightful

      Swift needed to be created because Objective C stinks, and no other modern language would have fit smoothly into the Smalltalkish legacy of the Cocoa framework. I'm just glad that the Apple fanboys who constitute most of my fellow iOS developers are finally allowed to believe bad things about Objective C, at least now that there's a nice alternative. Made me a little sick before to hear people praising Obj-C while writing reams of ridiculously verbose code that nobody will want to maintain 5 years from now.
       

      Objective-C is fine. The square brackets syntax just become second nature and disappear into the background after a couple of days. And personally I have no objection to methods with long names - it helps me understand what has been written when I return to a program after months (or a year) away. The long names actually make the code more readable and maintainable. I like Objective-C and have no bad things to say about it or the concepts behind it.

      What Swift does bring is enhancements that I would like to see in Objective-C - for instance return values with tuples. There are other enhancements as well. However, Swift is too new to really say if it will be successful.

    2. Re:Good reasons for Swift and Go by jeremyp · · Score: 2

      The only substantial way of improving on string concatenation in Objective-C would be to introduce custom operators, and that brings its own set of issues. The other alternatives sacrifice consistency.

      Actually, you could quite easily bring custom operators to Objective-C by adopting the Smalltalk approach. Simply allow symbols to be messages e.g.

              [@"foo" stringByAppendingString: @"bar];

      could be written as

              [@"foo" +: @"bar];

      Smalltalk allows you to drop the colon with binary operators so you could even have

            [@"foo" + @"bar];

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
  8. Re:The real conspiracy... by RyuuzakiTetsuya · · Score: 2

    All of Go and Swift's documentation is available as free PDFs.

    --
    Non impediti ratione cogitationus.
  9. Re:The real conspiracy... by sconeu · · Score: 3, Insightful

    I don't think it's really that. I think it's more the divide specified.

    Some of us do NOT like using ebooks for reference manuals. We like having dog-eared tomes with tons of bookmarks or post-it tabs. The ability to flip back and forth between multiple pages in an ad-hoc manner is also useful.

    --
    General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
  10. Domain-Specfic is a more compelling case... by jtara · · Score: 5, Informative

    These all strike me as iffy use cases. What is more compelling is creating a language for some more-specific need. These are generally referred-to as Domain Specific Languages, or DSLs (not to be confused with trying to push high-speed internet over a twisted pair...)

    I designed one and implemented a compiler and interpreter for it in the early 1980's. It's not all that hard. I had had one compiler construction course in college. I used classic tools Yacc/Lex/Prep and wrote it in C.

    The language is (was? haven't followed) called VSL, or Variation Simulation Language.

    The problem was this: in the early 80's auto companies were experimenting with variation simulation. It's simulating the build of complex mechanical assemblies so that the effects of dimensional variations can be analyzed. The technique was developed at Willow Run Labs during WWII, as part of the solution to the awful-quality airplanes they were building for the war. They gathered experts to fix the problem, and they used this technique. At the time, it was done by a room full of woman working Friden mechanical calculators...

    So, in the early 80's there was some Fortran code written by a university professor that ran on a mainframe. I worked for a company that set out to commercialize it. My first task was to port it from the mainframe to IBM PC.

    Two problems: Models were written in Fortran, and then linked against a library. Fortran is painful, for anything. It's especially painful for manipulating representations of 3D objects. And compiling and linking Fortran on a PC was slow! Half-hour builds! And that's just to find you had a syntax error and then rinse and repeat.

    My boss wanted to build a "menu system" that engineers could design in. Keep in mind, we are talking 80's and this was just to be a scrolling text menu. Yes, there were graphics workstations, but this was a new untested product, and nobody was going to pop the $20,000 that they did for, say, finite element workstations. they wanted it to work on a PC so that we could more easily convince the auto companies to try it - make it an easier decision to give it a go.

    He wrote up the menu system, and presented it to us in the conference room. He rolled-out a roll of paper the length of the conference table, and then it hung over both ends! I convinced him that the time for this approach had not yet come.... Sure, point and click on graphics - but he couldn't afford either the time or money for that development. But not that silly long-ass text menu!

    The alternative was VSL. It was specifically-tailored to the task, it had "objects" of a sort - and by this I mean "3D objects". You could just pass a fender around in a function call, for example.

    It didn't compile to machine code, but generated bytecode. I wrote an interpreter in Fortran, and so eliminated the costly link step. The Fortran program just read the bytecode into an array and interpreted it. Was it slow? No, it was fast as heck! That's because almost all the work was done in well-optimized library functions written in Fortran or even assembly in some cases. (I also talked my boss into hiring an actual mathematician who fixed our broken edge cases, and knew the right heuristics to speed things up.)

    This made it much easier for engineers to create and use models. Now they wrote them in VSL, much more expressive to the task than Fortran. And in a minute they either knew they had a syntax error or were testing their model.

    In a couple years, we went from a couple of pilot projects to like 50. Every auto company took it up. Boeing used to help re-engineer the FA-18. Today probably every car, airplane, and hard drive was analyzed using VSL. (Siemens wound-up with the product eventually, after a few acquisitions.) I don't know if VSA is still under the hood, or if it really has any practical use today: the models are now written using point/click/drag/popup stuff on drawings. What my boss new we had to eventually get to, but couldn't at the time.

    Of the languages mention

  11. Go does not see significant use, even at Google. by tlambert · · Score: 3, Interesting

    Go does not see significant use, even at Google. It's one of the allowed implementation languages, along with Python, JavaScript, and C/C++, but it doesn't see a lot of uptake internally at Google.

  12. Proud tradition by Just+Some+Guy · · Score: 3, Interesting

    Like when Bell Labs developed C to write Unix? There's a long tradition of major companies coming up with new languages to scratch an itch. Thank God is hasn't died. How boring to live in a time when we'd decided that there was nothing left to innovate?

    --
    Dewey, what part of this looks like authorities should be involved?
    1. Re:Proud tradition by drjzzz · · Score: 2

      Bell Labs didn't develop C; in fact I think Bell Labs hardly knew what to do with it. Two (brilliant) people -- Keringhan and Ritchie -- working in Bell Labs wrote C and developed Unix so that they could do what they wanted, better and quicker, on the minicomputers around their labs. Their slim volume "The C Programming Language" is amazingly engaging, concise, and deeply instructive. Modern IDEs are great for many things but they also constitute a significant hurdle to actually coding, which K&R had you doing pronto in a succinct, introductory tutorial chapter.

      --
      to err is human, to forgive is divine, to forget is... umm...
  13. Re:The real conspiracy... by slapout · · Score: 4, Informative

    It's hard to flip thru an ebook the same way you do a paperback.

    --
    Coder's Stone: The programming language quick ref for iPad
  14. Re:Why? by Actually,+I+do+RTFA · · Score: 3, Insightful

    real men have their own programming language

    If I was in charge of a huge budget, and the ability to foist my language on the public, I would invent my own language. heck, every programmer wishes they could design the language everyone uses.

    --
    Your ad here. Ask me how!