Software in 2014

https://www.tbray.org/ongoing/When/201x/2014/01/01/Software-in-2014

by AndrewDucker • 13 years ago

471 256 13 years ago

tbray.org

rmrfrmrf• 13 years ago

Save yourself a click -- it's another PHP and JavaScript rant.

joe_fishfish2• 13 years ago

It's not at all, it's a rant on the massive disparity between server-side and client-side development.

muhuk• 13 years ago

I am in your debt.

ragecore• 13 years ago

I thought ranting about PHP and JS was so 2013

cothomps• 13 years ago

.. and ranting about Spring is about what, 2006?

hayksaakian• 13 years ago

I agree the client side situation is a mess, but I think its getting better.

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.

lucaspiller• 13 years ago

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?

joe_fishfish2• 13 years ago

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.

josteink3• 13 years ago

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.

kalleboo3• 13 years ago

They have every incentive to keep the browser dumb in order to keep devs using java/objc and staying on their platform.

It's IE6 all over again :(

xd13• 13 years ago

"It’s a pity some people still build important apps in PHP..."

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

thirdsight3• 13 years ago

Those are great features.

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.

xd13• 13 years ago

PHP is making strides to remove legacy pain points. Check the changelogs i.e. http://php.net/ChangeLog-5.php#5.4.0

As to parameter ordering .. I've been using PHP for so long now that they've been memory to committed ;)

coldtea5• 13 years ago

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.

enneff3• 13 years ago

So what? Part of the reason PHP is such a disgusting mess is because it is a raft of haphazardly accumulated features.

xd13• 13 years ago

For someone that works on Go at Google I'm shocked by your very much subjective view of PHP. Elitist much?

grey-area6• 13 years ago

baseless statements from so called software professionals

You're calling this guy[1] a 'so-called software professional' because he criticised PHP?

[1] http://en.wikipedia.org/wiki/Tim_Bray

pgeorgi• 13 years ago

To be fair, he _did_ bring XML upon us...

stiff• 13 years ago

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.

-- Rasmus Lerdorf

andyroid• 13 years ago

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.

poolpool• 13 years ago

For all the folks getting excited about my quotes. Here is another - Yes, I am a terrible coder, but I am probably still better than you :) @rasmus

jokoon6• 13 years ago

I agree, but that can't really work on the long term...

thejosh• 13 years ago

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

qwerta• 13 years ago

I think this would apply to early Ruby On Rails. PHP libs and interpreter are actually fairly good.

mseebach2• 13 years ago

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.

lsh3• 13 years ago

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

JackMorgan• 13 years ago

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.

daGrevis• 13 years ago

