19 ms·

Software in 2014

471 points by AndrewDucker 13y ago

deleted 13y ago
[deleted]
rmrfrmrf 13y ago
Save yourself a click -- it's another PHP and JavaScript rant.
- joe_fishfish 13y ago
  It's not at all, it's a rant on the massive disparity between server-side and client-side development.
- muhuk 13y ago
  I am in your debt.
- ragecore 13y ago
  I thought ranting about PHP and JS was so 2013
  - cothomps 13y ago
    .. and ranting about Spring is about what, 2006?
hayksaakian 13y 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 13y 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_fishfish 13y 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.
    - Xixi 13y ago
      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.
  - josteink 13y 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.
- kalleboo 13y ago
xd 13y 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
- enneff 13y ago
  So what? Part of the reason PHP is such a disgusting mess is because it is a raft of haphazardly accumulated features.
  - xd 13y ago
    For someone that works on Go at Google I'm shocked by your very much subjective view of PHP. Elitist much?
    - ciupicri 13y ago
      It's not just his view, there are other people who feel the same way about PHP.
    - dmak 13y ago
      That comment didn't even come across as elitist. There was no need to get personal.
      - xd 13y ago
        He works on Go at Google. A skilled professional no doubt, could he not have made some valid points rather than simply calling PHP disgusting. It didn't add anything to the conversation. If you where in the pub and someone spent some time listing the virtues of the pint they where drinking, and then someone joined in the conversation and called it disgusting with no basis .. wouldn't you find that to be odd behavior?
paukiatwee 13y 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 13y 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.
  - taeric 13y 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.
- Morgawr 13y ago
tomp 13y 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.
- 72deluxe 13y 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 13y 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 13y 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-epic-games-successful-game/ http://www.ijailbreak.com/applications/infinity-blade-ios-ep...
- thirdsight 13y 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 13y 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 13y 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).
- codygman 13y ago
  FP Ivory tower? There are plenty of imperative only programmers who believe PHP isn't a sane choice.
- alien3d 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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?
    - 13y ago
cclogg 13y 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.
coldtea 13y 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.
- oe 13y 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.
  - kalleboo 13y 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
thirdsight 13y 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.
- abvdasker 13y 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.
fit2rule 13y 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_ 13y 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.
CmonDev 13y 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.
weland 13y ago
I think this paints a rather meagre picture of software development in 2014: > More or less everything is expected to talk HTTP, and it’s really easy to make things talk HTTP. A lot of things that shouldn't talk HTTP are expected to just because there's an army of programmers who don't know better. Also, it's actually hard to make things talk HTTP, partly due to HTTP itself. However, much of this complexity is hidden, leaving people to think that > devices are memory-starved, CPU-starved, and battery-starved. In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved? The fact that so many applications perform computationally trivial things, but lag on such devices, has nothing to do with their processing power being low, and has everything to do with them being badly written. It takes a lot of effort to make an application lag on such a system. > Browsers suck too Browsers are fine as long as you use them for what they are meant to be used: browsing HTML files. Seriously, browsers have been just fine and dandy since the days of Opera 6. What does suck, indeed, is when people try to use tools that were meant to make HTML docs look nice to build an office suite. They inevitably end up with an office suite that sucks, but that's not the browser's fault. (Edit: just to be clear, the author kind of seems to imply some of these points, too)
- talkingquickly 13y ago
  > Browsers are fine as long as you use them for what they are meant to be used A lot of people now want to use their browser for far more than that and browser technologies are evolving accordingly. I'd suggest it's been quite a while since browsers were meant to be used for nothing more than browsing html files.
  - jokoon 13y ago
    So true. Browser were meant to display page, the day javascript was introduced, nobody would have really imagined to see 3D webgl games running on the monster that is v8.
  - _pmf_ 13y ago
    > A lot of people now want to use their browser for far more than that No. People want a way to quickly use new software. It's just that the easiest way to achieve this today is providing applications via the browser.
ceautery 13y ago
"JavaScript is horrible." > function byNum(a,b) {return +a>+b} undefined > [5, 10, 1].sort(byNum) [1, 5, 10] No, it's not.
- Morgawr 13y ago
  that looks pretty horrible if you ask me
  - twerquie 13y 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 13y ago
  Writing your own method to solve a problem every other language does out of the box is missing the point...
  - twerquie 13y 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.
    - adobriyan 13y ago
      > runaway See "runaway chain reaction".
      - twerquie 13y ago
        I'm not following, is this just snark or am I missing a point?
