Software in 2014
tbray.org
tbray.org
> 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)
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.
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.
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?
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.
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.
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.)
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.
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.
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...
Swap tablets for phones then and the GP's point stands.
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.
Not bogus at all.
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.
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.
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.
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.
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.
So what you're saying is that in a couple of years mobile phones will be as powerful as today's desktops and laptops?
So any applications you design now that you expect to be relevant in a few years time need to take that into account.
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.
> 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.
I'll get the first round.
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.
No. People want a way to quickly use new software. It's just that the easiest way to achieve this today is providing applications via the browser.
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.
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.
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.
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.
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".
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.
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.
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.
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.
Sure, there were technical arguments, but you're naive if you think that they key to the decision.
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.
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.
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.
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"
lol, sir, lol.
Getting real tired of seeing these baseless statements from so called software professionals.
Here is an off-the-top-of-my-head list of features of modern day PHP:
* yield
* event
* pthreads - yeap, real threads.
* closures (including support for $this)
* consistent hashing api
* "finally" added to try-catch
* empty() now supports expressions, rather than only variables.
* array and string literal dereferencing
* foreach support for list() - foreach($array as list($var, $var))
* array_column
* traits
* short array syntax
* namespaces
* json manipulation is second to none.
* runkit - all kinds of danger here
-- Rasmus Lerdorf
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.
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.
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.
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.
But is it solving more problems than it creates?
Where will Perl 6 sit when/if it becomes something you could realistically use? Would you classify it as one of the bad tools or a newer, better one?
"it's not very liked one due to it's flaws", PHP is very well liked, just not by everyone .. which goes for most things in life.
If you really need it, here's a very good write-up which should cover that in an impressively detailed manner:
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
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.
http://forums.devshed.com/php-development-5/php-is-a-fractal...
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.
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.
At the time it was reasonable .. but PHP evolved and learned lessons, it didn't just stop there as you seem to be saying.
Why is exposing a C library's functions and their names PHP's fault?
[1] http://dev.mysql.com/doc/refman/5.5/en/mysql-escape-string.h... [2] http://dev.mysql.com/doc/refman/5.5/en/mysql-real-escape-str...
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.
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.
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. :)
edit: you know what would be great, if you could show some common programming examples in PHP and how Go would manage the same situation.
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.
You're calling this guy[1] a 'so-called software professional' because he criticised PHP?
* closures (including support for $this)
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.
However the objection people, including myself, have with PHP is that the legacy stuff is inconsistent junk.
I still use it on occasion but it pains me.
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.
As to parameter ordering .. I've been using PHP for so long now that they've been memory to committed ;)
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.
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.
Here's a good start - and I'll bet that Heroku's free tier is a better option than most $5/month PHP webhosts:
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).
[0] https://github.com/jsebrech/php-o
[1] http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...
Even if a handful of those issues have been addressed in the intervening 15 months, the depth and breadth of fundamental problems remains. /$.02
There's a lot wrong with PHP, and that'd be the case if even a quarter of the points in the article I linked to were valid.
PS Feel free to get the last word in after this, I don't plan to reply again since it's not very constructive. Have a nice day.
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.
PHP with these features has become more of a headache.
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.
Anyone else?
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 =].
Worth checking out.
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.
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.
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...?
>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.
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.
Apologies again for the assumptions.
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.
>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.
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 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?
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.
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.
The article is pretty much spot on. For most people who want to write great software, the client side is currently a mess.
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.
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.
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.
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.
Out of those, I use Rdio daily and played Bastion a lot and they work great. I didn't know they were made with Mono until now.
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.
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.
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.
Unless it's christmas, in which case you have to wait a week
How about an app that exploits the user, damages the phone through some sandboxing hole, and whatever?
Sure, those can still happen even with checks, but a whole bunch of them is removed.
(And yes, people have used updates in the past to pass malicious changes to apps).
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.
Care to list some, other than Xamarin and RubyMotion?
There are Cocoa bindings for a number of languages [3], but I'm fairly certain they are desktop-only.
[1] http://fsharp.org/use/ios/
[2] https://forums.xamarin.com/discussion/3465/f-language-bindin...
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.
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 :)
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.
The biggest problem is the conflict of interest between the major browser makers in that they are also handheld device makers.
They have every incentive to keep the browser dumb in order to keep devs using java/objc and staying on their platform.
Firefox is really the only thing that has the influence and power to "save us" (obviously barring anything unpredictable).
But last I checked, they were still bankrolled by Google, and their browser has stale market share.
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.
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.
It's IE6 all over again :(
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
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.
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.
With great power comes great responsibility.
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.
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.
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.
So, for now, I just turn off updates and the update notification in Play / Market and then keep backups of the APKs every so often so you can go back.
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.
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 guess in the past (on desktop) this wasn't as much of an issue because Windows had such a large market share.
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.
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.
Can you elaborate on this?
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 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.
http://docs.racket-lang.org/ts-guide/
[0] in GHC Haskell you can use a flag to defer type errors to be checked at runtime:
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.
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...
In app purchases are usually pretty optional as is content.
Here is one pointer to more info http://christophermeiklejohn.com/frp/javascript/clojurescrip... and down near the bottom he has a link to the HN discussion of his article.
PHP/Spring only sucks if you dont know how to use.
Functional Programming is getting a foothold on the mainstream, because if you care about performance you care about concurrency
Since when FP is high performance and better concurrency support?
Pick the right tool please.
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.
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.
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.
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.
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 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.
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?
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.
"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.
And here I am naively assuming that Snowden et al. at least taught us that nothing should talk HTTP anymore and everything should talk at least HTTPS.
Maybe 2015 then.
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.
> function byNum(a,b) {return +a>+b}
undefined
> [5, 10, 1].sort(byNum)
[1, 5, 10]
> [10, 1, 5, 1, 10, 10, 1, 5, 5, 5, 10].sort(byNum)
> [10, 10, 5, 1, 10, 1, 1, 5, 5, 5, 10]
> function byNum(a, b) { return a - b; }Good catch.
See "runaway chain reaction".
[5, 10, 1].sort(function(a, b) { return a - b })
Or, in ES6:
[5, 10, 1].sort((a, b) => { a - b })
That's starting to look pretty nice if you ask me.
Anyone could elaborate on what this actually means?
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.
[5, 10, 1].sort(function(a,b){return a - b});I think google (or other search engines) are the open webs equivalent of an "app store"
Treat .sort() without a sorting function as undefined behavior. Voilà.
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.