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...
> 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.
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.
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.
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.
> 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.
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.
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 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 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.
> 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.
> 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.
> 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?
I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
Yeah, xd clearly missed to list that the creator of the language also has a sense of humor, but trying to limit it to technical features seems reasonable.
> 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.
It's the equivalent of smacking a malfunctioning (mechanical) appliance to try and make it work again. Maybe you just want something to last long enough until you can get a better-designed, more reliable appliance.
He works on Go at Google. A skilled professional no doubt, could he not have made some valid points rather than simply calling PHP disgusting. It didn't add anything to the conversation.
If you where in the pub and someone spent some time listing the virtues of the pint they where drinking, and then someone joined in the conversation and called it disgusting with no basis .. wouldn't you find that to be odd behavior?
And hell, the fact that people have that opinion stems from somewhere. And that is a fact we should all take a note of -- to build better tools. You see, PHP is nothing but a tool, and as a tool, it's not very liked one due to it's flaws. Solution? Abandon it! Build new, better tools instead of feeling threathened.
Le PHP sink and die it's well deserved death and make way for better tools, because professionals shouldn't feel attached to their tools, instead they should be critical towards them and look to find better ones.
And that is precisely what Tim is saying. He happens to work mostly with the new tool named Go but he does recognize that there are others like Rust and Dart that are also trying to do things better.
But we need to actually move away from using bad tools (and this has happened with PERL) and start using the newer, better tools more often. Every software developer should learn some Erlang (or Elixir), some Clojure, some Go, etc.
If you don't try these tools out and kick the tires for a while, then you end up stuck in the past like all those COBOL programmers.
Oh god. It's Perl. And no need to drag it through the mud here. It's pretty much the only language that gets Unicode right. It has nothing in common with the abject misery that is PHP. Perl came out in '87. Erlang came out in '86. I don't know what you're high on, other than trends and trendwhores.
Clojure isn't new. Not to take a dig at Rich Hickey, but everything he is doing with immutable objects was done more than a decade ago by the likes of Henry Baker (http://home.pipeline.com/~hbaker1/home.html). Of course, everything that has ever been tried at all has been tried in some variant of Lisp/Scheme at one point in time.
Clojure isn't new. Not to take a dig at Rich Hickey, but everything he is doing with immutable objects was done more than a decade ago by the likes of Henry Baker (http://home.pipeline.com/~hbaker1/home.html). Of course, everything that has ever been tried at all has been tried in some variant of Lisp/Scheme at one point in time.
Stop while you're behind. Nobody believes that Henry Baker's papers are equal to what Rich Hickey has done with immutable objects. Geez, get a grip on reality man.
I might be wrong, but COBOL isn't being actively developed as a language anymore .. PHP however is still solving problems and under constant development and improving all the time.
PHP is great for developers and firms because they are always required to stay and make sure things blow up. Most of the PHP I've worked with was also very hard to decipher by anyone except the original developer.
He has updated the article over time which is good of him, but much of it is still subjective and from a quick glance there are points that no longer hold true.
It was a long one, and I'll admit I only skimmed it.
But from a glance, it looks like the one writing the rebuttal didn't really understand the criticism, and is himself 100% captured by the exact mindset which the original article criticized PHP for having.
This guy is the one who will be standing at the door complaining that you just broke his house. He is what is wrong with PHP.
And naturally, however much sense he thinks his argument makes, it will still be wrong. It's in the very nature of this situation.
He probably didn't elaborate because he felt the basis for the view was clear - there are clearly areas of PHP which still need work. PHP is often frowned upon because the APIs are a mess of legacy cruft like addslashes, magic_quotes, mysql_escape_string, mysql_real_escape_string, mysqli_real_escape_string versus prepared statements. Efforts are being made to clean it up, but for a language to ever end up in a place with that sort of library functions is a pretty big red flag.
Because php ends up combining the API consistency of C with the syntactic elegance of visual basic. I say this as someone who programs php professionally, the fact that they still haven't provided a complete set of OO api's very much speaks against the language stewards. PHP could have a sane subset, like javascript, but because there are gaps in the API (like the string and array API's, which are horrible) you can't get a sane subset without adding some extra API wrappers of your own.
And that's why it's impossible to build frameworkless PHP code that is elegant, something that even the designed-in-10-days javascript lets you do.
Still, i like php for its getting things done mentality. What it lacks in elegance it makes up for in productivity.
Sorry if I upset you. Your feature list is no stronger a point than my response, though. Features don't make a language great. Clarity, consistency, simplicity, and orthogonality do. PHP has none of those qualities. I know, because I used it extensively for a decade.
I stand by my comment. I can see why people like PHP but nobody in their right mind should deny that it is a mess and that it was constructed haphazardly.
"Elitist?" I came into web development via the PHP tradesman's entrance, and until by the grace of God I found my way out into the wider world, I didn't even begin to suspect just how miserable I had it. If there's a tinge of elitism in the wider world's attitude toward PHP, I'll be the first to contend that it's justified.
Not really a parallel; you'll never meet a long-time cigarette smoker who doesn't know how awful a habit it is, although you'll probably meet some who will lie about it.
On the other hand -- and I say this as a smoker, albeit as one who's cut back his habit to almost nothing over the last couple years -- smoking is an awful habit, which is both severely addictive and without meaningful benefit for the person with the habit or for anyone else. So I suppose I'm not all that inclined to quibble about the not-quite-perfect parallel, after all. :)
My perception is most developers who choose to use PHP these days for new development efforts either do so because it's their strongest language and do not want to reinvest the time to retool, or because of political reasons orthogonal to PHP's technical chops. Thankfully, it is still actively developed, so those who make that choice are able to take advantage of such new features.
I totally understand the choice to work in shops that have legacy php code: they have money and often times don't want to change off php. Handily enough, most of us like working for money.
What caused me to retool away from php was the fear that not enough new systems were being built in it, leaving a diminishing pool of jobs for a constant pool of developers not wanting to retool. I figured I'd give up my space to someone else, and seek my fortunes on other stacks. I don't think there is anything wrong with deciding X language will be the one you ride into the sunset on (some COBOL programmers I know make crazy money due to the economics of the ratio of jobs/developers). I just personally considered the risk of a job shortage to outweigh the rush of a talent shortage. (And I am so practiced at retooling, I could probably be ready to interview for a PHP job in a few weeks if I had to).
I think of choice of stacks from the agile way, "make it fast to change, and you'll be ready to snatch up arbitrage opportunities when they arise." Rather than the waterfall way, "pick the right tech that will last your career at the point of maximum ignorance".
I think most people mock PHP just because it's fashionable to do so, it's the "easy joke" that vb6 used to be. I wouldn't take it personally, you should own your choices.
Yes, php is more checklist complete than it was a few years ago, but there's still quite a bit of ugliness in the language. For example, you mention
* closures (including support for $this)
I looked at this a couple days ago, because closures make a lot of problems easier. However, PHP's handling of closures is more than a bit ugly and hackish. Yes, it supports $this, but this was done after the initial release, doesn't give much confidence in how it's handled under the hood. Plus, you have some real syntactic ugliness; in order to scope variables into a closure, you have to declare them again with a now overloaded keyword -- use -- with them passed by value by default. Closures in pretty much any other language, you just put them in the scope of your function and the compiler/interpreter knows how to handle them without any hints from you.
While php is less bad now, there's still quite a bit of ugliness in it due to its tendency to just spackle new parts on without any regard for what the end result looks and functions like. The php team needs to make a concerted effort to clean the language of its rough points, even if it breaks backwards compatibility, otherwise, useful ideas will continue to be hampered by an overbloated ugly core.
PHP, especially post 5.2, is a flexible and battle tested language to do work in. It has some bad design choices inherited but nothing that you can't overcome and never have to think about again in a couple of weeks of learning the language.
Exactly like Javascript in this regard. I've been programming JS for over 15 years, and with the exception of cross browser support back in the day, there's nothing that had me startled after I learned the language -- except for a few issues related to floating point that I stumble upon now and then, but then that would be true for floating point math in any language.
The only PHP inconsistency is with the naming of the built-in functions. Functionality wise, most are solid bindings of respected C libraries. And, really, the needle/haystack thing has been blown out of all proportion. As if that's the biggest challenge one faces when programming.
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 professional.
"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'. No need to worry about wsgi, cgi-bin, application servers or anything.
As much as I loathe PHP because it sweeps the developer towards bad habits and unreadable, bug-ridden, slop, I love it because, rather like a bash, it's a flexible and comprehensive tool in my toolbox.
Speaking as someone who has written hundreds of thousands of lines of php over the years, i think php's main problem is not that it lacks features, but rather that it doesn't have a sane subset, a javascript-like 'good parts' if you will. PHP added OO api's for date and database handling in the 4 to 5 transition, but it never got around to doing the same for strings and arrays. So frameworkless php is by necessity a mixture of procedural and OO code (unless you go pure procedural), and always looks ugly. PHP's stewards could solve this by bringing all the API's into the OO fold, and I have experimented [0] with what PHP could look like if strings and arrays were objects, but so far this hasn't happened.
You do have some really nice frameworks that hide the procedural stuff, like laravel, and that code looks nice, but it is really slow. And this is the inherent conflict of the php developer. If you write raw php, it is ugly but fast. If you use a framework it is pretty but slow. The techempower benchmarks [1] demonstrate this, where raw php performs at near-native speeds, but frameworks like symfony and laravel are embarassingly slow in comparison.
So, php's scorn is well deserved. It's productive, yes, but it is impossible to build a world-class top-performing app in it and still get clean and consistent code without jumping through some sizeable hoops (like facebook did by building their own php engine and php-like language called Hack, in addition to their own frameworks).
This was a competent and accurate criticism of PHP. Backed up with references, neither of which were veekun's rant. Thank you for adding some signal to the noise which usually accompanies threads where PHP is mentioned.
PHP certainly has features and it certainly is successful, and people are certainly doing stuff with it. It also certainly has severe and fundamental design flaws that are never going away.
It's distressing to say the least to many of us people who have studied programming languages a lot, that the quality of design and coherence in your programming language has almost no effect (or even negative correlation!) to how well it succeeds.
Node as javascript does handle the object notation natively, which is an advantage over PHP in terms of handling JSON. Which, coupled with the (recently corrected) awkward syntax for arrays, unfortunately makes PHP's most common pattern (conversion of SQL data into arrays and maybe into JSON) more of a hassle than it should be.
Oddly, he mentions three client-side areas: Web, iOS and Android.
Did anyone else notice that he didn't mention "THE DESKTOP" or any native applications? I don't know about you but I tend to use native applications every day and use the web for getting data and info. I don't use "apps" that sit in a browser all day.
If he thought that the Web/iOS/Android system was bad, he should have actually put Web / iOS / Android / WindowsPhone / Metro / NatinveWin32 / Linux / Mac OS.
Although the web was meant to fix all the problems with writing cross-platform apps, it hasn't. So I still happily use and write native applications for each platform instead of writing something for the Web that'll be out of date in a few years or will need testing in one of any 25+ combinations of browsers on different platforms.
I've recently discovered node-webkit (https://github.com/rogerwang/node-webkit) which I've been liking a lot. It's more or less chrome, packaged as a one-off app, that only runs the code you give it.
Converting the app (web/browser extension) I'm working on to use it has so far been extremely favorable. On top of this, it embeds node.js in the browser runtime. So not only do you get all of chromium's HTML5 features, but you get a whole hell of a lot of native libraries for free via node.js. It also has a good amount of UI helpers built in so you can keep the OS-specific code to a minimum.
This lets you hit both web and desktop (Windows, Linux, Mac) with a very similar/same codebase. Then all that's left is mobile =].
IMO, as a long-time desktop developer (occasional early mobile and web), unless you're interfacing with hardware, there is probably no reason for you to be writing a true native desktop application.
At this point, even if I were writing business CRUD apps, I think I'd be reluctant to start using, say, C# and .Net, preferring some kind of packaged system allowing me to, effectively, write desktop apps using mobile languages and stacks.
Given the hundreds of millions of Windows users, can you think of thousands (or even hundreds) of Small Businesses making money selling applications to Windows users? The only ones that I know of are large companies - Microsoft, Apple, Oracle, Adobe, VMWare, etc. And if you include the parasites of the software world there are the companies like Symantec, Kaspersky and their ilk. But those are all giant companies.
Perhaps not thousands. But do you use an online accounting package or do they use Sage or Pegasus? Do you use an online 3D modelling system or do you use Maya / Blender / 3DS Max / SolidWerks etc.? Do you use an online media player or do you use MPlayer / VLC / FFMPEG etc.? Do you play games online in a browser or do you play games written under DirectX / OpenGL that run natively? Was your time scheduled at work using an online system or a timetabling / resource management piece of software? For quotes, do you use an online system or do people use Quotewerks etc.?
People forget the massive native application market and the many years of software heritage that Windows permits them to still run. Just because giant companies create widely used applications doesn't mean that there isn't a vast myriad of other software floating around that isn't written to run in a web browser. There is a trend, particularly here on HN, to think that all software revolves around stuff done in a browser but it is narrow minded. Native software typically has a much longer lifespan.
What classes as a small business? Up to what size? I don't have figures but I have worked for 2 in the past that wrote software for Windows, one solely existing for the software, the other for complimenting their services with a side software product. They managed to turnover > £1million and >£4 million respectively.
Do we need to have thousands of companies listed in order for their software to qualify as "software" in your eyes?
The main point was that Tim ignored desktop native software in his analysis of software, which I felt was an oversight given that probably 98% of jobs involving a computer use desktop software all day long, software that was purchased. I do not see Doris in the admin office using a web browser all day long for her job.
Just because you and I might not be buying desktop software in droves does not mean that there isn't a market for it, a pretty sizeable market. Home users might not be buying masses of desktop software but companies still do, particularly through licensing. Tablets haven't changed the way many people do work at work. At home perhaps, but not work.
I am not sure what your point is or why the size of the business is important to what software is being produced...?
You can use any definition you like. 50-ish employees?
>Do we need to have thousands of companies listed in order for their software to qualify as "software" in your eyes?
No, I just asked a simple question because I didn't know. I have no idea what you think you're replying to. But from your reply I get that you don't have the answer to my question.
>I am not sure what your point is or why the size of the business is important to what software is being produced...?
I just asked a question. I don't know of people starting companies to ship commercial windows software. Ofcource custom software development is certainly a vibrant domain, but that was not the focus of my question.
When you see tons of people starting companies to ship software on a platform - that gives you an idea (in general terms) of the 'profitability' of that platform in terms of small business being able to make some money. I have not seen that on the windows platform in quite a while.
I don't know why you're assuming I'm some kind of anti-native pro-web person. I'm primarily a low-level C++ programmer.
Apologies for the assumptions! I think you're right that the number of items being shipped on a platform is a good indication, but there's no real way to tell outside the walled gardens. There doesn't appear to be a massive take-up of the Metro app store, so I wonder if people are just ignoring it and still shipping native Win32 apps still? Or just nobody is writing anything?
You're right though - I haven't the answer to your question! I wonder where we can get some sort of metric of software being shipped for Windows? As nobody is really funnelling their software through the Windows store, it is probably impossible to get any concrete numbers.
My view is that the Metro app store will eventually take off. IMO Microsoft usually rushes to ship not-yet-finished products and which are then refined across successive versions/updates till people eventually accept them.
But as far as native apps go, I have not seen many SMEs pop up to ship commercial software on that. In contrast small businesses pop up all the time to ship iOS/Android apps.
Notice how everything he writes about mobile development is wrong?
>First of all, you have to do your mobile development twice
Nope, there are plenty of frameworks with large user bases, both OSS and with corporate backend to do it once. From Xamarin to PhoneGap. Especially 2D game developers are spoiled for choice.
>The devices are memory-starved, CPU-starved, and battery-starved.
The devices have never been better (obviously), and currently pack a 2005 era laptop power in the size of pack of cards and 1GB or more of memory. And the battery lasts the whole day, at least with the devices I'm familiar with.
>You don’t get a choice of languages; if you hate both Java and ObjC, get another job.
Really? Because there are iOS bindings for all popular languages (and I've used several) and I'd guess there are Android bindings too. Now, one can say that to be a great developer you also have to know Obj-C (which I'm familiar with), but that's in no way a prerequisite, just a nice-to-have. Plenty of people have built amazing things without learning Obj-C.
>Unit testing is a bitch.
Haven't found it such. Except if he means with all the Android flavors? That's orthogonal and inherent to mobile.
>Fortunately for your users but unfortunately for you, the UX-quality bar on mobile is high and there is no fast or cheap way through; it requires inspiration and iteration.
And that belongs in a list of reasons "mobile suchs" (sic), why?
>You can’t make money. Seriously, Apple is always talking about the billions and billions they pay out of the app store, so why is it that I don’t know anyone who’s making serious money on mobile apps?
Perhaps you don't have a lot of friends? Or friends in the right circles? Because for a market that "can't make money", they just paid $10 billion to developers.
I want to see some good Xamarin & PhoneGap apps, honestly the ones I've seen don't come close to natively built ones. Also if you are developing a game, you'd better stay far away from UIKit and do everything in OpenGL if you hope to get the same type of performance on Android using a translation tool.
The article is pretty much spot on. For most people who want to write great software, the client side is currently a mess.
Xamarin and Phonegap are completely different beasts. You are thinking about Phonegap now. Xamarin ones are natively built ones; you use Apple classes to build everything but just in C# instead of Objective-C. So you have to rebuild the frontend twice indeed for Android and iOS but it does look and function 'native' as if you did it with Xcode.
Phonegap => not so much; most just works like shit, but you only have to build once for a lot of platforms. It's a big reason for the proliferation of extremely bad apps in the Play store though; just wrapping of a website or form and putting it in as app.
Sorry, I got Xamarin confused with Titanium, which was a pretty bad experience for me for the week that I tried it. If I tried to do anything fancy, it was completely useless.
Also any time you are using 3rd party tools like Titanium / Xamarin to develop these apps it comes with gotchas / limitations that may not even be worth it in the end (it seems like Xamarin has less gotchas). The main issue is that you still have to do UI twice in the end (iOS & Android), and one more time for web.
Sure, but there aren't really any alternatives. When you build advanced apps HTML5 is depressing for apps at the moment. It will happen, but not this year.
>I want to see some good Xamarin & PhoneGap apps, honestly the ones I've seen don't come close to natively built ones.
I don't know, what's bad about these http://xamarin.com/apps , e.g. Rdio which I've used and is fine?
Xamarin is a binding to Cocoa and other libs, it doesn't recreate any UI itself. So the "don't come close to natively built ones" doesn't even make sense from a technical standpoint. Not to mention that C# is compiled AOT.
>The article is pretty much spot on. For most people who want to write great software, the client side is currently a mess.
The article isn't even about those people in the first place. He even laments that "UX-quality bar on mobile is high" as a reason why mobile sucks.
Which Xamarin apps that you've seen don't look native?
As others have pointed out, Xamarin provides C# bindings for the native APIs. It is fundamentally different to Phonegap, which takes a lowest-common-denominator Java/Swing approach.
> Nope, there are plenty of frameworks with large user bases, both OSS and with corporate backend to do it once. From Xamarin to PhoneGap. Especially 2D game developers are spoiled for choice.
With Xamarin you need to build the GUI twice as you are using the native classes per platform to build them, hence the excellent results.
2D games is a whole different ballgame; there are indeed 100s of platforms for devving 2d games on anything. But I think we are talking about apps; games is a solved problem already with Unity2D/3D, Corona, Haxe and many others.
The best phone I ever owned was a Nokia 6310i, and I had to charge it only once, occasionally twice a week. Now with all the advances in battery technology, phones barely last a day and there's a thriving market in external batteries and portable chargers. If I am not using any of the "smart" features on my smartphone, just calls and texts, I would expect it to last longer than that old Nokia, but I might get at best 2 days. Modern phone designs are horribly inefficient, and the consumer has just been forced to get used to it.
the consumer has just been forced to get used to it.
Have they? Why? Nokia still sells feature phones with good battery life. Hell, the new 105 lasts a month(!) on a single charge and you can get it on ebay for $30+shipping.
Nobody is forcing anything, people just like smartphones.
Which is nice and everything, but for me nowadays the phone part of a mobile device tends to be among the least used of its core features. For every call I make, I'm probably sending dozens of long text messages, taking dozens of high resolution photographs, reading dozens of web pages, listening to dozens of songs, investigating maps, writing notes and playing games.
We're no longer even talking about the same product segment. A modern smartphone is more of an iPod than a phone. More of a Palm Pilot than a phone. More of a GameBoy than a phone. More of a handheld GPS than a phone. More of a laptop than a phone. More of a camera than a phone.
These aren't inefficient phones, they're not phones.
When I turn off data on my Android phone to use it as a backup phone with my home SIM in, it does indeed last for weeks. Modern phone designs are a marvel of efficiency for what they're expected to do.
>The update cycles are slow. Days in the case of iOS ...
Last time I tried it was hours, although not instant as you might hope.
>What’s worse is that you can’t even count on people accepting the mobile-app updates you send them.
IOS7 tries to help this with automatic updating. Users still have the choice of updating but if you state in the release notes that it's a fix for "data-losing account-compromising privacy-infringing bug" they just might update.
Haven't found it such. Except if he means with all the Android flavors? That's orthogonal and inherent to mobile.
I assume he means that the tooling isn't as mature as that available for non-mobile, which I think is a fair comment. Running tests in the device or emulator is more involved, as is mocking apis for things like geolocation or the camera.
First of all, you have to do your mobile development twice
This is not wrong, in fact with Windows Phone and Firefox OS it'll soon become 3 x or 4 x, and more importantly compared to the web you have to make that choice of which to target, test and support - with web software it doesn't come up. The landscape for x-platform software is pretty limited, and having to use a framework like phonegap is far from ideal and leaves you beholden to that framework author for updates, performance, updating for new UIs like iOS 7, fixing bugs etc. That's not an enviable situation to be in and you shouldn't just dismiss it with a wave of the hand. Consumers are often hostile to apps made with html frameworks across platforms as well, because the performance isn't always good, and the platform makers are hostile to them because they break their ecosystem monopoly.
You don’t get a choice of languages; if you hate both Java and ObjC, get another job.
I do think it's a shame that the providers of these platforms lock them down to APIs in their chosen languages/frameworks - Apple have been getting better on this, but really there is no good reason to ban alternative browsing engines, and on all these platforms the platform vendors' aim is to lock you into their development tools, process and API, ideally to the exclusion of all others. Apple could have given webkit/x-platform development equal footing with native, but instead they have hindered it with substandard performance compared to the built-in browser.
Because for a market that "can't make money", they just paid $10 billion to developers.
I'd be very interested to see the breakdown on which developers have made all that money; I suspect it would be heavily skewed towards shady purveyors of skinner-box games like Zynga and big name game studios with lots of marketing behind them. It is possible for an indy to make money, but it's far harder than you might think depending on the segment you're in. I agree 'You can't make money' is patently false though, you can make money on mobile apps. In my experience though there's far more certain money in making them than in selling them.
My biggest complaints about mobile development are the capricious and arbitrary rules and judgements on whether apps get onto the device or not. That serves no-one but Apple/Google, and in the long term I suspect will doom their platform compared to more open alternatives like the web. Apple and Google want to control their consumers absolutely and take a cut on transactions, and use their tight grip on the app stores to make this a reality.
I don't see mobile overtaking the web though, quite the reverse in the long term. Coming from server-side development mobile app development can be frustrating because of the power the platform vendors exert over every stage of the process. That's not something to celebrate or paper over, it's a serious problem.
Just to take one example - Apple has banned developers from exploring any other payment system than their own for selling digital goods. That's a serious crimp on innovation, costs the customers and developers, and guarantees that Apple has a stranglehold on a huge emerging market and collects a vig on every transaction, to the detriment of competitors of theirs like Amazon and customers who just want to buy a book in their kindle app. Why should a single corporation control which books I read just because of the device I bought?
At least he points out that the situation on the browser side technically is equally broken and in need of improvement, with only one language available for client-side development.
> I do think it's a shame that the providers of these platforms lock them down to APIs in their chosen languages/frameworks
I never understand this point. All APIs are exposed via some protocol. Whether it's javascript, C, Objective-C or HTTP.
High-level APIs like HTML5 or Cocoa need to be exposed in a high-level language. The restrictions imposed by js or obj-c are an inescapable part of what make these environments better than what we used before.
Does anyone really want to go back to using thin wrappers around C APIs?
It's an interesting debate, and in particular UI bindings often need higher level access. I'm not convinced that the trade off of being locked into whatever Apple decides is the one true language and API is worth the gains though.
I'd be much happier with mobile dev if the situation was more like that of developing for the web - use any language you want as long as it can output HTML to be presented in the browser. That has been a limiting, but at the same time truly revolutionary, feature of web software which freed it from domination by large software vendors and restrictive practices like those we've seen on iOS or (to a lesser extent) Android.
If all the platform vendors had standardised on an API in say c as web browsers or unix have, we'd have a much more convincing case for mobile taking over the world and competing with the web - given the current situation of competing ecosystems with draconian restrictions I suspect they will all be subsumed by the web at some point.
> I'd be much happier with mobile dev if the situation was more like that of developing for the web - use any language you want as long as it can output HTML to be presented in the browser
On the server, that's definitely true. On the client, it's basically the same situation w/r/t languages. But this is a client/server distinction, not a native/web distinction.
Clients are just inherently coupled to the APIs that they use. Servers aren't so much. The coupling in languages reflects this.
> If all the platform vendors had standardised on an API in say c as web browsers or unix have, we'd have a much more convincing case for mobile taking over the world and competing with the web
That's an interesting point (although we'll then be totally locked to a particular platform/language on the client) and I think the web will eventually win. But not for a while.
At some point, the rate of progress on native will decrease and the advantages of standardization (cost, mostly) will overcome the disadvantages (lack of progress). It'll be interesting to see how the manafacturers adapt to that. I suspect that Google will do better than Apple.
They are indeed for desktop. As Objective-C becomes better (and it does it pretty fast, it has covered two decades of language development from 1970s to 1990s in just 7 years), most of the amateur iOS languages bindings become stale.
There are currently no high-quality, production-ready, native 3rd party language bindings for iOS that I know of, except for Xamarin mentioned above and Unity family.
In iOS 7 though, there's some activity in JavaScriptCore.framework on providing seamless integration between JavaScript and Objective-C.
Delphi lets you do single codebase iOS, android, windows and mac native apps that render their ui to opengl and are therefore really fast.
Ofcourse, you have to write objectpascal, which is not a popular language, but once you get over the weirdness it is more productive than C++ while still giving you pure native software. It even has closures these days :)
I second that request. Could you please include the links to mature production-ready bindings for some of the top programming languages from the TIOBE index?
In my pocket, maybe. I get to practically watch my battery indicator drain before my eyes trying to do any sort intensive activity, or (god forbid) watch video.
That may be true with Apple (WebGL please?), but I haven't felt that way about Google before. I've always seen Android as a means to an end for them, to get more people using the web. Any further reading?
I've always seen Android as a means to an end for them, to get more people using the web. Any further reading?
That used to be the story, but then it changed as a means to get people into Google services, and guess what: You don't need a web to do that.
The current state of Android is that all defaults, unless you override them and install third party apps, involve you logging into a Google account and storing and associating everything you do with that: Mail, Contacts, Calendar-data, Photos, Music, etc.
And to install third party apps, you need to log in with a Google+ account, and when you do that, the sync for all the above-mentioned things get activated.
Escaping the Google-creep is getting harder and harder on Android, so I seriously hope FirefoxOS, Jolla, Tizen or anything really will be getting somewhere and soon.
Android is not feeling quite as cozy as it used to anymore.
It's a means to an end for them in that it gets more people using their ecosystem, which means more personal data for them to harvest, which means ever-better targeted ads for people to click on, and ever-more-varied platforms on which to show said adverts.
I've always seen Chrome, Chrome OS and Android as first and foremost defensive products: if you control the OS you control the default browser, and if you control the browser you control the default search engine.
When you look at it that way these products are all very logical moves to protect Google's search business (and the very very lucrative ad business attached to it). The rest is added bonus.
The client-side mess? I just use MOAI. Lua is a lovely language, and the MOAI engine itself is so well thought out, that I can manage to build our client apps for Windows, Linux, MacOSX, Android, iOS, Chrome NaCL, and even HTML5+JS target platforms. With the exact same code.
At this point I just don't see any point to doing things natively. Actually, the tools that MOAI provides (and some of the other community frameworks that sit on top of MOAI, such as Hanappe or Flower) are decent enough, and contain all the basics, to implement pretty much any of the fancy GUI interactions seen elsewhere. And the appeal of being able to write an application that works - and looks the same - on all of the above platforms is just too great; in spite of the investment in learning a 'non-standard' framework, and in spite of the fact of nobody else knowing much about it (and thus no google'able answers to dodgy questions), I still feel this is the right direction to go. Especially since MOAI is open-source, and you can put the host VM anywhere you are capable (technical competence-wise) of doing it.
So I don't do native development for Apps any more. My ObjC/Java/C/C++ chops are still highly useful, but these chops are being used in a different context now: instead of writing a native app in one of these languages, I just write a host - and then use Lua to do the app logic. This is just so fun, I hope everyone starts doing it soon. ;P
To be frank, except for games (and even then it's not disagreeable to provide a nice, native UI), I disagree with you quite strongly. As is the usual case, language choice is completely arbitrary, but intentionally aiming for constancy across your narrow range of apps, instead of focusing on working to the platforms strengths is a very dangerous, and damaging approach to take imo.
Although i will say, i do not have a huge host of experience to go from, but this is from the perspective of someone who could potentially be your customer. With two apps at rough feature parity, i would pick the native app every single time, regardless of how nicely you've styled your app, at the end of the day the burden of proof lies on you; to prove the value of your app, if you cannot be bothered to create an appearance and functionality which is native, chances are that if you can't be bothered to do so, you've cut corners elsewhere.
I'm sorry if that comes across as presumptuous, perhaps i completely misunderstood what you're saying, or just jumped to conclusions, if so sorry, if not, i hope got my point across.
Its a valid concern to have, but the counter-argument is this: the app looks the same, and works the same, no matter what computer you're using. My users love that.
As an aside: Moai is great, but it has a problem with lack of developer activity, to the point that a cynical person could (especially with the abrupt shutdown of Moai Cloud) consider it to be abandoned.
For example, the current official Moai site's link to the downloadable SDK is broken, and there is currently nowhere to download the SDK; you have to build it yourself. There isn't even a proper official release beyond 1.3. And the current master branch has a bunch of outstanding issues, such as a Lua/C-binding-related segfault and the fact that you can't build the code with XCode 5.0.
Right now there are several unofficial forks that could become the new master. Unfortunately, of all the game companies that use Moai, very few of them seem to be contributing code back. At the very least some of them could get together to coordinate stewardship of the project, something which seems completely lacking right now.
Also, you are wrong about the lack of developer activity - unless you meant Zipline themselves, but we MOAI heads all know that Zipline are too busy making real products with MOAI at this point. Besides Zipline, the MOAI-using community is flourishing .. there is a de-facto effort to address the issues you mention (Binary SDK releases being one of the most important ones), and there has been a lot of progress in the last 6 months towards merging everyones' branches.
>At the very least some of them could get together to coordinate stewardship of the project, something which seems completely lacking right now.
Pay more attention to the forums at getmoai.com if you think this is the situation at the moment, because actually there is stewardship occurring by some of the core MOAI guys. The effort to pull all requests into a new branch and prepare for a community-release is definitely well under way, and you may indeed see the issues you brought up, addressed properly in a few weeks. MOAI is in the transition stages from being a proprietary (yet open) software stack developed by a single company, towards a proper community-supported effort like we all know and love. This will happen.
I had a bad experience years ago with the Genesis3D engine, which was similar to Moai -- open source, really easy to get productive with, an enthusiastic community. Then the company changed its strategy, abandoned the open source version, and the whole thing just collapsed. I wouldn't want to see the same thing happen with Moai.
What kind of apps are you writing in Moai? Games or something else?
I ask because there's a huge problem with rolling your own UI that you might not be aware of: accessibility for people with disabbilities, especially blind people. All of the major desktop and mobile platforms have accessibility APIs, which their native GUI toolkits (or dominant ones, in the case of desktop GNU/Linux) implement. These APIs are very tricky to get right in custom implementations; I've seen many projects get them wrong, especially on Windows, where I have the most experience with this stuff. If your app isn't something like a game that really can't be accessible to blind people unless it's specifically designed for them, then it pays to use the native UI toolkits.
I work in the Industrial sector - we do not have the requirement of supporting hindered folks. Rather, the GUI has to be operational in extreme conditions ..
> What’s worse is that you can’t even count on people accepting the mobile-app updates you send them.
There's a good reason for this: companies routinely push updates that either (1) change the user interface, usually for the worse (Google Maps), (2) remove functionality, or (3) introduce bugs/reduce stability (e.g. Viber). No wonder that customer's delay updating as much as possible.
Almost every time I update my apps, I'm sorry that I did it. The only reason I do it, is to remove the annoying Google Play icon in the statusbar.
(4) Many apps request new, intrusive, permissions for every update. I don't want to review the permission list all the time so any time an app requests something new i default to not update it. If the app worked good before without the permission why would it need more now?
It’s a pity some people still build important apps in PHP...
I wonder how that could be. It's almost like people chose to use PHP and it works for them. Like they made an informed decision and actually ended up going with PHP. Maybe they are just too dumb for their own good. Or maybe PHP is actually a perfectly sane choice for lots of cases outside of your FP ivory tower.
I don't use PHP, but I think the "Fractal of Bad Design" essay is well known about.
That's why I choose Django and Python when I wanted to do a web based app properly (as opposed to hacking something together quickly in Perl / CGI which is what I did know).
I have not regretted my choice so far. (No idea if I would have regretted using PHP, but Python does seem to do stuff well / properly most of the time).
i don't regard moving from xxx language to PHP.Is the point where if PHP don't support,use JAVA call.If both cannot support USE .NET.. for web i prefer PHP.For compile application i prefer VB.NET compare to PHP GTK..
His point about web vs iOS vs Android hit home with me. I've been a pure iOS developer for several years now, but the constant nag on me is to support Android. I assume it's the same for people that know the Android side. Unfortunately, it's not a 5 minute job to port over... if you take pride in building something great for one platform, you'll want to do the same on the other, but they have quite different paradigms, not to mention requiring a separate language and device set.
I guess in the past (on desktop) this wasn't as much of an issue because Windows had such a large market share.
If only Windows Phone had a greater market share. Despite being a UNIX guy I quite like it plus according to my colleagues (both of which are iOS and Android defectors respectively): You get to use a decent language (C#), Tooling is good and free, Apps are really scary fast, Unit testing is possible, One form factor, Approval is very fast and you can make money as the market isn't saturated to the point the SNR is against you.
Hear, hear. This is just one man's opinion, but Windows Phone 8 turned out to be a shockingly good mobile OS, the terrible market share of which is a combination of being late to the game and being a Microsoft product. It's a little sad that Microsoft's bad/monopolistic reputation of 10-15 years ago still hurts the products it releases today.
Altogether Windows Phone 8 is pretty phenomenal. The UI is head and shoulders above Android and iOS, and the perfect lockstep integration with C#/Visual Studio is a pleasure for development.
Software engineers are typically good at building things meant for other engineers. That's why some of the most robust, rock-solid, reliable pieces of software engineering are, e.g. OS kernels and language compilers. So Tim Bray is right in saying that we needn't worry about the server side. The server side is in good hands.
Also true that the client side sucks, and I see only one way of fixing it: engineers have to work in a highly disciplined, tyranical kind of an environment. For example, the reason you don't see a lot of technical error messages on iOS (and you do see them a lot on Android) is just that: someone has to constantly remind the engineers that software they are making is meant for humans, not engineers.
Engineers are humans... most of them anyway... I think.
"Software engineers are typically good at building things meant for other engineers."
You're not capturing the essence though, software engineers use Android as well as Linux on their desktops. I think it's more the way they approach user-interfaces. Engineers tend to reason from the bottom-up, but for good product design you also need to reason top-down. You can't just have a look at all the features you have engineered and then create some haphazard user-interface to expose them to the user and along the way pass along any error message that comes from any random subsystem directly to the user. There is no abstraction as leaky as a user-interface, I think that bothers engineers more than they are willing to admit.
"engineers have to work in a highly disciplined, tyranical kind of an environment"
That is not enough though, you also need someone who has the top-down perspective and product vision. Apple probably lacks both of these conditions right now, the usability of my iPhone is deteriorating so fast that I might as well switch to Android.
I'll be looking at ClojureScript in 2014. To me, the web is great despite all the difficulties, just because you can push stuff immediately. If only we could have skipped all the mobile "apps" stuff, and they would just be links to offline pages implemented with JS, NaCL, WebGL, etc..
I don't agree that mobile devices are resource-starved. Tim is an old hand so there must be concrete examples behind the words, but as stated I don't get it.
Also, it's quite easy to make fun of a language by stating one non-central feature that's counter-intuitive. End of the day, anyone working in a language seriously learns the corner cases and moves on. After a while, it's no longer relevant to them.
I did like the discussion of dynamic vs. static though. It really feels dynamic is good for early codebases and static for late. So why aren't there languages that allow you to move to static as your codebase matures? TypeScript adds optional typing but doesn't quite go the whole way unfortunately.
> I did like the discussion of dynamic vs. static though. It really feels dynamic is good for early codebases and static for late. So why aren't there languages that allow you to move to static as your codebase matures? TypeScript adds optional typing but doesn't quite go the whole way unfortunately.
I think that's a good idea. Maybe have a dynamically typed language, with other features that make dynamic languages good for using in a REPL and with more of a investigative programming style. And then have (another) language which is more static and have simpler runtime semantics, so that the language is easier to reason about but has less features that make it interactive. You might not even need the interactive features at a certain point, anyway, but it might be a problem if you want to move back to the more dynamic part in order to experiment with stuff. But that could perhaps be solved by making it possible to use the static language as the dynamic one, but not vice versa: for example if the difference is only in that the static one has type declarations and the dynamic one does not, simply ignore the type declarations and run it as the dynamic language, or defer it to be checked at runtime [0].
Someone in another thread brought up Typed Racket, which IIRC is implemented in Racket itself with macros.
My two cents: the ease of use of a platform is inversely proportional to the speed at which business needs move to remain competitive using it. The more rapidly business needs change, the less time a stable, elegant interface to the platform on which that business is based has to stabilize.
Business needs on the server side do not change terrifically fast. The things we needed to do on the server side has certainly changed over the past ten years, but the changes have been gradual. I struggle to name a single server-side upheaval as violent as the release of iOS or the demise of flash was to client-side. As a result, things are pretty well-understood. Thanks to POSIX and *nix, the operating system interface has been effectively static for at least a decade. Concurrency is hard to wrap your head around as a developer, but once you do you find that the actual tools you use have achieved something resembling stability. Persistence is one place that's actually seeing interesting changes with various database platforms coming into prominence, but if all else fails, you can get a decent amount of mileage out of good old SQL.
Client side programming, UI programming in particular, is where an application's most immediate value resides. As a result, it's where the most competition and development takes place, and so its interfaces and programming techniques are most changeable. Consumer-facing platforms come and go at a consumer-market pace. Platform providers like Google, Apple, and the W3C are constantly struggling to keep ahead of the manic pace both of of consumers' expectations regarding features and businesses' demand for capabilities. As a result, there are no time-honored abstractions like the Unix file system, or SQL, but rather a roiling soup of constant upheaval.
What's the takeaway? Rather than bemoaning the lack of stability in the client programming world, come to terms with the fact that you as a developer are going to have speed up. So long as client-side magic and consistency is a source of competitive advantage for applications, the state of the client-side programming art will continue to change rapidly. Things will get easier and harder as time goes by, but change and inconsistency are the natural order of this world.
A quick and illustrative addendum: There is one place where client side programming is stable and enjoys proven, reliable, and well-worn standards: enterprise applications. If you're ever in need of a reminder for what happens when a group of developers values stability and established pattern over staying at the head of the curve, log into your stockbroker's website, pour yourself a stuff drink to ease the pain, and go learn a new framework.
The author does not even touch on the ease of use for paying for content; in the case of in-app purchases the walled gardens are far ahead of the open web.
I'm not quite sure of what to make of his claim that he does not know of anyone who is making money from the walled gardens. Epic Games famously stated that Infinity Blade actually makes them more money than Gears of War when figured on a man-years vs revenue basis. http://www.ijailbreak.com/applications/infinity-blade-ios-ep...
I've come to the conclusion that "MVC" is the problem with web client apps. Now that there are several choices for doing MVVM using a functional reactive programming style, we really should move beyond the simplistic MVC concept.
>Since when FP is high performance and better concurrency support?
Lately I've been going back and forth between taking Udacity's Intro to Parallel Programming course (using CUDA, a C++ extension) and reading Learn You A Haskell For Great Good. I've found that while FP principles are cool to think about, they're also crucial for writing proper concurrent code.
If you write a kernel (a function executed by many threads in parallel) that produces side effects, you'll end up with a mess (since you can make no assumption about which threads will get to a particular part at which time). Furthermore, when you design parallel algorithms, knowing how monoids work is useful: you want to be doing operations that are associative and have empty implementations (+0, *1, AND true, OR false) so that they can be run in any order.
In short, Haskell forces you to stop thinking about the order in which your commands will be run, which is also a constraint imposed by parallelism.
Of course, when you are coding in such a way that you know what all of your shared resources are, sometimes it is convenient to be the one in charge.
I pretty much always go to a cooking analogy. Knowing how many spoons/dishes/ovens/stovetops/etc is critical to specifying an algorithm for making a large dinner. In many kitchens, you even have to account for how long it takes to clean said items to know how many you will need.
Basically, when designing an algorithm (or recipe), I think I fully agree with what you are saying. When you are designing the plan of attack on how something will actually be done, you typically have to go lower.
Now, I fully expect/hope that that part of the task could be done mechanically. I think it is safe to say that compilers aren't as far as many advocates put forth.
>Since when FP is high performance and better concurrency support?
FP is a huge step forward for concurrent development. The availability of immutable and (especially) persistent data structures is a key point in getting a concurrent application to work well. One of the core points behind FP is to reduce (or even remove) side effects in software development. Those side effects are what make concurrent development hell and unmaintainable. By logic, using FP makes concurrent development easier to handle.
As for performance, it's not that obvious whether or not FP is better or worse than other paradigms. Had you asked me ten years ago then the answer would've been obvious (it'd be worse) but interpreters, compiler development, type systems and all that jazz has improved a lot in the recent years.
For the majority that aren't concerned with realtime processing (total fine grained control isn't needed) concurrent FP is much simpler than the alternatives. FP code (ala Haskell) can also be very aggressively optimized.
Also, most of the time programmers shoot themselves in the foot with that total fine grained control some languages give. This doesn't mean they don't need to exist, just that FP can server a majority who think they need total control much better with more than acceptable performance.
"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.
I'll conceded that PHP in 2014 has some awesome frameworks but argue it doesn't matter because PHP was designed (very) badly from the beginning. BTW, PHP was my first language ;)
C# is well designed and I will admit that despite it still being more Microsoft specific (mono is getting there). We are stuck with Javascript, but can use it from better languages such as ClojureScript and Haskell via Fay.
I do need to give PHP a deeper look again, because it has changed quite a bit. If I were to hazard a guess though, there are still inconsistencies that will inspire too much paranoia for me to use it in production.
> The devices are memory-starved, CPU-starved, and battery-starved.
If memory is your problem in 2014 and you're not creating some data analyzer application, you might be doing something wrong. If CPU is your problem and you're not creating a game, I think you're really doing something wrong. Battery drain is the only real bottleneck. Frankly I'm surprised how fast it went and how fast mobile devices are nowadays. My phone is roughly twice as powerful as my server, both in terms of CPU and memory (CPU performance comparison based on benchmarks).
> The browser APIs suck too. Sufficiently so that jQuery (or equivalent) is regarded as the lowest level that any sane person would program to; in effect, the new Web assembler.
Hi there! You just met an insane person.
> There’s no app store for your browser-based client with anything like the scale and size and polish of those for mobile apps.
We figured out how to do search quite a while ago. And they all do content search, the thing you were complaining about that app stores didn't have. What do you mean there is no way to search for web applications?
Also ChromeOS is doing this, but frankly I don't want it. Applications that just run machine code are way more powerful. I use Google Docs only because it works better for concurrent collaboration in documents, there is no other reason, and that is the only web application that I still use (tried some more, all sucked). I use vim and plaintext markdown editors anytime I can, or occasionally libreoffice when I really need imagery in documents.
> Browsers suck too · This is an unfashionable opinion, but I can’t see why it’s controversial.
That is something I completely agree with, though I quite like Javascript (as long as it's not OOP, JS just isn't made for that and you have to abuse all kinds of things) I hate the DOM. Why would this be controversial?
Doubt you're a mobile dev. Phones may have gigs of ram but, for example, an Android app is capped at a 64MB heap. If your app has any large images that heap can fill with bitmaps quite quickly.
This blog almost immediately reminded me of grandma’s speech to Gil in the movie Parenthood. “…that a ride could make me so frightened, so scared, so sick, so excited and so thrilled all together. some didn’t like it. they went on the merry-go-round. that just goes around… nothing… I like the roller-coaster. you get more out of it”. Yes, there is a giant mess around building applications for today’s users! But that is where is the fun, excitement, and innovation is coming from. If you require safe, secure, and boring I’m sure there is bank somewhere in the world that need a good COBOL developer.
I'm betting on Ember.js or Angular (leaning towards Ember) to really take hold in 2014: it fixes everything that's currently wrong with the web front-end, and (if done right) is that last bit of magic missing from a native app.
Add to the mix some kind of Appcelerator/phone gap/something else that can be a thin wrapper around your web interface (but do it in a way that you can't tell it's not native and still have instant code pushes) and we've got ourselves a shiny roadmap to the future of development.
TL;DR - "Fortunately for your users but unfortunately for you," users in today's world expect amazing UX, on their platform of choice (largely iOS and Android), aren't willing to compromise on speed, usability, or access, and it means engineering is harder. We live in a world of amazing user experiences and products, and if that means more engineering work, so be it. If we limited our products to what's easy engineering wise, we'd still have crappy products and experiences.
"The client-side mess · Things are bad. You have to build everything three times: Web, iOS, Android. We’re talent-starved, this is egregious waste, and it’s really hurting us."
Not really, Xamarin did a good job of simplifying this (and you can use decent modern languages). HTML5/CSS/JS on the other hand is the real client-side mess - let's hope we will see more PNaCl/asm.js developments for non-game applications in 2014.
I think browsers are great from a user perspective. Everyone knows browsers, they are familiar with using them, navigating with them and all importantly making purchases.
Coding with Javascript I agree can be like working with one hand tied behind your back, just because of its limitations, but you know what, loads of us can build apps with this and we can be guaranteed it will work on most devices!
I imagine Dart may provide a better playing field for the developer in the future.
>Mobile sucks.
I tend to agree, although Xamarin and Titanium are trying to help.
>UX-quality bar on mobile is high and there is no fast or cheap way through; it requires inspiration and iteration.
I think Microsoft went a lonq way with Windows 8 "Metro" style design to basically tell developers, "build this way" then we should have great consistency with UX across mobile app landscapes
> I imagine Dart may provide a better playing field for the
> developer in the future.
It was mostly igonred in comments but Bray did get at least one point right: the gazzilion of JS frameworks and none really solving the problem. Replacing Javascript with Dart will not solve the problem. I doubt it will be ever sold, really, and wish people stop trying to pull web tech by the ears. Other platforms offer you mature and complete frameworks, web has none of that. I hope to see the day when people realize that "Internet enabled" does not mean "HTML enabled" and get back to "the right tool for the job".
I used to think JavaScript sucked until I read a JavaScript pattern/anti-pattern book. I then realized it was I who sucked. IMO JavaScript is perfectly suited for its environment.
As someone who is just starting to learn Java and ObjC, am I going down the wrong path? I'm sure this guy is exaggerating to a degree, but I'm not sure how much.
Don't let an opinion piece posted to Hacker News do much to influence your choice of languages. Everyone has opinions and most of them are equally valid (or invalid).
If you want to write mobile apps, you're pretty much stuck writing in those languages or using a framework that does the cross-platform shenanigans for you. Or writing web apps exclusively that have mobile browser support.
Regardless, neither Java nor Obj-C is going away anytime soon, so it would not be a mistake to learn either or both.
A bug in my code doesn't make javascript horrible, it makes me horrible for rushing to illustrate a point instead of just harrumphing internally and finishing my coffee.
True, JS doesn't ship with a large standard library. But that has turned out to be one of its greatest strengths and a key reason for it's runaway success.
The point is not that it's impossible to numerically sort an array of numbers in JavaScript; it's that calling the sort function on such an array doesn't do that. That's a surprise to most developers, I'm sure, and surprises in languages and libraries are bad.
One of the benefits of "really functional" code is that without lots of side-effects and mutable state, it is easy to parallelise things. But if "you’re single threaded" as node.js is, you aren't going to get those benefits anyway, s it doesn't matter.
There are performance benefits to the asynchrony that node.js's callbacks give you - i.e. the single thread that you have doesn't block waiting for things to complete and can handle other requests in the meantime. But this isn't really parallelisation.
Javascript does not have threads, so the only way to use it on the server with decent multiuser performance is with async I/O and callbacks. So he's saying people are using NodeJS because it made it possible to write server-side apps, regardless of its other features.
While search engines aid in discovery, they are not an easy way for customers to "buy" apps by just entering a password associated with their phone account.
What, did desktop GUI application development suddenly disappear? There's many classes of software, especially line of business ones, where desktop is pretty dominant.
Firefox and Ubuntu are blazing the trails in the mobile client unification.
It's just too early to notice.
We need more devices with Firefox OS and Ubuntu installed. Web developers will come en masse to show you how it should have been done from the beginning.
One app, searchable, upgradable, that runs everywhere.
> 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)