"JavaScript is horrible." > function byNum(a,b) {return +a>+b} undefined > [5, 10, 1].sort(byNum) [1, 5, 10] No, it's not.
Writing your own method to solve a problem every other language does out of the box is missing the point...
Software in 2014
81–90 of 265 posts
Re: Software in 2014
#82It’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.
>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 thread…
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.
Re: Software in 2014
#83Notice 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 bette…
The best phone I ever owned was a Nokia 6310i, and I had to charge it only once, occasionally twice a week. Now with all the advances in battery technology, phones barely last a day and there's a thriving market in external batteries and portable chargers. If I am not using any of the "smart" features on my smartphone, just calls and texts, I would expect it to last longer than that old Nokia, but I might get at best…
When I turn off data on my Android phone to use it as a backup phone with my home SIM in, it does indeed last for weeks. Modern phone designs are a marvel of efficiency for what they're expected to do.
Re: Software in 2014
#84I 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…
> What does suck, indeed, is when people try to use tools that were meant to make HTML docs look nice to build an office suite.
The same thing is now happening to a certain extent in the native mobile development. UI Frameworks have been steadily inadequate towards the modern UI idioms and trends, so people are doing crazy things customizing the standard components to have their app looking like FB's app, for example. It's the UI frameworks that are seriously lacking, not so much the tools and the languages.
Re: Software in 2014
#85Earlier 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
I agree, but that can't really work on the long term...
It's the equivalent of smacking a malfunctioning (mechanical) appliance to try and make it work again. Maybe you just want something to last long enough until you can get a better-designed, more reliable appliance.
Re: Software in 2014
#86> 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 ap…
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.
Re: Software in 2014
#87I 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? 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 applications. They tend to be more I/O bound than computationally-bound. I think something is seriously fucked up if a programmer manages to screw up the performance of his Twitter client or chat application because of caching. This isn't the case for, say, mobile games or various types of multimedia applications, but that's a different story. The point is, a native-looking interface made up of nothing but native-looking widgets has no excuse for being laggy on such a platform.
Cache memory is not vital for a CPU "to be fast" in every situation, it's vital for a CPU to be fast with bulk data. If you're working on bits and pieces of information that are hundreds of bytes in length, low cache count is no excuse to be slow.
It's also worth noting that on today SoC's, a lot of data processing is offloaded in different manner. Small cache on a general-purpose CPU that has to do software video decoding has a far larger impact than small cache on an SoC with a dedicated video processor, with its own set of fast-access memory buffers & co..
I'm obviously not trying to imply that a 1 GHz mobile SoC is equivalent in every term of processing power as, say, a 1 GHz network processor or a 1 GHz PowerPC from a Powerbook. But things are actually somewhat better than you paint them to be.
> Many things are already preoptimized on the kernel level, but it doesn't change the fact that even html and javascript parsers, which parse text, will be slower on those devices.
Obviously not. What I am arguing is that having to parse HTML and Javascript in applications that are not web browsers (or which otherwise don't have to browse hypertext because hypertext is essential to their intended function) is superfluous.
Edit:
> Performance will bite you on mobile software.
Performace will bite you on every type of software. It's a mad, possibly rabid dog that hates humans. Some programmers, however, seem very prone to teasing it.
Re: Software in 2014
#88I 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 partly shitty ARM code, its not really much to do with the specs. I can do things much more easily on an underpowered x86 than an overpowered ARM.
Re: Software in 2014
#89Notice 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 bette…
>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-i…
> 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
Re: Software in 2014
#90I 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? 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…
Yes, we desperately need the "mobile is the new desktop computer" meme to die. You get what you pay for, and a CPU that barely consumes a watt will not deliver desktop performance, no matter the cores, memory or frequency.
That said, compared to actual CPU- and memory-starved embedded systems, mobile is a freaking race car. If you measure your memory in multiples of megabyte, you need not apply. Given that, the performance situation on mobile is rather appalling.