Live data from Hacker News

Software in 2014

tbray.org

141–150 of 265 posts

Re: Software in 2014

#141
post #62

I think this paints a rather meagre picture of software development in 2014: > More or less everything is expected to talk HTTP, and it’s really easy to make things talk HTTP. A lot of things that shouldn't talk HTTP are expected to just because there's an army of programmers who don't know better. Also, it's actually hard to make things talk HTTP, partly due to HTTP itself. However, much of this complexity is hidden…

> In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved? Sounds to me like you've never developed seriously on an ARM chipset. These devices are worlds apart from your standard desktop, there is a reason that both Android and IOS dropped Adobe flash. It's partly the hardware and p…

The original iPhone, back when these decisions were made to not support flash, used an arm 1176 processor underclocked at 412MHz. That was a single-issue, in-order core without SIMD. Consider the Cortex-A15 and the latest Qualcomm parts; they're at least three-wide fully out-of-order cores supporting 128b SIMD operation with fused multiply-add, clocked at 1.5-2GHz in two- and four-core configurations. They are far more similar to a low-voltage Core2 package than they are to the armv6 processors of the first iPhone and Android devices (and in some ways they’re actually nicer to program for), and would easily be capable of handling a flash runtime.

Re: Software in 2014

#142
"More or less everything is built with an MVC-or-equivalent level of abstraction, and there are good frameworks to help us work sanely and cleanly. It’s a pity some people still build important apps in PHP and Spring, but those aren’t choices anyone is forcing them to make."

Lost me right there. PHP in 2014 has some awesome frameworks and a huge open source community, never enjoyed working with it more than today.

Re: Software in 2014

#143
post #94

Earlier quoted context omitted.

> Sounds to me like you've never developed seriously on an ARM chipset. You're selling cucumbers to the gardener, I was actually one career choice away from designing chips, and wrote ARM assembly before there was anything such as a tablet. A mobile phone is slow in comparison to a desktop, but not slow enough to afford an excuse for lagging in most of today's mobile applications. If a Facebook client, a mail applica…

> If a Facebook client, a mail application, a simple 2D game or a music player lags on such a mobile phone, it does so because it's a piece of crap. Fair point. It has more to do with the way these apps are cobbled together out of heterogeneous chunks of code, just to make them look "cool". The native frameworks are lacking in terms of their ability to easily customize the controls, so people start applying crazy hac…

That's my understanding, too. Developers are using high-level frameworks that generate an absurd number of redraws. In many cases, the bottleneck isn't even the CPU or the memory, but simply pushing too many pixels to the screen. It doesn't help that we expect much snappier response from touch interfaces than from 10-year-old desktops. Two seconds to open a new screen was somewhat acceptable in a VB6 application. Try to do that in an Android app, and see the kind of rating you get.

Re: Software in 2014

#144
post #119
post #72

Earlier quoted context omitted.

> In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved? Those CPU don't have as much cache memory (which is vital for a CPU to be fast), are very low powered, and not cooled by any fan. Even my $50 nokia can do 3D, 3D acceleration doesn't mean it's a fast device. CPU frequency do…

> If you make an app for a smartphone, you can't really have even one third of the expectations you have on a desktop or laptop computer. So what you're saying is that in a couple of years mobile phones will be as powerful as today's desktops and laptops? So any applications you design now that you expect to be relevant in a few years time need to take that into account.

No they won't, until there is a huge breakthrough in battery technology. And please stop talking about "computer power", because most of computer power boils down to how much data per second a CPU can treat, unless you have a really minimal software design. Data per second equates to energy consumption.

Although even today batteries hold quite a lot of power and you can watch it when you break it, lithium battery can be dangerous, so more powerful batteries might not be such a good idea.

Re: Software in 2014

#145
post #131
post #79

Earlier quoted context omitted.

lucky php has very clever people doing clever things with it - see hhvm for a recent great thing for PHP.

> lucky php has very clever people doing clever things with it - see hhvm for a recent great thing for PHP The whole point of HHVM is to migrate away from the PHP runtime (by using the PHP language on another runtime). It's a bit perverted to say that's a god thing for PHP.

its just a more performant runtime environment, why is that migrating away from php ?

Re: Software in 2014

#146
post #129

Earlier quoted context omitted.

> Browsers are fine as long as you use them for what they are meant to be used A lot of people now want to use their browser for far more than that and browser technologies are evolving accordingly. I'd suggest it's been quite a while since browsers were meant to be used for nothing more than browsing html files.

> A lot of people now want to use their browser for far more than that No. People want a way to quickly use new software. It's just that the easiest way to achieve this today is providing applications via the browser.

