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."
Now by anonymous submission.
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.
New programming languages props up the publishing industry by producing dead-tree door-stoppers that detail the new programming language. I stopped buying dead-tree door-stoppers years ago, cleared off the bookshelves and get the ebook version.
Duh. This was a dumb article and whoever approved it should feel ashamed.
Comment removed based on user account deletion
Why? /. = hacked (and is stopping submissions of it too) http://www.theregister.co.uk/2...
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.
real men have their own programming language, that's why!
Like how they used to say in the chip business, real men have their own fab.
Bigshot online identity providers LinkedIn and Amazon were vulnerable to a novel attack that allowed ID fraudsters potential access to top websites – including Slashdot, NASDAQ.com and Crowdfunder – an IBM security duo have revealed.
Really?
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.
I assumed it was a case a Not Invented Here Syndrome.
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.
The name alone is a reason to never touch that language?
A: What do u do? B: I'm a hack programmer!
*A runs away*
I'd give it to Apple for being most responsible of the 3 (we really don't don't need Go, or Dart or Hack, but Objective C is too verbose. Enter Swift. You could add SAP ABAP or Salesforce APEX as well of course but they're even more irrelevant I guess.
I have higher hopes for Mozilla's Rust than any of the above.
Looks that way from the article posted and what have you.
Then Red Forman would be the mascot for Swift.
As in, a swift kick in the ass. Dumbass.
Get free satoshi (Bitcoin) and Dogecoins
This is nothing new AA had Sabretalk back in the 80s.
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...
http://en.wikipedia.org/wiki/A...
>. A computer scientist can implement any algorithm in any language.
ou CAN pound a nail with a screwdriver. You can even pound a nail with a saw. A hammer is a much better, more efficient tool for that job. If you need to install hundreds of nails, a nail gun is a much better tool.
I COULD use VB to convert one type of XML to another, but I use xslt (true xslt, not loops) because it's a better tool for the job. I use several languages each day, selecting the one best suited for the task at hand.
> if you cannot implement that algorithm in that language then you are nothing but a code monkey.
If you DO implement all algorithms in your favorite language (JavaScript?!?!?) ... well, you're like the "contractor" who owns nothing but a hammer, and says "I can't do it with a hammer..."
PS - generally there is one condition that decides whether JavaScript is the best choice . JS is the best choice if and only if that's the only possible option. For client-side logic in a web page that needs to work in multiple browsers, it's the best option because it's the only option. Anywhere else, there is probably a better tool for the job.
safari books online.
www.safaribooksonline.com
imho certainly worth the money...
in Apple's case, particularly
That is exactly backwards.
Apple needed to go forward with a new language, but no other language offers the kind of interoperability that Swift does, nor would any existing language designers have been willing to bend to make that happen.
In Apple's case they designed a modern language that you can use to the fullest, while at the same time having easy bridging to Objective-C so that developers (including Apple's developers!!) can chose a transition timeline that makes sense for what they are doing.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Just because you CAN code an algorithm in a language doesn't mean it's the best option. Just because I can drive a screw into a 2x4 with the heel of my shoe doesn't mean I should.
Please, stop with the carpentry analogies. This isn't carpentry.
Languages are developed to make certain problem domains easier.
I agree somewhat. Yeah, writing an OS in Python would be a bitch and probably require some firmware written in 'C' and I find writing my Internet data scrapers and text parsers much easier in Python that it would be in 'C' - because those libraries are built into the language.
IOTW, folks confuse language syntax with the libraries the language has.
Python isn't a better language for manhandling web content than C; it's built-in libraries are simpler to use (i.e. it's seamless).
But what get's me is that these companies can do quite well with using existing languages and just adding an API. Instead of spending all their time on developing a new language, why no just create an API and use Javascript, Python, C, C#, BASIC, Perl, R's ...whatever? ANY of those languages are more than capable of doing what they need.
Why Another Fucking Language - WAFL?
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
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.
so that developers (including Apple's developers!!) can chose a transition timeline entirely at apples discretion to change everything yesterday and not tell you til next month.
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?
Perhaps it's done to discourage employees from changing jobs?
If all you know is "Go", where you gonna go?
If you force your programmers to learn Go, it's less likely Apple will steal them as their programming experience will be in a language that is useless to them, and to any other company.
Have you read the bit about "Concurrency is not MultiProcessing" (or something that means the same thing). Go is a single threaded language, which is concurrent but not multiprocessing. So there's basically no payoff in many cases from using it, and you've got to run it through an interpreter (unless you use the gcc version).
So why bother?
I think we've pushed this "anyone can grow up to be president" thing too far.
Sounds more like linked-in got hacked, and this hack could be used to sign into Slashdot.
I think we've pushed this "anyone can grow up to be president" thing too far.
Someone drank too much of the koolaid.
So how d'ya like "beta" now? Only a fool would've used the design /. did.
You are right. The Nimrod programming language (http://nimrod-lang.org) is essentially a much better swift (macros for meta programming), cross platform, and I've been using it for a year with great pleasure. But it has a hard time to interact with objc, and that is Apple's inheritance. Pity, hopefully Swift 2.0 will catch up with Nimrod and provide macros too, they are really sweet.
Other than a handful of obvious edge cases (the worst of which were fixed with fast enumeration and string and number constants), I'd argue that it mostly isn't Objective-C that is too verbose, but rather the Cocoa APIs themselves. And you'll be using those same ginormous scrubtheKitchenSink:withBrilloPad:andCleanser:byHand:usingExcessiveForce: methods in Swift, just with slightly different punctuation....
Check out my sci-fi/humor trilogy at PatriotsBooks.
I disagree. Dylan was very innovative at its time, but I can't see what's so great about Swift from the admittedly cursory look I've taken at it, although I can understand why someone who is used to Objective-C might like it.
Apple could have done much better. Perhaps language marketing played a more important role than language design this time.
Won't comment on Facebook Hack, since it's not clear to me why Facebook itself needs to exist. But to each their own...
My understanding is that Facebook needed a more statically-typed language (while still preserving the familiar syntax of PHP) in order to exploit more performance advantages when compiling their code to the HHVM, which started off as a PHP compiler.
Yes Go offers a simple lightweight single thread concurrency with asynchronous support.
However, runtime.GOMAXPROCS(2) will give you 2 proc multithreading run in parallel, etc.
Go is probably the most potentially useful language. But it doesn't have enough of a user and development base to replace C++. And while it may take 45 minutes to do a build on large C++ project, you do get a lot of control over the process and built-in optimisation so that the code will run faster. Go is pretty much Pike and Thompson latest concurrent toy (after Newsqueak, Alef & Limbo).
Apple has always had custom environments, they will just eventually have Swift instead of Objective C at the heart of them. So not much change.
The article is well written for a general audience but not very technical. It makes no mention of Dart, which is the one real attempt and an imperial takeover by a corporate giant. But all Dart does is allow Google's apps to run faster on Chrome. Other browser makers don't see any advantage in this, not enough to put a second language into them anyway, and in fact seem to think that Google's apps running slower than native Javascript on their browser is just fine.
Go code is compiled, not interpreted.
The author seems to believe C was born open sourced. Not only was it invented by a big company employee for a specific purpose, when Pascal already existed, it was so proprietary that hackers used to break into AT&T buildings to learn how to code in it.
I said it is the best choice for client-side processing on web pages, because it's the only plausible option. Where other options exist, the others are probably better suited to the task.
If you disagree, can you come up with a counterexample, any scenario where you'd consider using something other than JavaScript, but decide JavaScript is better than the alternative? I'm curious what solutions could be worse than JavaScript. As stated in what you quoted, I do mean solutions - things that would work, but not work as well as JavaScript.
It's "Concurrency is not Parallelism". However Go supports both just fine: I rote a multithreaded image processor in Go that got linear speed up with the number of CPU cores. That's simply not the only (or main) use of the concurrency primitives in go.
Also the original/default Go compiler is not an interpreter. Its a real compiler. While its not great at optimizing, decently written code runs at speed somewhat close to C, and some code will run about as fast as C. It was compiled at the original public release and still is.
, and you've got to run it through an interpreter
My god... did you... what?... Ok... this guy doesn't know shit about what he's talking about. Go is compiled.
If Apple had moved to a whitespace-active language I seriously would have switched to Android development.
Not even joking. I have used a lot of languages professionally and for fun, but I could not get past that aspect of Python and I can't see why such an insane design flaw would be any more tolerable in Nimrod.
It has so many dangers in terms of correctness and overlooked bugs...
There was one other language that bugged me in... Fortran... but at least there is only affected what was a comment, it didn't oversee control flow.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
You could have said the same thing with a lot less words had you phrased it as:
No, I can't think of even one application where you'd consider two languages and decide JavaScript was better for that application.
I didn't say JavaScript doesn't have a lot of features. It does have a large mishmash of features. I said it'll almost always be the worst choice, if you have any other option.
> its intended purpose, making it exceptionally well-fit for the web.
It's the ONLY choice for client-side web. As I said twice before, that's the one place nothing is worse or better - because you have no other choice.
> Java
Since neither iOS nor most Android devices run Java applets, that means MOST users today won't run them. A "solution" that won't run at all for most users isn't a solution. You can't say "Java and JavaScript would both work, but JavaScript would be better".
If you're advocating JavaScript as a server-side language, well that's just silly. Learn any language designed for server-side and after you understand it tell me JavaScript is better suited.
> (Other popular criticisms stem from pure, unadulterated, ignorance: The behavior of this, for example.)
If a key component of the language behaves in unintuitive, surprising, and troublesome ways, that's a valid criticism. See "principle of least surprise".
You've made some good points, and ones directly responsive to my statement this time. That is true, once upon time Java was a serious option on the client side and it did have the hype. So much so that Livescript was renamed JavaScript to take advantage of the Java hype. JavaScript won, against actual competition. Ps I WAS around during that time, and I've written ActiveX controls for use on public web pages. JavaScript beat both ActiveX and Java in the browser.
The PayPal link is interesting as well. I was curious what their reasoning was, given the plethora of server-side languages, why choose one that's very much designed for a very different role in a very different environment, with very different constraints? They said the primary reason was so that there front-end Javascript developers could also author the matching server-side portion. That's interesting and a little surprising to me. Note one subtle distinction that may not be important except in the context of this thread - they did not say - JavaScript was best suited for the role of server-side development, they said that they wanted a particular team to do server-side and that team only knew JavaScript.
It turned out that for PayPal, Javascript did the job just fine for them. So I'll revise my statement:
If all you know is JavaScript, it might be enough to get the job done.
If it's client side web browser code, JavaScript is the only workable option because it beat Java in this role.
Otherwise, where you have a choice, JavaScript is NORMALLY not the best suited for any role other than client side web page code. Exceptions may exist.
I had assumed that:
meant that the go compiler was basically a "byte-code compiler", and that this code was run through an interpreter.
By "byte-code compiler" I actually mean it was used to generate a bunch of calls to library routines that did the actual work. I wasn't actually presuming that the op-codes were single bytes, as I consider that irrelevant.
The claim that "it runs as fast as C" is one that I've heard most interpreted languages since Java make, so I pretty much ignored it. I did note that they considered the LLVM to be too slow, but I interpreted this as meaning they build a customized virtual machine.
OTOH, the gcc version of go does compile to machine code, so there's nothing inherently improbable in it actually compiling to machine code. That's just not the way I read things. (I also think of Java as an interpreted language, and Python, and Ruby...though at least in the case of Java and Python the more technically correct phraseology is that they are compiled to a virtual machine.)
For that matter one could say that UCSD Pascal was compiled to a virtual machine, but it was always called an interpreted language.
I think we've pushed this "anyone can grow up to be president" thing too far.
Not only that, but I think it is more relevant to developer lock in to a particular platform. Just like C# and Apple, and say porting video games from Xbox to Playstation. They want exclusivity on applications developed for their particular platform. This is nothing new. It is just a way to exclude competition to their particular market, and to prevent or at least make it more difficult to get the same functionality from a competing service.
As probably many people mentioned, any coder worth their salt can use or learn any new language without too much effort. Coders with multiple experience would of course have an edge.