
Software in 2014 - AndrewDucker
https://www.tbray.org/ongoing/When/201x/2014/01/01/Software-in-2014
======
weland
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)

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

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

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

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

~~~
rubinelli
That's my understanding, too. Developers are using high-level frameworks that
generate an absurd number of redraws. In many cases, the bottleneck isn't even
the CPU or the memory, but simply pushing too many pixels to the screen. It
doesn't help that we expect much snappier response from touch interfaces than
from 10-year-old desktops. Two seconds to open a new screen was somewhat
acceptable in a VB6 application. Try to do that in an Android app, and see the
kind of rating you get.

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

~~~
stiff
_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

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

~~~
dscrd
Can you have a long-running process on PHP these days? I thought it still
wasn't an option.

~~~
xd
I've been running long running process's with PHP for well over 8 years now.

~~~
dscrd
How did you deal with the resource leaks before PHP 5.3, which was released in
2009?

~~~
xd
I steered clear of circular references.

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

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

~~~
72deluxe
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.

~~~
ksk
How many small businesses are making money shipping software on windows ?

~~~
72deluxe
What classes as a small business? Up to what size? I don't have figures but I
have worked for 2 in the past that wrote software for Windows, one solely
existing for the software, the other for complimenting their services with a
side software product. They managed to turnover > £1million and >£4 million
respectively.

Do we need to have thousands of companies listed in order for their software
to qualify as "software" in your eyes?

The main point was that Tim ignored desktop native software in his analysis of
software, which I felt was an oversight given that probably 98% of jobs
involving a computer use desktop software all day long, software that was
purchased. I do not see Doris in the admin office using a web browser all day
long for her job.

Just because you and I might not be buying desktop software in droves does not
mean that there isn't a market for it, a pretty sizeable market. Home users
might not be buying masses of desktop software but companies still do,
particularly through licensing. Tablets haven't changed the way many people do
work at work. At home perhaps, but not work.

I am not sure what your point is or why the size of the business is important
to what software is being produced...?

~~~
ksk
You can use any definition you like. 50-ish employees?

>Do we need to have thousands of companies listed in order for their software
to qualify as "software" in your eyes?

No, I just asked a simple question because I didn't know. I have no idea what
you think you're replying to. But from your reply I get that you don't have
the answer to my question.

>I am not sure what your point is or why the size of the business is important
to what software is being produced...?

I just asked a question. I don't know of people starting companies to ship
commercial windows software. Ofcource custom software development is certainly
a vibrant domain, but that was not the focus of my question.

When you see tons of people starting companies to ship software on a platform
- that gives you an idea (in general terms) of the 'profitability' of that
platform in terms of small business being able to make some money. I have not
seen that on the windows platform in quite a while.

I don't know why you're assuming I'm some kind of anti-native pro-web person.
I'm primarily a low-level C++ programmer.

~~~
72deluxe
Apologies for the assumptions! I think you're right that the number of items
being shipped on a platform is a good indication, but there's no real way to
tell outside the walled gardens. There doesn't appear to be a massive take-up
of the Metro app store, so I wonder if people are just ignoring it and still
shipping native Win32 apps still? Or just nobody is writing anything?

You're right though - I haven't the answer to your question! I wonder where we
can get some sort of metric of software being shipped for Windows? As nobody
is really funnelling their software through the Windows store, it is probably
impossible to get any concrete numbers.

Apologies again for the assumptions.

~~~
ksk
Heh, no need for any apologies.

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.

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

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

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

~~~
weixiyen
Sorry, I got Xamarin confused with Titanium, which was a pretty bad experience
for me for the week that I tried it. If I tried to do anything fancy, it was
completely useless.

Also any time you are using 3rd party tools like Titanium / Xamarin to develop
these apps it comes with gotchas / limitations that may not even be worth it
in the end (it seems like Xamarin has less gotchas). The main issue is that
you still have to do UI twice in the end (iOS & Android), and one more time
for web.

~~~
tluyben2
Sure, but there aren't really any alternatives. When you build advanced apps
HTML5 is depressing for apps at the moment. It will happen, but not this year.

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

~~~
Xixi
I've always seen Chrome, Chrome OS and Android as first and foremost defensive
products: if you control the OS you control the default browser, and if you
control the browser you control the default search engine.

When you look at it that way these products are all very logical moves to
protect Google's search business (and the very very lucrative ad business
attached to it). The rest is added bonus.

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

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

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

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

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

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

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

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

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

~~~
pilsetnieks
There were some changes in iOS7 that he didn't like. Hence, Apple is doomed.

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

------
alexandros
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
> 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/](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](https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime)

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

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

------
brisance
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...](http://www.ijailbreak.com/applications/infinity-blade-ios-epic-games-
successful-game/)

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

In app purchases are usually pretty optional as is content.

------
memracom
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...](http://christophermeiklejohn.com/frp/javascript/clojurescript/2013/06/13/functional-
reactive-programming.html) and down near the bottom he has a link to the HN
discussion of his article.

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

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

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

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

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

~~~
codygman
C# is well designed and I will admit that despite it still being more
Microsoft specific (mono is getting there). We are stuck with Javascript, but
can use it from better languages such as ClojureScript and Haskell via Fay.

I do need to give PHP a deeper look again, because it has changed quite a bit.
If I were to hazard a guess though, there are still inconsistencies that will
inspire too much paranoia for me to use it in production.

------
lucb1e
> The de­vices are mem­ory-starved, CPU-starved, and bat­tery-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
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.

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

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

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

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

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

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

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

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

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

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

------
ceautery
"JavaScript is horrible."

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

No, it's not.

~~~
i2
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; }

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

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

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

------
tracker1
The JS sort example was interesting... solution.

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

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

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

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

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

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

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

------
Eleutheria
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
Awfully late to displace iOS/Android

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

~~~
ragecore
I thought ranting about PHP and JS was so 2013

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

