I don't think this analogy conveys anything particularly useful. The reasons most restaurants don't charge Michelin star prices are:
* Ingredient costs go up rapidly too.
* Because of that, the profit margins are narrow in the restaurant business at all restaurant price levels. There are rich restauranteurs here and there but owning a high end restaurant is still a very risky business venture and many are barely scraping by.
* You become talent bound. Finding chefs who can prepare food at that level is hard. Designing a good menu is very hard. Food is like any other creative art, you can't just arbitrarily decide to make amazing food—many try and fail.
* There is limited demand. Most people can't afford to eat high end food often and even those who can often don't want to go to the same restaurant over and over.
I don't see how any of this maps to the topic being discussed.
If we're talking about construction work in South-East Asia, the same basic principles apply. Limited demand because there really aren't that many foreigners relative to locals (and some of the foreigners don't have more money than the local middle class anyway), and satisfying the foreigners' more exacting standards, weird ideas about construction and insistence on exotic materials needs more skill than most local construction workers possess, and competent English. That means most people in construction are only going to get to work for a wealthy Westerner through a middleman, and that middleman is going to pay them the standard local rates.
Drawbacks, hmm — I'm not sure, really, there is no silver bullet, and I can't see significant problems with the language itself that another language would magically solve. I'm pretty happy with Clojure and ClojureScript and some advantages are hard to replicate elsewhere (such as business logic code being written only once and then shared between Clojure and ClojureScript).
One thing I noticed is I got spoiled by Rich Hickey solving problems for me, and I'd really like him to continue doing so. For example, transducers and core.async were great, but spec isn't quite finished yet. Also, reporting status and anomalies (as in, status of operations, computations, including errors/exceptions) and passing it through channels or foreign encodings is a problem I had to solve myself. I'm pretty sure Rich could come up with a better solution.
The biggest problems that I encounter everyday are not with the language itself, but with the ecosystem. Many libraries could use more maintenance. And the really big problems aren't language-related at all. For example, RethinkDB shutting down. I also wish I didn't have to write the full FoundationDB integration ("language binding") myself.
AdStage is a cross-channel advertising management platform helping in-house marketers and digital agencies easily report, automate, and optimize paid search and social campaigns under one roof. We are looking for someone to join our report product team. Report is a WYSIWYG tool for marketers to build dashboards and present their performance internally and to their clients. https://www.adstage.io/reporting/
The report product stack is Clojure and Datomic on the backend, with Clojurescript and Fulcro/Om Next on the front end. We are looking for people with experience or a desire to learn functional programming in a modern Lisp.
For senior engineer we are looking for someone with - 4 to 6 years of engineering experience - Strong leadership skills and communication skills - Experience with any of the following languages and technologies: JavaScript, Ruby, Clojure, Cassandra - Software engineering degree - Experience with marketing or advertising industries is a plus - Management experience is also a plus - ONSITE San Francisco
If you are interested please email stefan@adstage.io.
AdStage is a cross-channel advertising management platform helping in-house
marketers and digital agencies easily report, automate, and optimize paid search
and social campaigns under one roof. We are looking for someone to join our
report product team. Report is a WYSIWYG tool for marketers to build dashboards
and present their performance internally and to their clients.
https://www.adstage.io/reporting/
The report product stack is Clojure and Datomic on the backend, with
Clojurescript and Fulcro/Om Next on the front end. We are looking for people with
experience or a desire to learn functional programming in a modern Lisp.
For senior engineer we are looking for someone with
- 4 to 6 years of engineering experience
- Strong leadership skills and communication skills
- Experience with any of the following languages and technologies: JavaScript,
Ruby, Clojure, Cassandra
- Software engineering degree
- Experience with marketing or advertising industries is a plus
- Management experience is also a plus
- ONSITE San Francisco
If you are interested please email stefan@adstage.io.
AdStage | Full-Stack Engineer | San Francisco ONSITE
AdStage is a cross-channel advertising management platform helping in-house marketers and digital agencies easily report, automate, and optimize paid search and social campaigns under one roof. We are looking for someone to join our report product team. Report is a WYSIWYG tool for marketers to build dashboards and present their performance internally and to their clients.
https://www.adstage.io/reporting/
The report product stack is Clojure and Datomic on the backend, with Clojurescript and Om Next on the front end. We are looking for people with experience or a desire to learn functional programming in a modern Lisp.
PG in some of his older articles was really big on Lisp being the most powerful programming language and instrumental to his success. His writing actually inspired me to learn Clojure.
In your experience, does the power of a programming language, in a software business, matter as much?
This is on the top of HN because people, like me, are interested in it. You say learn to do it the "right way", by that logic we should have stuck to making desktop only apps instead of browser based web apps. I'm not saying this is better or worse. But I certainly think it's an approach worth considering.
It's a great piece of tech, I'm not saying anything against that, I'm saying that it shouldn't be used as a replacement for native programming because you don't want to learn a new language. react will come with huge limitations and deps that you don't want to even think about, it's never easy as "code once, deploy everywhere", this is usually a bad decision any company makes, engineering wise.. same reason as adobe air never took off, it's a bad idea, the only reason this is taking off is because people already know JS and don't want to learn something else.
By the "right way" I mean use every language for its intended purpose, you can't build desktop apps in browsers, that's why we have Javascript. and i'm saying we should keep it that way
React Native doesn't claim "code once, deploy everywhere", and in fact embraces native APIs where appropriate. As a reference, their slogan is "learn once, write anywhere". In other words, learn React Native, and write native apps wherever you want. Indeed one of the opening talks about React Native at React Conf specifically mentions that React Native is a leaky abstraction, and embraces that by allowing multiple escape hatches so that the native APIs are always available.
Railing against React Native seems like railing against Unity3d, or saying that abstracting the common parts of mobile development (while leaving the non-common parts 100% available) is a bad thing.
By the "right way" I mean use every language for its intended purpose, you can't build desktop apps in browsers
You can build desktop apps in browsers (ie emscripten). Additionally, can you explain why a "language" (as compared to platform specific APIs) has any relevance to what can or can't be built for a mobile device? For JavaScript specifically, if Apple didn't think that it was a language for building applications on iOS, then why would they ever have release JavascriptCore (which is what React Native uses)?
React is native.
It's a JS interpreter on a separate queue rendering native UILabels and UIViews.
I'd say the concept is far more superior to UIKit which disgusts me, and I've worked with for almost seven years now. I honestly think React is the future, but for now we can try to stick with MVVM and RxSwift ;-).
I think you're fundamentally not understanding how React (not just React-native) works.
This is mainly taking off because native developers want a fast build-run loop, hot code reloading, the ability to update code on the device without pushing a new App Store release, and a shared technology and mental model for writing apps across web, iOS and Android.
No, it is not. "I don't know what I am doing" mentality already hurts the web, where hordes of developers without understanding of the strengths and limitations of the platform are making angular monstrosities, now the same is being pushed to mobile.
Luckily it does not have much chances there.
