Code it
4.6K views | +0 today
Follow
Code it
This is a curated resource for programmers and software architects. It is regularly updated with Articles, Hacks, How Tos, Examples and Code.
Curated by nrip
Your new post is loading...
Your new post is loading...
Scooped by nrip
Scoop.it!

Why Python hasn't taken off on mobile, or in the browser - according to its creator

Why Python hasn't taken off on mobile, or in the browser - according to its creator | Code it | Scoop.it

Python creator Guido van Rossum reveals the strengths and weaknesses of one of the world's most popular programming languages.

 

mobile app development is one of the key growth fields that Python hasn't gained any traction in, despite it dominating in machine learning with libraries like NumPy and Google's TensorFlow, as well as backend services automation.

 

Python isn't exactly boxed into high-end hardware, but that's where it's gravitated to and it's been left out of mobile and the browser, even if it's popular on the backend of these services, he said.

 

Why? Python simply guzzles too much memory and energy from hardware, he said. For similar reasons, he said Python probably doesn't have a future in the browser despite WebAssembly, a standard that is helping make more powerful applications on websites.  

 

Mobile app development in Python is a "bit of a sore point", said van Rossum in a recent video Q&A for Microsoft Reactor.  

 

"It would be nice if mobile apps could be written in Python. There are actually a few people working on that but CPython has 30 years of history where it's been built for an environment that is a workstation, a desktop or a server and it expects that kind of environment and the users expect that kind of environment," he said.

 

"The people who have managed to cross-compile CPython to run on an Android tablet or even on iOS, they find that it eats up a lot of resources," he said. "Compared to what the mobile operating systems expect, Python is big and slow. It uses a lot of battery charge, so if you're coding in Python you would probably very quickly run down your battery and quickly run out of memory," he said.

 

"Python is a pretty popular language [at the backend]. At Google I worked on projects that were sort of built on Python, although most Google stuff wasn't. At Dropbox, the whole Dropbox server is built on Python. On the other hand, if you look at what runs in the browser, that's the world of JavaScript and unless it translates to JavaScript, you can't run it," van Rossum said. 

 

"I don't mind so much different languages have to have different goals i mean nobody is asking Rust when you can write Rust in the browser; at least that wouldn't seem a useful sort of target for Rust either. Python should focus on the application areas where it's good and for the web that's the backend and for scientific data processing."

 

watch the Microsoft Q&A with him at https://www.youtube.com/watch?v=aYbNh3NS7jA

 

 

read the original article at https://www.zdnet.com/article/python-programming-why-it-hasnt-taken-off-in-the-browser-or-mobile-according-to-its-creator/

 

 

No comment yet.
Scooped by nrip
Scoop.it!

Amazon Web Services Launches New Capabilities for Mobile Developers

Amazon Web Services Launches New Capabilities for Mobile Developers | Code it | Scoop.it

Amazon Web Services  today announced several new capabilities to make it easier for developers to build, deploy, and scale mobile applications. Amazon Cognito is a new service that provides simple user identity and data synchronization that lets developers create apps that authenticate users through popular public login providers, and then keep app data such as user preferences and game state synced between devices.


The new Amazon Mobile Analytics service allows developers to easily collect and analyze app usage data, up to billions of events per day from millions of users, and delivers usage reports within an hour of data being sent by the app. AWS is also introducing a new unified Mobile Software Development Kit (SDK) that makes it easy for iOS, Android, and Fire OS developers to access the new Amazon Cognito and Amazon Mobile Analytics services as well as popular AWS services like Amazon S3 and Amazon DynamoDB.


Today, many app developers around the world use the AWS Cloud as infrastructure building blocks for the back-end services that power their mobile applications. Still, these mobile app developers have had to spend valuable time on undifferentiated heavy lifting like connecting apps to storage and database services and integrating core functionality such as authentication, user management, notifications, and usage data analytics. With Amazon Cognito, Amazon Mobile Analytics, and the AWS Mobile SDK, developers are now able to focus more of their energy on what matters, the differentiated functionality of their app that attracts and retains end users.


With AWS Mobile Services, developers can:


  • Securely store, manage, and sync user identities and data (Amazon Cognito)

  • Quickly access and understand app usage data (Amazon Mobile Analytics)

  • Easily connect apps to AWS services (AWS Mobile SDK)

  • Send notifications, updates, and promotions across platforms (Amazon SNS)



To get started with AWS Mobile Services, visit http://aws.amazon.com/mobile .
No comment yet.
Scooped by nrip
Scoop.it!

The inevitable result of focusing only on shipping features

The inevitable result of focusing only on shipping features | Code it | Scoop.it

If we confuse shipping features for building a product, we will eventually see all forward progress cease.

 

If we are continually adding new features, the overall complexity of the software will steadily increase, and the surface area that we need to maintain will grow to an unsustainable state. I’m not suggesting that adding new features is bad, but we need to add them with the long-term product in mind. We need to see a continuous focus on restructuring/improving the product as part of our job, not a tax that takes us away from adding new features.

 

A common pattern in large software systems is that they grow in scope over time, leading to a state where they can no longer move quickly or keep up with the regular ongoing work needed.

 

Eventually they die out or someone must rebuild them from the ground up. The business or the engineering team makes this decision because it seems like the easiest path forward. This doesn’t have to be the case, but to avoid it requires a mindset change. 

 

A focus on reducing complexity and sustainable growth.

 

A preference for enhancing our core functionality instead of adding new capabilities.

 

There are definite reasons for new features, they can be critical to the product, but we must build them with an awareness of their cost.

 

We also need to be aware of what we are celebrating and creating incentives around. Is work done to improve maintainability, efficiency and existing functionality given equal weight to shipping something new and shiny? I suspect that if it were, we would have more stable and reliable software that could avoid the eventual demise of so many projects.

 

read the complete version of this beautifully written, brilliant article at https://www.duncanmackenzie.net/blog/inevitable-cost-of-focusing-on-only-features/

 

nrip's insight:

I believe that any products' market growth comes first from from the regular consistent improvement of its core capabilities/features of and then from the new bells and whistles that are added to it as offerings to its customers. This lovely articles articulates this so well.

 

I  am extracting this example from within the article out here so its easily visible and available to read for all those lazy guys who dont click on the link to the article and read it.

 

Imagine you have a construction company that designs and builds skyscrapers. They can create one new skyscraper a year. Assuming nothing else changes, they should be able to keep that pace up for the long-term. Now, after each new building project finishes, have that same team take over as the maintenance and operators of that building. It’s a small amount of work, relative to the full construction, but it takes a part of their capacity away, so the next building takes 13 months to finish. Now they take over the maintenance of that building as well. They are smart, so there are some efficiencies gained, but still, the next building takes 14 months to complete. Eventually, there are so few team members left to focus on the next project, that all progress stops.

 

 

No comment yet.