Live data from Hacker News

Software in 2014

tbray.org

131–140 of 265 posts

Re: Software in 2014

#131
post #79
post #49

Earlier quoted context omitted.

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

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

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

The whole point of HHVM is to migrate away from the PHP runtime (by using the PHP language on another runtime). It's a bit perverted to say that's a god thing for PHP.

Re: Software in 2014

#132
post #116

Earlier quoted context omitted.

> because it's a piece of crap. I don't think that's a fair assessment. The challenge is that developing for mobile is nowhere near _as_ _easy_ as desktop. So we have a legion of desktop devs coming over to mobile and getting lost, their code doesn't "suck" its fine for desktop its just not good mobile code. Also, power management.

> their code doesn't "suck" its fine for desktop its just not good mobile code IMHO, code that is not adequate for a platform on which it is intentionally deployed, by definition, sucks. There's no such thing as good application that is fine for any computer except those it is ran on.

As a person who used an LG "smart"phone that couldn't handle the bare Android OS without lagging (and turning on Wi-Fi would freeze it to death), I agree wholeheartedly. Intentionally selling crap that doesn't work is evil in my book.

Re: Software in 2014

#133
post #62

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…

> 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 p…

Even on the slow (by smartphone standards) Nexus One, Flash ran quite decently. The Nexus 5 is a good magnitude faster in every way (I can't find specific parity-version benchmarks, so perhaps I'll fire both of them up and give it a go), moreso in some ways like the GPU, and is as powerful as some desktops that people still use in business settings. It would of course have no problem with Flash.

Flash failed because a good percentage of existing content relied upon the accouterments of a desktop, namely the keyboard and the mouse. Minus these it just made for a frustrating experience for a lot of users. Add the fact that sites were loaded with obnoxious, taxing Flash ads, and it just gave users of Flash-enabled devices a very negative experience. It also reflected poorly on the product as a number of popular tech sites compared Android and iOS web page loading times, the former seriously hindered by the loading and overhead of Flash.

There were later changes to make it activate on click, but that just made it even more of a usability burden.

In a way, at the time this whole debate was raging, iOS users got to enjoy essentially a free "adblock" in the absence of Flash.

I have to entirely disagree with any notion that smartphones are underpowered: I am currently working on a very intense real-time image processing system and with each iteration I'm finding that I'm increasing the scope and featureset because the performance continually blows me away. Even when I work on "older" devices like the Galaxy S3, with good code and good parallelization (incl. the GPU), it is just a ridiculous platform.

Re: Software in 2014

#134
post #32
post #24

Earlier quoted context omitted.

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

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

"Elitist?" I came into web development via the PHP tradesman's entrance, and until by the grace of God I found my way out into the wider world, I didn't even begin to suspect just how miserable I had it. If there's a tinge of elitism in the wider world's attitude toward PHP, I'll be the first to contend that it's justified.

Re: Software in 2014

#135
post #5

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

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

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

Re: Software in 2014

#136
post #65

Earlier quoted context omitted.

"haphazardly accumulated features" is not an explanation, it's a subjective point of view. "it's not very liked one due to it's flaws", PHP is very well liked, just not by everyone .. which goes for most things in life.

"haphazardly accumulated features" is not an explanation, it's a subjective point of view. If you really need it, here's a very good write-up which should cover that in an impressively detailed manner: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

This was hotly debated, by myself included, right here on HN: https://news.ycombinator.com/item?id=3820431

He has updated the article over time which is good of him, but much of it is still subjective and from a quick glance there are points that no longer hold true.

Re: Software in 2014

#138

Earlier quoted context omitted.

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

I think modern Android and iOS devices could do that just as well. I believe not supporting Flash has more to do with Apple/Google strategies (i.e. not depending on propietary third party software) than actual hardware limitations.

Even old tablets could do that perfectly fine, for example the touchpad (on both Android and WebOS).

Re: Software in 2014

#139

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 t…

> I did like the discussion of dynamic vs. static though. It really feels dynamic is good for early codebases and static for late. So why aren't there languages that allow you to move to static as your codebase matures? TypeScript adds optional typing but doesn't quite go the whole way unfortunately.

I think that's a good idea. Maybe have a dynamically typed language, with other features that make dynamic languages good for using in a REPL and with more of a investigative programming style. And then have (another) language which is more static and have simpler runtime semantics, so that the language is easier to reason about but has less features that make it interactive. You might not even need the interactive features at a certain point, anyway, but it might be a problem if you want to move back to the more dynamic part in order to experiment with stuff. But that could perhaps be solved by making it possible to use the static language as the dynamic one, but not vice versa: for example if the difference is only in that the static one has type declarations and the dynamic one does not, simply ignore the type declarations and run it as the dynamic language, or defer it to be checked at runtime [0].

Someone in another thread brought up Typed Racket, which IIRC is implemented in Racket itself with macros.

http://docs.racket-lang.org/ts-guide/

[0] in GHC Haskell you can use a flag to defer type errors to be checked at runtime:

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

Re: Software in 2014

#140
post #87
post #72

Earlier quoted context omitted.

> In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved? Those CPU don't have as much cache memory (which is vital for a CPU to be fast), are very low powered, and not cooled by any fan. Even my $50 nokia can do 3D, 3D acceleration doesn't mean it's a fast device. CPU frequency do…

> Those CPU don't have as much cache memory (which is vital for a CPU to be fast), are very low powered, and not cooled by any fan. They are, nonetheless, far more powerful than computers which ten years ago ran comparable applications of comparable feature and comparable eye candy complexity (if somewhat lacking in design taste). I think cache memory should mostly be irrelevant for many of the user-facing mobile app…

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

That's why the software and protocol you use on a mobile device should be very much different. To me, desktop and mobile software are way too much similar.

The fact a programmer will fuck up an app boils to the fact twitter will use HTTP, which is text, on top of SSL. This can't be blazing fast for such a low powered device, especially if it's a library API thing you use to make an app on top of it. I think google and the web in general are mostly to blame because they're responsible of spreading text based protocols.

I'm just concerned about mobile software, because the hardware is really really good, but the software had not been adapted for it. We just need protocols and format that are just faster, more compact, and maybe rely on other networking optimizations. bittorrent, for example, is a great example of a reliable binary protocol.

HTTP and HTML were great because they are easy platforms to make something on, but they require more memory because of parsers and more bandwidth because one single web page will often weigh 100ko, and run a javascript engine which is not a simple piece of software.

The hardware has gotten smaller, maybe we also need to make smaller software too ! I agree there are also security concerns about binary protocols, but it's just weird that there are so few open, standardized binary protocols, maybe because developers find working with http being just easier. You can't have it easy all the time.

Post reply on HN