7 ms·

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 t

by weland 13y ago

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)

talkingquickly 13y ago
> 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.
- jokoon 13y ago
  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.
- _pmf_ 13y ago
  > 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.
  - talkingquickly 13y ago
    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.
jokoon 13y ago
> 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.
- weland 13y ago
  > 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.
pjmlp 13y ago
> 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.
integricho 13y ago
I just can't believe, not one thread on HN starts with an "i agree totally" reply.
bluetomcat 13y ago
> 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.
Quarrelsome 13y ago
> 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.
- weland 13y ago
  > 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.
  - Quarrelsome 13y ago
    > 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.
    - weland 13y ago
      > 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.
      - 13y ago
lsh 13y ago
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.
- weland 13y ago
  If we ever end up in the same part of the world, we should grab a beer :-). I share your worries.
  - lsh 13y ago
    I'm in London, find me at lsh@ccxx.cx I'll get the first round.
  - georgemcbay 13y ago
    I'm in San Diego and would like to subscribe to your newsletter.
bad_user 13y ago
> 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.
- bruceboughton 13y ago
  >> 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.
- weland 13y ago
  > 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.
  - derefr 13y ago
    > 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.)
10098 13y ago
> 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.
- deeviant 13y ago
  Take a look at http://kentonv.github.io/capnproto/ http://kentonv.github.io/capnproto/
- xyzzyz 13y ago
  You can use Apache Thrift for that (developed by Facebook).
protomyth 13y ago
> 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.
- weland 13y ago
  Dear God, yes! That was a beautiful platform. Beautiful.
pistle 13y ago
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"
saber_taylor 13y ago
HTTP is used since it won't be firewalled.
auvrw 13y ago
> 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.

by weland 13y ago

talkingquickly 13y ago

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

jokoon 13y ago
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.
_pmf_ 13y ago
> 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.
- talkingquickly 13y ago
  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.

jokoon 13y ago

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

weland 13y ago
> 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.

pjmlp 13y ago

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

integricho 13y ago

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

bluetomcat 13y ago

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

Quarrelsome 13y ago

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

weland 13y ago
> 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.
- Quarrelsome 13y ago
  > 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.
  - weland 13y ago
    > 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.
    - 13y ago

lsh 13y ago

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.

weland 13y ago
If we ever end up in the same part of the world, we should grab a beer :-). I share your worries.
- lsh 13y ago
  I'm in London, find me at lsh@ccxx.cx I'll get the first round.
- georgemcbay 13y ago
  I'm in San Diego and would like to subscribe to your newsletter.

bad_user 13y ago

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

bruceboughton 13y ago
>> 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.
weland 13y ago
> 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.
- derefr 13y ago
  > 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.)

10098 13y ago

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

deeviant 13y ago
Take a look at http://kentonv.github.io/capnproto/ http://kentonv.github.io/capnproto/
xyzzyz 13y ago
You can use Apache Thrift for that (developed by Facebook).

protomyth 13y ago

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

weland 13y ago
Dear God, yes! That was a beautiful platform. Beautiful.

pistle 13y ago

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"

saber_taylor 13y ago

HTTP is used since it won't be firewalled.

auvrw 13y ago