Hacker News new | past | comments | ask | show | jobs | submit login

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, leaving people to think that

> devices are memory-starved, CPU-starved, and battery-starved.

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?

The fact that so many applications perform computationally trivial things, but lag on such devices, has nothing to do with their processing power being low, and has everything to do with them being badly written. It takes a lot of effort to make an application lag on such a system.

> Browsers suck too

Browsers are fine as long as you use them for what they are meant to be used: browsing HTML files. Seriously, browsers have been just fine and dandy since the days of Opera 6.

What does suck, indeed, is when people try to use tools that were meant to make HTML docs look nice to build an office suite. They inevitably end up with an office suite that sucks, but that's not the browser's fault.

(Edit: just to be clear, the author kind of seems to imply some of these points, too)




> What does suck, indeed, is when people try to use tools that were meant to make HTML docs look nice to build an office suite. They inevitably end up with an office suite that sucks, but that's not the browser's fault.

Yet, because it runs in the browser and is available everywhere, that's why I use Google's Docs. And GMail's web interface is better than any email client I tried until now.

> Browsers are fine as long as you use them for what they are meant to be used: browsing HTML files.

Phones are also fine as long as you use them for what they are meant to be used: initiating phone calls.

So why use browsers as application platforms? Just as in the case of phones becoming potent computational devices, the answer is - because we can and because it brings benefits that aren't easily solvable by any alternative.


> Yet, because it runs in the browser and is available everywhere, that's why I use Google's Docs. And GMail's web interface is better than any email client I tried until now.

IMHO, this is a case of solving a problem at a wrong level. I also find that matches provide neither a sufficiently long-lasting, nor a sufficiently intense fire to cook. Longer and thicker matches would obviously be a solution to this, and it would definitely work. That doesn't make it a good solution.

> Phones are also fine as long as you use them for what they are meant to be used: initiating phone calls.

Yes; and I do think smartphones are a terrible piece of engineering. The "mobile" part ceases being true when their battery is only sufficient to allow them to be mobile for the duration of an entry-level delayed road trip. I'd much rather have a dumphone and a tablet than a smartphone.


> Yes; and I do think smartphones are a terrible piece of engineering.

I can't read that and not scoff. I don't know how you can seriously argue that smartphones aren't a great piece of engineering. The power, accessibility, and flexibility offered in a device that easily fits in your pocket is pretty amazing in my book. Yes, battery technology isn't the best, but to say somehow that what has happened in the smartphone industry in the past 5 years isn't an amazing piece of engineering, I find that pretty laughable. I guess we should all go back to our brick phones and blackberries for the business types then?


They are an impressive feat of technical prowess, no questions asked there. Whenever I look at the innards of an iPhone or a Galaxy I am not only impressed, but -- with all the wear and tear of the EE that's buried inside my soul -- I can only shrug and admit that the electronic design is way, way past my skills.

That being said, the impressive design of the PCB and of some of the chips aside, smartphones are a failure of engineering. As mobile phones they have to do two things:

- Move, and

- Allow you to talk on the phone.

Very much like a mobile seat, say, a car, or a wheelchair. If I were to build a car or a wheelchair that could only go for fifteen kilometers or so -- and generally move, but not at an impressive pace, would you be happy? I, for one, wouldn't,

Battery technology is, indeed, the major setback, despite the incredible research activity that goes into it. However, I think they made the wrong trade-off, not only regarding to battery life, but also regarding software development and deployment options and especially user interaction. Choosing trade-offs is the root of engineering.

> I guess we should all go back to our brick phones and blackberries for the business types then?

I'm dead serious about it. Between my tablet and my brick phone, I can do everything that my colleagues who have smartphones can do. I also enjoy a) the benefit of a larger screen estate and b) the laughs when their portable devices are useless in the evening because they forgot their chargers at home. Bonus if I'm the one who has to call the cabs for everyone after a few rounds of drinks, because my phone is the only one still running.


Mmmm. It's not a great piece of engineering because they compromise on the wrong thing: mobility, precisely because of their tendency to eat up the battery in less than a day. When you need to charge a mobile device every single day, it's not meeting the ideal specifications you want to have, so yeah, in that sense it's shitty engineering we have been forced to swallow. And that's not going in the good direction when you keep putting more cores and more watts in in the smartphones' innards, while the battery technology is very slow to evolve.