OK I'll rephrase; for most people the internet isn't a thing where you view static html documents anymore. Therefore people want to use "something" to access these things (for example new software) and currently this thing is a browser.

Therefore in terms of the expectation of a majority of its users, it's not accurate to define a browser as something for looking at static html documents.

Not to say there couldn't be a different something for this - java applets, flash etc have all tried and failed to remove this from the browsers functionality to a delegated function - but at the moment there doesn't seem to be a viable alternative.

Re: Software in 2014

#147

Earlier quoted context omitted.

Supposedly (and I'm being quite serious) the Surface 2 plays flash websites quite nicely in IE.

I think modern Android and iOS devices could do that just as well. I believe not supporting Flash has more to do with Apple/Google strategies (i.e. not depending on propietary third party software) than actual hardware limitations.

Yep. Who wants to make bad ports easier? Their goal is to keep their users hooked, and people are cheap (or stupid if you prefer) and approach value from the wrong direction, money spent instead of value gained.

Re: Software in 2014

#148

Earlier quoted context omitted.

> In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved? Sounds to me like you've never developed seriously on an ARM chipset. These devices are worlds apart from your standard desktop, there is a reason that both Android and IOS dropped Adobe flash. It's partly the hardware and p…

The original iPhone, back when these decisions were made to not support flash, used an arm 1176 processor underclocked at 412MHz. That was a single-issue, in-order core without SIMD. Consider the Cortex-A15 and the latest Qualcomm parts; they're at least three-wide fully out-of-order cores supporting 128b SIMD operation with fused multiply-add, clocked at 1.5-2GHz in two- and four-core configurations. They are far mo…

I just think adobe didn't really work to optimize flash for this processor in particular. Flash is a complex piece of software, and it's not properly made.

Re: Software in 2014

#149
post #127

Earlier quoted context omitted.

It's a pity that people still build important app in PHP, because despite improvements to PHP, there are several, even many, languages out there that beats PHP flat out on all fronts. PHP used to be by far the easiest language to get started with for web dev. This is not the case anymore. And while you're certainly entitled to disagreement, Tim Bray is about as far from "so called" you can get for a software professi…

"PHP used to be by far the easiest language to get started with for web dev. This is not the case anymore." um - who would be the contenders? in terms of getting started, which also means deploying and see your stuff on something other than your local machine, I can't think of anything better supported than PHP. Most budget hosting you can simply upload your brand new, first-ever PHP script and have it 'just work'. N…

> who would be the contenders?

Here's a good start - and I'll bet that Heroku's free tier is a better option than most $5/month PHP webhosts:

https://devcenter.heroku.com/categories/language-support

Re: Software in 2014

#150
post #140
post #87

Earlier quoted context omitted.

> Those CPU don't have as much cache memory (which is vital for a CPU to be fast), are very low powered, and not cooled by any fan. They are, nonetheless, far more powerful than computers which ten years ago ran comparable applications of comparable feature and comparable eye candy complexity (if somewhat lacking in design taste). I think cache memory should mostly be irrelevant for many of the user-facing mobile app…

> Cache memory is not vital for a CPU "to be fast" in every situation, it's vital for a CPU to be fast with bulk data. If you're working on bits and pieces of information that are hundreds of bytes in length, low cache count is no excuse to be slow. That's why the software and protocol you use on a mobile device should be very much different. To me, desktop and mobile software are way too much similar. The fact a pro…

> The fact a programmer will fuck up an app boils to the fact twitter will use HTTP, which is text, on top of SSL. This can't be blazing fast for such a low powered device, especially if it's a library API thing you use to make an app on top of it. I think google and the web in general are mostly to blame because they're responsible of spreading text based protocols.

I think this paints only part of the truth. About an year ago (I don't know if this still applies today), I grudgingly agreed to see if Phonegap could be of any help to us in a project. The difference in interface alone was noticeable: slider widgets were sloppy and noticeably froze, on a mid-range phone. The same native widget was fine.

Clearly, then, the phone isn't memory- or CPU-starved to the point where it can't paint a slider widget. It logically follows that one implementation of that widget is inefficient (sweet talk for "it's worse than it could be", if not "it's bad").

HTTP over SSL probably does make for slow data transfer on such a device, but it should play little role in a sloppy UI. I've seen fluid, well-built UIs that ran on slower devices, over slower data links (think hundreds of bytes per second or even less). They adequately conveyed the information that the device is waiting for data, or that data is being fed at a slow pace, but they weren't botching.

Post reply on HN