Should I be impressed? Mess on top of existing mess. :(

chrisweekly2• 13 years ago

For me, this is the definitive take-down of PHP: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Even if a handful of those issues have been addressed in the intervening 15 months, the depth and breadth of fundamental problems remains. /$.02

xd13• 13 years ago

Obviously you believe everything you read on the internet without question .. https://news.ycombinator.com/item?id=7030283

Sanddancer• 13 years ago

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.

abvdasker2• 13 years ago

Call me crazy, but PHP JSON manipulation is maybe second to node.

krapp2• 13 years ago

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.

dscrd3• 13 years ago

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.

Joeri3• 13 years ago

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

[0] https://github.com/jsebrech/php-o

[1] http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...

krapp2• 13 years ago

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.

antocv• 13 years ago

Throwing a bunch of buzzwords or features at the problem doesnt mean the language magically becomes elegant, consistent and logical.

PHP with these features has become more of a headache.

paukiatwee• 13 years ago

It’s a pity some people still build important apps in PHP and Spring

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.

idProQuo• 13 years ago

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.

taeric2• 13 years ago

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.

Morgawr2• 13 years ago

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.

codygman5• 13 years ago

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.

tomp• 13 years ago

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.

72deluxe5• 13 years ago

Haha this is so true! Maps became rubbish after the update. The same goes for Hangouts replacing Talk.

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.

Too• 13 years ago

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

brisance• 13 years ago

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

thirdsight3• 13 years ago

I wouldn't say that. Subscriptions are far easier to take on the web.

In app purchases are usually pretty optional as is content.

troels• 13 years ago

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.

collyw• 13 years ago

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

codygman5• 13 years ago

FP Ivory tower? There are plenty of imperative only programmers who believe PHP isn't a sane choice.

alien3d2• 13 years ago

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

morkbot• 13 years ago

"NodeJS isn’t really functional, but if everything’s a callback and you’re single threaded, who cares?"

Anyone could elaborate on what this actually means?

mrich• 13 years ago

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.

SideburnsOfDoom• 13 years ago

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.

mojuba• 13 years ago

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.

rejschaap• 13 years ago

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

pikachu_is_cool• 13 years ago

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?

cclogg• 13 years ago

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.

coldtea5• 13 years ago

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.

weixiyen2• 13 years ago

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.

glassx• 13 years ago

There's an App Showcase on Xamarin's website: http://xamarin.com/apps

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.

coldtea5• 13 years ago

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.

tluyben23• 13 years ago

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.

andyjohnson03• 13 years ago

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.

oe• 13 years ago

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.

kalleboo3• 13 years ago

Last time I tried it was hours, although not instant as you might hope.

Unless it's christmas, in which case you have to wait a week

acgourley• 13 years ago

App store review times? It's generally 5 business days.

gaius• 13 years ago

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.

icebraining2• 13 years ago

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.

kalleboo3• 13 years ago

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.

sjwright• 13 years ago

The best phone I ever owned was a Nokia 6310i

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.

grey-area6• 13 years ago

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.

chrisdevereux2• 13 years ago

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?

tluyben23• 13 years ago

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.

kranner• 13 years ago

there are iOS bindings for all popular languages (and I've used several)

Care to list some, other than Xamarin and RubyMotion?

andyjohnson03• 13 years ago

There are iOS bindings for F# [1] with some level of support from Xamarin [2]. I'm not aware of any others.

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

[3] http://en.wikipedia.org/wiki/Cocoa_(API)#Other_bindings

smikhanov2• 13 years ago

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?

Joeri3• 13 years ago

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 :)

http://www.embarcadero.com/products/delphi

andyjohnson03• 13 years ago

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.

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.

BlackDeath32• 13 years ago

the battery lasts the whole day

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.

coldtea5• 13 years ago

Well, compare apples to apples though. Were you watching much 720/1080p video on those old featurephones the guy yearns for?

thirdsight3• 13 years ago

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.

abvdasker2• 13 years ago

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.

fit2rule4• 13 years ago

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

Alphasite_2• 13 years ago

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.

fit2rule4• 13 years ago

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.

lobster_johnson2• 13 years ago

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.

fit2rule4• 13 years ago

you have to build it yourself

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.

mwcampbell• 13 years ago

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.

fit2rule4• 13 years ago

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

CmonDev• 13 years ago

No mention of Midori/M# (unlike Rust).

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

weland10• 13 years ago

I think this paints a rather meagre picture of software development in 2014:

More or less everything is expected to talk HTTP, and it’s really easy to make things talk HTTP.

A lot of things that shouldn't talk HTTP are expected to just because there's an army of programmers who don't know better. Also, it's actually hard to make things talk HTTP, partly due to HTTP itself. However, much of this complexity is hidden, leaving people to think that

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

In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved?

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

Browsers suck too

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

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

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

talkingquickly2• 13 years ago

Browsers are fine as long as you use them for what they are meant to be used

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

jokoon6• 13 years ago

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

_pmf_2• 13 years ago

A lot of people now want to use their browser for far more than that

No. People want a way to quickly use new software. It's just that the easiest way to achieve this today is providing applications via the browser.

jokoon6• 13 years ago

In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved?

Those CPU don't have as much cache memory (which is vital for a CPU to be fast), are very low powered, and not cooled by any fan. Even my $50 nokia can do 3D, 3D acceleration doesn't mean it's a fast device. CPU frequency doesn't mean it's a muscly device either. You'll always need power for fast computing, and multithreading without adapted programming paradigm lead you nowhere. Those chips are very much different than your desktop's.

Many things are already preoptimized on the kernel level, but it doesn't change the fact that even html and javascript parsers, which parse text, will be slower on those devices. If you make an app for a smartphone, you can't really have even one third of the expectations you have on a desktop or laptop computer. Optimizing will be mandatory, and that's a huge disadvantage because most developers are not trained for that.

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

weland10• 13 years ago

Those CPU don't have as much cache memory (which is vital for a CPU to be fast), are very low powered, and not cooled by any fan.

They are, nonetheless, far more powerful than computers which ten years ago ran comparable applications of comparable feature and comparable eye candy complexity (if somewhat lacking in design taste).

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

Cache memory is not vital for a CPU "to be fast" in every situation, it's vital for a CPU to be fast with bulk data. If you're working on bits and pieces of information that are hundreds of bytes in length, low cache count is no excuse to be slow.

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

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

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

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

Edit:

Performance will bite you on mobile software.

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

revelation• 13 years ago

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.

simonh• 13 years ago

If you make an app for a smartphone, you can't really have even one third of the expectations you have on a desktop or laptop computer.

So what you're saying is that in a couple of years mobile phones will be as powerful as today's desktops and laptops?

So any applications you design now that you expect to be relevant in a few years time need to take that into account.

annnnd• 13 years ago

the bogus "optimizing is evil" knuth quote.

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

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

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

Not bogus at all.

pjmlp• 13 years ago

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

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

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

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

integricho• 13 years ago

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

bluetomcat2• 13 years ago

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

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

Quarrelsome2• 13 years ago

In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved?

Sounds to me like you've never developed seriously on an ARM chipset. These devices are worlds apart from your standard desktop, there is a reason that both Android and IOS dropped Adobe flash. It's partly the hardware and partly shitty ARM code, its not really much to do with the specs. I can do things much more easily on an underpowered x86 than an overpowered ARM.

weland10• 13 years ago

Sounds to me like you've never developed seriously on an ARM chipset.

You're selling cucumbers to the gardener, I was actually one career choice away from designing chips, and wrote ARM assembly before there was anything such as a tablet.

A mobile phone is slow in comparison to a desktop, but not slow enough to afford an excuse for lagging in most of today's mobile applications. If a Facebook client, a mail application, a simple 2D game or a music player lags on such a mobile phone, it does so because it's a piece of crap.

ZanyProgrammer• 13 years ago

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

corresation• 13 years ago

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.

stephencanon• 13 years ago

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.

gclaramunt• 13 years ago

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

lsh3• 13 years ago

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

A lot of things that shouldn't talk HTTP are expected to just because there's an army of programmers who don't know better.

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

weland10• 13 years ago

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

bad_user• 13 years ago

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

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

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

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

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

bruceboughton2• 13 years ago

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

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

weland10• 13 years ago

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

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

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

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

tracker12• 13 years ago

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

10098• 13 years ago

A lot of things that shouldn't talk HTTP are expected to just because there's an army of programmers who don't know better.

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

deeviant• 13 years ago

Take a look at http://kentonv.github.io/capnproto/

xyzzyz• 13 years ago

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

protomyth• 13 years ago

In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved?

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

weland10• 13 years ago

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

pistle• 13 years ago

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

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

There's plenty of power there, but code will bloat to fill all resources. You said it. "...complexity is hidden"

saber_taylor• 13 years ago

HTTP is used since it won't be firewalled.

auvrw• 13 years ago

In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved?

lol, sir, lol.

ceautery2• 13 years ago

"JavaScript is horrible."

  > function byNum(a,b) {return +a>+b}
    undefined
  > [5, 10, 1].sort(byNum)
    [1, 5, 10]

No, it's not.

Morgawr2• 13 years ago

that looks pretty horrible if you ask me

twerquie3• 13 years ago

It can (and should!) be written more elegantly

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

Dirlewanger• 13 years ago

Writing your own method to solve a problem every other language does out of the box is missing the point...

twerquie3• 13 years ago

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.

i2• 13 years ago

Except it is, because your code doesn't work:

  > [10, 1, 5, 1, 10, 10, 1, 5, 5, 5, 10].sort(byNum)
  > [10, 10, 5, 1, 10, 1, 1, 5, 5, 5, 10]

The right way is

  > function byNum(a, b) { return a - b; }

ceautery2• 13 years ago

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.

Good catch.

kelseyfrancis• 13 years ago

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.

kriro• 13 years ago

"""More or less everything is expected to talk HTTP, and it’s really easy to make things talk HTTP."""

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.

72deluxe5• 13 years ago

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.

Anyone else?

ksk6• 13 years ago

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.

72deluxe5• 13 years ago

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.

orthecreedence• 13 years ago

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

Worth checking out.

was_hellbanned• 13 years ago

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.

alexandros• 13 years ago

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.

Dewie• 13 years ago

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:

https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime

swah• 13 years ago

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

shaydoc• 13 years ago

Browsers suck too.

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

rimantas• 13 years ago

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

alien3d2• 13 years ago

have you got new customer wanted ie7 comp?thanks oracle form

kayoone3• 13 years ago

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

codygman5• 13 years ago

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 ;)

