Live data from Hacker News

Android, evolvability and Comcast

abe-winter.github.io

51–60 of 71 posts

Re: Android, evolvability and Comcast

#51
post #5
post #4

The solution is called React Native. - Single file app: Check - Super fast rebuild: Check - Dynamic language (high reusability and one-liners): Check (Use ClojureScript to take this even further)

But there is a single problem with React Native: Javascript (and all languages that come from it). It's frequently one of the most hated ones as it is loved. Dynamic language is not necessary the best thing invented, if it were there wouldn't be any other kind of languages.

I was just addressing the issues outlined in the post. I would hardly define ClojureScript as a language that came from JavaScript.

Naturally there are cases when a typed language is better than a dynamic one.

Re: Android, evolvability and Comcast

#53
post #21

Man, I knew this was a troll when I clicked the link. I'll briefly vent my spleen and get on with a substantive comment. I get real tired of web soft boys coming into native and complaining about how complicated it is on the metal. This stuff is hard cause you're not just churning html. It's harder work than writing a web page. Sorry. Specifically, mobile is resource constrained in a way that server-side work just is…

"Metal is just the last layer you care to look under."

Re: Android, evolvability and Comcast

#54

Earlier quoted context omitted.

Because Facebook has thrown tens of millions of dollars towards getting a unified cross platform method of having 60fps rich mobile apps. Because managing an app of more than trivial complexity on iOS and Android is massively expensive. Because this approach offers the most leverage with the least trade offs of performance, development overhead, and future viability. And because live coding mobile apps with a REPL is…

These are all developer centric points. What about users? Android already needs huge batteries, make everything run JavaScript and they'll need to be even larger. And forget computationally heavy apps? The hardware android runs on doesn't exactly have the best JavaScript performance.

[deleted]

Re: Android, evolvability and Comcast

#55

Earlier quoted context omitted.

Because Facebook has thrown tens of millions of dollars towards getting a unified cross platform method of having 60fps rich mobile apps. Because managing an app of more than trivial complexity on iOS and Android is massively expensive. Because this approach offers the most leverage with the least trade offs of performance, development overhead, and future viability. And because live coding mobile apps with a REPL is…

These are all developer centric points. What about users? Android already needs huge batteries, make everything run JavaScript and they'll need to be even larger. And forget computationally heavy apps? The hardware android runs on doesn't exactly have the best JavaScript performance.

I'm not sure you understand what react-native is... The app your users use isn't running javascript, it's not Facebook Cordova. You use javascript to compose the app, there's no javascript in the app you deliver to the users.

Re: Android, evolvability and Comcast

#56
post #2

If this post gains traction, its title will probably be changed to “Android, evolvability & comcast” since that's the title of the linked article. So here, for posterity, is the original post title, which made me chuckle: If you like calling comcast you'll love android studio

I miss that title. I have no clue what the article is about from reading the new title.

Re: Android, evolvability and Comcast

#57

I have many complaints with java, but this: "Java is pretty bad at producing portable one-liners. In my opinion that’s because of the public/private feature (completely unnecessary), " was the point, when I stopped taking him seriously.

I'm sensitive to the argument that public/private rules improve maintainability of libraries by shrinking the exported API. Maybe, but that's a maintainability argument, not a usability/reusability argument.

It's hard to predict which part of your program developers are going to need. Also, 'private by default' prevents the gradual modularization of code that happens in languages lacking visibility rules.

Re: Android, evolvability and Comcast

#58
post #4

The solution is called React Native. - Single file app: Check - Super fast rebuild: Check - Dynamic language (high reusability and one-liners): Check (Use ClojureScript to take this even further)

There is something seriously wrong with our industry. How can this even be suggested as a solution?

People will always suggest what they know as a solution to everything. A lot of people only have deep knowledge of, say, Javascript or Python. That's why you see people in threads like this suggesting these languages as the solution for whatever problem they envision.

That's also why you see horrible solutions for problems that have already been solved in the past.

There should be a rule that says that you are not allowed to design a framework until you have direct experience in developing for at least 5 different systems from different periods in history first.

Re: Android, evolvability and Comcast

#59

Earlier quoted context omitted.

These are all developer centric points. What about users? Android already needs huge batteries, make everything run JavaScript and they'll need to be even larger. And forget computationally heavy apps? The hardware android runs on doesn't exactly have the best JavaScript performance.

I'm not sure you understand what react-native is... The app your users use isn't running javascript, it's not Facebook Cordova. You use javascript to compose the app, there's no javascript in the app you deliver to the users.

What? Surely the JS you write is embedded in the release build.

Re: Android, evolvability and Comcast

#60
I stopped taking the author seriously when I saw that he was using ListView. Maybe that's a factor of poor documentation, but there's no reason to use ListView (and the are many reasons not too).

I'll admit there are issues with Android, but reducing them to the same tired arguments against Java is just lazy (and lack of config files?).

[Developing for Android for close to 8 years]

Post reply on HN