- i2 13y 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; }
kriro 13y 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.
72deluxe 13y 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?
- ksk 13y 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.
  - 72deluxe 13y 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.
alexandros 13y 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 13y 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/ 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
swah 13y 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 13y 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 13y 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".
pikachu_is_cool 13y ago
This is one of the most ill-informed and circlejerky posts on HN I have ever seen. Most of the fallacies in the article have already been addressed, but I thought I needed to point these few relating to mobile out: > Mobile sucks. First of all, you have to do your mobile development twice. You don’t get a choice of languages; if you hate both Java and ObjC, get another job. Unit testing is a bitch. You obviously have never done mobile development, or have tried really hard to stay ignorant at what's available to you. Have you heard of Xamarin, or saurik's cycript? >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. > The right way to use the Internet is to click in the search box at the top of your browser and type in what you want, and find it, and click on it, and use it. But if the information or service or whatever that you’re looking for has been sucked into mobile, you have to install the app, which means another level of search in the mobile-app store, where search isn’t nearly as good as what Google and Bing provide. ...I'm not even going to bother addressing this. > 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? I don't know, maybe because everyone you know is a shit developer?
alien3d 13y ago
have you got new customer wanted ie7 comp?thanks oracle form
deleted 13y ago
[deleted]
kayoone 13y 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.
- codygman 13y 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 ;)
  - kayoone 13y 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.
    - codygman 13y ago
      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.
eonil 13y ago
Nice summary. Anyway, it seems he haven't tried Go seriously yet.
Eleutheria 13y 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 13y ago
  Awfully late to displace iOS/Android
memracom 13y 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/clojurescript/2013/06/13/functional-reactive-programming.html http://christophermeiklejohn.com/frp/javascript/clojurescrip... and down near the bottom he has a link to the HN discussion of his article.
warfangle 13y ago
>JavaScript is horrible. >> [5, 10, 1].sort(); >> [ 1, 10, 5 ] Treat .sort() without a sorting function as undefined behavior. Voilà.
jfasi 13y 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.
- jfasi 13y 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 13y 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 13y 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 13y 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 13y 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.
deleted 13y ago
[deleted]
lucb1e 13y 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 13y 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 13y 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 13y 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.
tracker1 13y ago
The JS sort example was interesting... solution. [5, 10, 1].sort(function(a,b){return a - b});
arieldiaz 13y 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.
LizVerano 13y ago
this is cool!
lutorm 13y ago
Software != web software. Plenty of us write software that never touches either an HTTP server or browser.
damian2000 13y 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 13y 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

471 points by AndrewDucker 13y ago

deleted 13y ago

[deleted]

rmrfrmrf 13y ago

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

joe_fishfish 13y ago
It's not at all, it's a rant on the massive disparity between server-side and client-side development.
muhuk 13y ago
I am in your debt.
ragecore 13y ago
I thought ranting about PHP and JS was so 2013
- cothomps 13y ago
  .. and ranting about Spring is about what, 2006?

hayksaakian 13y 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 13y 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_fishfish 13y 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.
  - Xixi 13y ago
    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.
- josteink 13y 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.
kalleboo 13y ago

xd 13y 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

enneff 13y ago
So what? Part of the reason PHP is such a disgusting mess is because it is a raft of haphazardly accumulated features.
- xd 13y ago
  For someone that works on Go at Google I'm shocked by your very much subjective view of PHP. Elitist much?
  - ciupicri 13y ago
    It's not just his view, there are other people who feel the same way about PHP.
  - dmak 13y ago
    That comment didn't even come across as elitist. There was no need to get personal.
    - xd 13y ago
      He works on Go at Google. A skilled professional no doubt, could he not have made some valid points rather than simply calling PHP disgusting. It didn't add anything to the conversation. If you where in the pub and someone spent some time listing the virtues of the pint they where drinking, and then someone joined in the conversation and called it disgusting with no basis .. wouldn't you find that to be odd behavior?

paukiatwee 13y 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 13y 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.
- taeric 13y 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.
Morgawr 13y ago

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

72deluxe 13y 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 13y 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 13y 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-epic-games-successful-game/ http://www.ijailbreak.com/applications/infinity-blade-ios-ep...