It is interesting that Apple seems to have been focusing lately on mobility at the expense of more 'sexy' improvements. When talking to people around me, the battery life of devices rarely comes up, and yet in my own experience the most important improvements that I notice in day to day use of laptop, and tablet, has the battery life.

I'm not saying that it's exclusively Apple that focuses on this. That's beside the point. Rather, I find it interesting that so often the wrong trade-offs are made for so long and by everyone.


> The "mobile" part ceases being true when their battery is only sufficient to allow them to be mobile for the duration of an entry-level delayed road trip. I'd much rather have a dumphone and a tablet than a smartphone.

You sound like someone who lives in a somewhat-rural area. Smartphones are somewhat like smart cars, in that they're basically built for urbanites--people who mostly either end up at home each night (where there's a charger), or travel by flying (and take their charger with them.)


Precisely. There's an engineering trade off between processing power, display size, resolution, brightness, and battery life. I don't think battery life has ever been the feature that sells gadgets.

I read somewhere that SJ set the bar for iPad battery life at ~10 hours, and I think that set consumer expectations across the industry. Think of the iPad 3: it got thicker and heavier, in order to maintain battery life when faced with the retina screen.

My hypothesis: For each device category, there is an "accepted" battery life that new devices must meet. Beyond that, what sells better: a 15% boost in speed or in battery life?

When people stop using performance benchmarks and start using battery life, then companies may take notice. Until then, resign yourself to 1-2 days of battery on a smartphone.


> The "mobile" part ceases being true when their battery is only sufficient to allow them to be mobile for the duration of an entry-level delayed road trip.

Not that this is more than a patch for poor battery life, but even if you have a long-lived battery but sometimes forget to charge your phone until it's dead, it's worth being able to charge your phone on the road. GPS drains the battery significantly faster, so you can be doubly-screwed if you're using your phone for driving directions and the battery runs out -- no directions, and no way to call for help!

It's pretty easy to find a cigarette lighter plug with a USB port, fortunately.


> Phones are also fine as long as you use them for what they are meant to be used: initiating phone calls.

I don't know that is the case... Between the crappy bluetooth voice commands in my car, and having to unlock and click through 3+ items to get to a dialpad, I don't think "smart phones" make very smart phones...


>> Phones are also fine as long as you use them for what they are meant to be used: initiating phone calls.

Swap tablets for phones then and the GP's point stands.


> 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 doesn't mean it's a muscly device either. You'll always need power for fast computing, and multithreading without adapted programming paradigm lead you nowhere. Those chips are very much different than your desktop's.

Many things are already preoptimized on the kernel level, but it doesn't change the fact that even html and javascript parsers, which parse text, will be slower on those devices. 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. Optimizing will be mandatory, and that's a huge disadvantage because most developers are not trained for that.

Not to mention the bogus "optimizing is evil" knuth quote. Performance will bite you on mobile software.


> the bogus "optimizing is evil" knuth quote.

Read the quote again - Knuth talks about "PREMATURE optimization"! (it is a common mistake to leave the word out - but it alters the meaning significantly).

You should optimize only when you know what should be optimized (and how), which is very true for all platforms alike. And it is just common sense if you think about it.

Why is this quote important? Because most "not so good" programmers spend hours and hours polishing things that are not important (see StackOverflow for huge number of examples) but they feel ( / know / sense /...) will make for a better performance. On the other hand they often sacrifice code legibility, correctness and even the real performance in the process.

Not bogus at all.


Yes, we desperately need the "mobile is the new desktop computer" meme to die. You get what you pay for, and a CPU that barely consumes a watt will not deliver desktop performance, no matter the cores, memory or frequency.

That said, compared to actual CPU- and memory-starved embedded systems, mobile is a freaking race car. If you measure your memory in multiples of megabyte, you need not apply. Given that, the performance situation on mobile is rather appalling.


> That said, compared to actual CPU- and memory-starved embedded systems, mobile is a freaking race car. If you measure your memory in multiples of megabyte, you need not apply. Given that, the performance situation on mobile is rather appalling.

