Live data from Hacker News

Software in 2014

tbray.org

151–160 of 265 posts

Re: Software in 2014

#151
post #50
post #45

Earlier quoted context omitted.

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?

He did explain why PHP is disgusting mess. And hell, the fact that people have that opinion stems from somewhere. And that is a fact we should all take a note of -- to build better tools. You see, PHP is nothing but a tool, and as a tool, it's not very liked one due to it's flaws. Solution? Abandon it! Build new, better tools instead of feeling threathened. Le PHP sink and die it's well deserved death and make way fo…

And that is precisely what Tim is saying. He happens to work mostly with the new tool named Go but he does recognize that there are others like Rust and Dart that are also trying to do things better.

But we need to actually move away from using bad tools (and this has happened with PERL) and start using the newer, better tools more often. Every software developer should learn some Erlang (or Elixir), some Clojure, some Go, etc.

If you don't try these tools out and kick the tires for a while, then you end up stuck in the past like all those COBOL programmers.

Re: Software in 2014

#152

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

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.

Re: Software in 2014

#153
post #113

Earlier quoted context omitted.

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

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

Probably more than are making money shipping software on Android.

Re: Software in 2014

#154

Earlier quoted context omitted.

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

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.

> runaway

See "runaway chain reaction".

Re: Software in 2014

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

Re: Software in 2014

#156
I've come to the conclusion that "MVC" is the problem with web client apps. Now that there are several choices for doing MVVM using a functional reactive programming style, we really should move beyond the simplistic MVC concept.

Here is one pointer to more info http://christophermeiklejohn.com/frp/javascript/clojurescrip... and down near the bottom he has a link to the HN discussion of his article.

Re: Software in 2014

#157

Earlier quoted context omitted.

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

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

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

Re: Software in 2014

#158

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

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

Re: Software in 2014

#159
post #50

Earlier quoted context omitted.

He did explain why PHP is disgusting mess. And hell, the fact that people have that opinion stems from somewhere. And that is a fact we should all take a note of -- to build better tools. You see, PHP is nothing but a tool, and as a tool, it's not very liked one due to it's flaws. Solution? Abandon it! Build new, better tools instead of feeling threathened. Le PHP sink and die it's well deserved death and make way fo…

And that is precisely what Tim is saying. He happens to work mostly with the new tool named Go but he does recognize that there are others like Rust and Dart that are also trying to do things better. But we need to actually move away from using bad tools (and this has happened with PERL) and start using the newer, better tools more often. Every software developer should learn some Erlang (or Elixir), some Clojure, so…

I might be wrong, but COBOL isn't being actively developed as a language anymore .. PHP however is still solving problems and under constant development and improving all the time.

Re: Software in 2014

#160
post #72
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? 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…

> the bogus "optimizing is evil" knuth quote.

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

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

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

Not bogus at all.

Post reply on HN