kayoone3• 13 years ago

Every languages has its strenghts and weaknesses. I worked a lot with C# lately and love it, but i still enjoy modern PHP and Javascript.

Eleutheria• 13 years ago

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.

pswenson• 13 years ago

Awfully late to displace iOS/Android

memracom2• 13 years ago

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.

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.

warfangle• 13 years ago

JavaScript is horrible. > [5, 10, 1].sort(); > [ 1, 10, 5 ]

Treat .sort() without a sorting function as undefined behavior. Voilà.

jfasi2• 13 years ago

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.

jfasi2• 13 years ago

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.

Lorenzo45• 13 years ago

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.

sleazebreeze• 13 years ago

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.

cehlen• 13 years ago

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.

FrankenPC• 13 years ago

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.

lucb1e• 13 years ago

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?

jayd16• 13 years ago

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.

cabbeer• 13 years ago

There’s no app store for your browser-based client with anything like the scale and size and polish of those for mobile apps.

I think google (or other search engines) are the open webs equivalent of an "app store"

jaredsohn• 13 years ago

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.

tracker12• 13 years ago

The JS sort example was interesting... solution.

    [5, 10, 1].sort(function(a,b){return a - b});

eonil• 13 years ago

Nice summary. Anyway, it seems he haven't tried Go seriously yet.

arieldiaz• 13 years ago

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.

lutorm• 13 years ago

Software != web software. Plenty of us write software that never touches either an HTTP server or browser.

damian2000• 13 years ago

What, did desktop GUI application development suddenly disappear? There's many classes of software, especially line of business ones, where desktop is pretty dominant.

christiangenco• 13 years ago

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.

Software in 2014

Related Stories