YES! Maybe it's my use of the word "computer" above? I didn't want to imply one should expect the same performance from a mobile phone that they expect from a desktop. I called it a computer because it computes, not because it qualifies for being put in a big case with keyboard in front of it.


> 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 applications. They tend to be more I/O bound than computationally-bound. I think something is seriously fucked up if a programmer manages to screw up the performance of his Twitter client or chat application because of caching. This isn't the case for, say, mobile games or various types of multimedia applications, but that's a different story. The point is, a native-looking interface made up of nothing but native-looking widgets has no excuse for being laggy on such a platform.

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.

It's also worth noting that on today SoC's, a lot of data processing is offloaded in different manner. Small cache on a general-purpose CPU that has to do software video decoding has a far larger impact than small cache on an SoC with a dedicated video processor, with its own set of fast-access memory buffers & co..

I'm obviously not trying to imply that a 1 GHz mobile SoC is equivalent in every term of processing power as, say, a 1 GHz network processor or a 1 GHz PowerPC from a Powerbook. But things are actually somewhat better than you paint them to be.

> Many things are already preoptimized on the kernel level, but it doesn't change the fact that even html and javascript parsers, which parse text, will be slower on those devices.

Obviously not. What I am arguing is that having to parse HTML and Javascript in applications that are not web browsers (or which otherwise don't have to browse hypertext because hypertext is essential to their intended function) is superfluous.

Edit:

> Performance will bite you on mobile software.

Performace will bite you on every type of software. It's a mad, possibly rabid dog that hates humans. Some programmers, however, seem very prone to teasing it.


I think the point is more that without a decent cache, the speed of a cpu is greatly throttled to really be the speed of the memory feeding it.

Consider, for much of the task of browsing the web, the largest noticable speed problem is decidedly not the local device, but how long it takes for the data to load.


> 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 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'm just concerned about mobile software, because the hardware is really really good, but the software had not been adapted for it. We just need protocols and format that are just faster, more compact, and maybe rely on other networking optimizations. bittorrent, for example, is a great example of a reliable binary protocol.

HTTP and HTML were great because they are easy platforms to make something on, but they require more memory because of parsers and more bandwidth because one single web page will often weigh 100ko, and run a javascript engine which is not a simple piece of software.

The hardware has gotten smaller, maybe we also need to make smaller software too ! I agree there are also security concerns about binary protocols, but it's just weird that there are so few open, standardized binary protocols, maybe because developers find working with http being just easier. You can't have it easy all the time.


> 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.


> 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.


oh my god, you're my new best friend. I was despairing of finding any opinion on HN that wasn't so mired in being too politically correct that it could have been written by a cold, dead fish with a robot brain powered by HAL. my extreme cynicism of HN comments has been temporarily rolled back.

> 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.

this worries me actually - there is such fantastic momentum with new developers and new tools pushing a very narrow set of technologies forward simply because they haven't had broad exposure (experience) to other ways of building yet that we'll arrive (or perhaps have arrived ...?) at a point in the future where we really begin to suffer from a sort of deficit in available sophisticated technologies because of a long heritage of using HTTP/HTML/JS/Webkit/MVC for frickin everything. Those teaching won't know any better and it will be up to those who have been taught to dive farther and farther back in time to when there was more diversity to find and appreciate different solutions. A little dystopian, perhaps, but justified. Cross pollination of disciplines and variety will save us.


If we ever end up in the same part of the world, we should grab a beer :-). I share your worries.


I'm in London, find me at lsh@ccxx.cx

I'll get the first round.


I'm in San Diego and would like to subscribe to your newsletter.


> 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.


So true. Browser were meant to display page, the day javascript was introduced, nobody would have really imagined to see 3D webgl games running on the monster that is v8.


> Browsers are fine as long as you use them for what they are meant to be used: browsing HTML files

Fully agree. I do web development since 1999, besides many other types of projects.

On those days, it was a new world to discover.

Nowadays, I jump of joy every time I am asked to work in native UIs, instead of fighting against the Frankenstein that is the HTML/CSS/JavaScript mess.