thirdsight 13y 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 13y 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 13y 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).
codygman 13y ago
FP Ivory tower? There are plenty of imperative only programmers who believe PHP isn't a sane choice.
alien3d 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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?
  - 13y ago

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

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

oe 13y 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.
- kalleboo 13y 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

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

abvdasker 13y 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.

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

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

weland 13y ago

I think this paints a rather meagre picture of software development in 2014: > More or less everything is expected to talk HTTP, and it’s really easy to make things talk HTTP. A lot of things that shouldn't talk HTTP are expected to just because there's an army of programmers who don't know better. Also, it's actually hard to make things talk HTTP, partly due to HTTP itself. However, much of this complexity is hidden, leaving people to think that > devices are memory-starved, CPU-starved, and battery-starved. In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved? The fact that so many applications perform computationally trivial things, but lag on such devices, has nothing to do with their processing power being low, and has everything to do with them being badly written. It takes a lot of effort to make an application lag on such a system. > Browsers suck too Browsers are fine as long as you use them for what they are meant to be used: browsing HTML files. Seriously, browsers have been just fine and dandy since the days of Opera 6. What does suck, indeed, is when people try to use tools that were meant to make HTML docs look nice to build an office suite. They inevitably end up with an office suite that sucks, but that's not the browser's fault. (Edit: just to be clear, the author kind of seems to imply some of these points, too)

talkingquickly 13y ago
> Browsers are fine as long as you use them for what they are meant to be used A lot of people now want to use their browser for far more than that and browser technologies are evolving accordingly. I'd suggest it's been quite a while since browsers were meant to be used for nothing more than browsing html files.
- jokoon 13y ago
  So true. Browser were meant to display page, the day javascript was introduced, nobody would have really imagined to see 3D webgl games running on the monster that is v8.
- _pmf_ 13y ago
  > A lot of people now want to use their browser for far more than that No. People want a way to quickly use new software. It's just that the easiest way to achieve this today is providing applications via the browser.

ceautery 13y ago

"JavaScript is horrible." > function byNum(a,b) {return +a>+b} undefined > [5, 10, 1].sort(byNum) [1, 5, 10] No, it's not.

Morgawr 13y ago
that looks pretty horrible if you ask me
- twerquie 13y 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 13y ago
Writing your own method to solve a problem every other language does out of the box is missing the point...
- twerquie 13y 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.
  - adobriyan 13y ago
    > runaway See "runaway chain reaction".
    - twerquie 13y ago
      I'm not following, is this just snark or am I missing a point?
i2 13y 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; }

kriro 13y 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.

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

ksk 13y 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.
- 72deluxe 13y 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.

alexandros 13y 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 13y 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/ 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

swah 13y 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 13y 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 13y 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".

pikachu_is_cool 13y ago

This is one of the most ill-informed and circlejerky posts on HN I have ever seen. Most of the fallacies in the article have already been addressed, but I thought I needed to point these few relating to mobile out: > Mobile sucks. First of all, you have to do your mobile development twice. You don’t get a choice of languages; if you hate both Java and ObjC, get another job. Unit testing is a bitch. You obviously have never done mobile development, or have tried really hard to stay ignorant at what's available to you. Have you heard of Xamarin, or saurik's cycript? >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. > The right way to use the Internet is to click in the search box at the top of your browser and type in what you want, and find it, and click on it, and use it. But if the information or service or whatever that you’re looking for has been sucked into mobile, you have to install the app, which means another level of search in the mobile-app store, where search isn’t nearly as good as what Google and Bing provide. ...I'm not even going to bother addressing this. > 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? I don't know, maybe because everyone you know is a shit developer?

alien3d 13y ago

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

deleted 13y ago

[deleted]

kayoone 13y 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.

codygman 13y 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 ;)
- kayoone 13y 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.
  - codygman 13y ago
    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.

eonil 13y ago

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

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

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

warfangle 13y ago

>JavaScript is horrible. >> [5, 10, 1].sort(); >> [ 1, 10, 5 ] Treat .sort() without a sorting function as undefined behavior. Voilà.

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

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

deleted 13y ago

[deleted]

lucb1e 13y 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 13y 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 13y 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 13y 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.

tracker1 13y ago

The JS sort example was interesting... solution. [5, 10, 1].sort(function(a,b){return a - b});

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

LizVerano 13y ago

this is cool!

lutorm 13y ago

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

damian2000 13y 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 13y 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.