Objective-C vs R: What are the differences?
Developers describe Objective-C as "The primary programming language you use when writing software for OS X and iOS". Objective-C is a superset of the C programming language and provides object-oriented capabilities and a dynamic runtime. Objective-C inherits the syntax, primitive types, and flow control statements of C and adds syntax for defining classes and methods. It also adds language-level support for object graph management and object literals while providing dynamic typing and binding, deferring many responsibilities until runtime. On the other hand, R is detailed as "A language and environment for statistical computing and graphics". R provides a wide variety of statistical (linear and nonlinear modelling, classical statistical tests, time-series analysis, classification, clustering, ...) and graphical techniques, and is highly extensible.
Objective-C and R belong to "Languages" category of the tech stack.
"Ios" is the primary reason why developers consider Objective-C over the competitors, whereas "Data analysis " was stated as the key factor in picking R.
Uber Technologies, Instagram, and Pinterest are some of the popular companies that use Objective-C, whereas R is used by AdRoll, Instacart, and Verba. Objective-C has a broader approval, being mentioned in 851 company stacks & 363 developers stacks; compared to R, which is listed in 128 company stacks and 97 developer stacks.
What is Objective-C?
What is R?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Objective-C?
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
By mid-2015, around the time of the Series E, the Digital department at WeWork had grown to more than 40 people to support the company’s growing product needs.
By then, they’d migrated the main website off of WordPress to Ruby on Rails, and a combination React, Angular, and jQuery, though there were efforts to move entirely to React for the front-end.
The backend was structured around a microservices architecture built partially in Node.js, along with a combination of Ruby, Python, Bash, and Go. Swift/Objective-C and Java powered the mobile apps.
These technologies power the listings on the website, as well as various internal tools, like community manager dashboards as well as RFID hardware for access management.
At the heart of Uber’s mobile app development are four primary apps: Android rider, Android driver, iOS rider, and iOS driver. Android developers build in Java, iOS in Objective C and Swift. Engineers across both platforms land code into a monolithic code base that ships each week.
They use some third-party libraries, but often build their own, since “Many open source libraries available are general-purpose, which can create binary bloat. For mobile engineering, every kilobyte matters.”
On Android, the build system is Gradle. For the UI, Butter Knife binds views and callbacks to fields and methods via annotation processing, and Picasso provides image loading.
As for iOS, all of the code lives in a monorepo built with Buck. For crash detection, KSCrash reports crashes to the internal reporting framework.
Excerpts from how we developed (and subsequently open sourced) Uber's cross-platform mobile architecture framework, RIBs , going from Objective-C to Swift in the process for iOS: https://github.com/uber/RIBs
Uber’s new application architecture (RIBs) extensively uses protocols to keep its various components decoupled and testable. We used this architecture for the first time in our new rider application and moved our primary language from Objective-C to Swift. Since Swift is a very static language, unit testing became problematic. Dynamic languages have good frameworks to build test mocks, stubs, or stand-ins by dynamically creating or modifying existing concrete classes.
Needless to say, we were not very excited about the additional complexity of manually writing and maintaining mock implementations for each of our thousands of protocols.
The information required to generate mock classes already exists in the Swift protocol. For Uber’s use case, we set out to create tooling that would let engineers automatically generate test mocks for any protocol they wanted by simply annotating them.
The iOS codebase for our rider application alone incorporates around 1,500 of these generated mocks. Without our code generation tool, all of these would have to be written and maintained by hand, which would have made testing much more time-intensive. Auto-generated mocks have contributed a lot to the unit test coverage that we have today.
We built these code generation tools ourselves for a number of reasons, including that there weren’t many open source tools available at the time we started our effort. Today, there are some great open source tools to generate resource accessors, like SwiftGen. And Sourcery can help you with generic code generation needs:
(GitHub : https://github.com/uber/RIBs )
The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.
Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).
At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.
For more info:
- Our Algorithms Tour: https://algorithms-tour.stitchfix.com/
- Our blog: https://multithreaded.stitchfix.com/blog/
- Careers: https://multithreaded.stitchfix.com/careers/
#DataScience #DataStack #Data
Basically, the trajectory was we had our iOS app, which started out native, right? It started as a native app, and then we realized you have to go through a review process and it’s slow, and at a very early stage, it made sense for us to make it a wrapped web view. Basically, the app would open, and it would be a web view inside of it that we could iterate on quickly and change very rapidly and not have to wait for app store view process to change it. It wasn’t totally a native experience, but it was as actually a pretty good experience and lasted for a very long time and was up until recently the foundation of our current mobile web experience, which is different from our app situation. So for a long time, basically, our app store iOS Instacart app was a wrapped web view of just our store, a condensed version of our store, which meant that we could add things. We could change sales. We could change the formatting. We could change the UI really fast and not have to worry about the app store review process.
This all changed about a year ago, I would like to say, at which point it became a totally native app. We felt comfortable enough with the product and all the features that we made it a native experience and made it a fully featured app.
What are my other choices for a vectorized statistics language. Professor was pushing SAS Jump (or was that SPSS) with a menu-driven point and click approach. (Reproducibility can still be accomplished, you publish the script generated by all your clicks.) But I want to type everything, great online tutorials for R. I think I made the right pick.
While the majority of our stack is now using Swift, we still love Objective-C in many cases, especially low-level software manipulation, where it's just easier. It doesn't hurt that a lot of iOS/OS X Libraries out there are written in it either.
We like to go native with iOS development, and Objective-C has been the only game in town until recent introduction of Swift. We're keeping an eye on Swift, but we aren't giving up on the [old way:to do:things]!
Connect to database, data analytics, draw diagram. Machine Learning application, and also used Spark-R for big data processing.
PrometheanTV provides SDKs for IOS devices including support for the Objective-C language.
Visualisation of air quality in various rooms by RShiny (hosted free on shinyapps.io)