> 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 partly shitty ARM code, its not really much to do with the specs. I can do things much more easily on an underpowered x86 than an overpowered ARM.


> 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 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.


> 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 hacks just to mimic some functionality seen in another app, without any regard for the performance. It just has to "work".


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.


> because it's a piece of crap.

I don't think that's a fair assessment. The challenge is that developing for mobile is nowhere near _as_ _easy_ as desktop. So we have a legion of desktop devs coming over to mobile and getting lost, their code doesn't "suck" its fine for desktop its just not good mobile code. Also, power management.


> their code doesn't "suck" its fine for desktop its just not good mobile code

IMHO, code that is not adequate for a platform on which it is intentionally deployed, by definition, sucks. There's no such thing as good application that is fine for any computer except those it is ran on.


As a person who used an LG "smart"phone that couldn't handle the bare Android OS without lagging (and turning on Wi-Fi would freeze it to death), I agree wholeheartedly. Intentionally selling crap that doesn't work is evil in my book.


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.


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.


I call underpowered to Z80, 3.5Mhz, and 48Kb ram. ( http://en.wikipedia.org/wiki/ZX_Spectrum ) Still it had pretty amazing programs :)


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.


Even old tablets could do that perfectly fine, for example the touchpad (on both Android and WebOS).


Even on the slow (by smartphone standards) Nexus One, Flash ran quite decently. The Nexus 5 is a good magnitude faster in every way (I can't find specific parity-version benchmarks, so perhaps I'll fire both of them up and give it a go), moreso in some ways like the GPU, and is as powerful as some desktops that people still use in business settings. It would of course have no problem with Flash.

Flash failed because a good percentage of existing content relied upon the accouterments of a desktop, namely the keyboard and the mouse. Minus these it just made for a frustrating experience for a lot of users. Add the fact that sites were loaded with obnoxious, taxing Flash ads, and it just gave users of Flash-enabled devices a very negative experience. It also reflected poorly on the product as a number of popular tech sites compared Android and iOS web page loading times, the former seriously hindered by the loading and overhead of Flash.

There were later changes to make it activate on click, but that just made it even more of a usability burden.

In a way, at the time this whole debate was raging, iOS users got to enjoy essentially a free "adblock" in the absence of Flash.

I have to entirely disagree with any notion that smartphones are underpowered: I am currently working on a very intense real-time image processing system and with each iteration I'm finding that I'm increasing the scope and featureset because the performance continually blows me away. Even when I work on "older" devices like the Galaxy S3, with good code and good parallelization (incl. the GPU), it is just a ridiculous platform.


Flash would have been unsupported (or b0rked) in iOS whatever happened: it would have allowed others to compete with the App Store.

Sure, there were technical arguments, but you're naive if you think that they key to the decision.


> 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?

In the same weird world that an old NeXT Cube is easier to write applications for and has more responsive apps than the modern web client HTML5 apps.


Dear God, yes! That was a beautiful platform. Beautiful.


> 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.

Agree with this. Actually, I'd love it if Google released some kind of an RPC library for passing around protocol buffers between applications. It would be so much better than the crazy pseudo-REST mess we have.



You can use Apache Thrift for that (developed by Facebook).


> What does suck, indeed, is when people try to use tools that were meant to make HTML docs look nice to build an office suite.

The same thing is now happening to a certain extent in the native mobile development. UI Frameworks have been steadily inadequate towards the modern UI idioms and trends, so people are doing crazy things customizing the standard components to have their app looking like FB's app, for example. It's the UI frameworks that are seriously lacking, not so much the tools and the languages.


These little devices are also running applications built with tools that have heavy runtime and library dependencies along with sandboxing, etc. etc. etc. We used to write closer to the metal with the responsibility to not take out the whole thing.

Now, we write features first, as "elegantly" as possible, THEN we optimize as required. Look at what 3D games are doing on little devices vs. how poorly long lists perform during scrolling.

There's plenty of power there, but code will bloat to fill all resources. You said it. "...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?

lol, sir, lol.


HTTP is used since it won't be firewalled.


I just can't believe, not one thread on HN starts with an "i agree totally" reply.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: