Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software in 2014

tbray.org

Post reply on HN
Print view View original

51–60 of 265 posts

Re: Software in 2014

#51

Post by ben0x539 »

xd wrote: post #45
dmak wrote: post #37

Earlier quoted context omitted.

That comment didn't even come across as elitist. There was no need to get personal.

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?

Do you really want another thread in which everybody enumerates their favorite issues with php?

Re: Software in 2014

#52

Post by smikhanov »

kranner wrote: post #40
coldtea wrote: post #19

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

> there are iOS bindings for all popular languages (and I've used several) Care to list some, other than Xamarin and RubyMotion?

I second that request. Could you please include the links to mature production-ready bindings for some of the top programming languages from the TIOBE index?

Re: Software in 2014

#53

Post by andyroid »

stiff wrote: post #49
xd wrote: 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…

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

Yeah, xd clearly missed to list that the creator of the language also has a sense of humor, but trying to limit it to technical features seems reasonable.

Re: Software in 2014

#54

Post by smikhanov »

andyjohnson0 wrote: post #47
kranner wrote: post #40

Earlier quoted context omitted.

> there are iOS bindings for all popular languages (and I've used several) Care to list some, other than Xamarin and RubyMotion?

There are iOS bindings for F# [1] with some level of support from Xamarin [2]. I'm not aware of any others. There are Cocoa bindings for a number of languages [3], but I'm fairly certain they are desktop-only. [1] http://fsharp.org/use/ios/ [2] https://forums.xamarin.com/discussion/3465/f-language-bindin... [3] http://en.wikipedia.org/wiki/Cocoa_(API)#Other_bindings

They are indeed for desktop. As Objective-C becomes better (and it does it pretty fast, it has covered two decades of language development from 1970s to 1990s in just 7 years), most of the amateur iOS languages bindings become stale.

There are currently no high-quality, production-ready, native 3rd party language bindings for iOS that I know of, except for Xamarin mentioned above and Unity family.

In iOS 7 though, there's some activity in JavaScriptCore.framework on providing seamless integration between JavaScript and Objective-C.

Re: Software in 2014

#55

Post by mseebach »

xd wrote: 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…

It's a pity that people still build important app in PHP, because despite improvements to PHP, there are several, even many, languages out there that beats PHP flat out on all fronts.

PHP used to be by far the easiest language to get started with for web dev. This is not the case anymore.

And while you're certainly entitled to disagreement, Tim Bray is about as far from "so called" you can get for a software professional.

Re: Software in 2014

#56

Post by CmonDev »

No mention of Midori/M# (unlike Rust).

"The client-side mess · Things are bad. You have to build everything three times: Web, iOS, Android. We’re talent-starved, this is egregious waste, and it’s really hurting us."

Not really, Xamarin did a good job of simplifying this (and you can use decent modern languages). HTML5/CSS/JS on the other hand is the real client-side mess - let's hope we will see more PNaCl/asm.js developments for non-game applications in 2014.

Re: Software in 2014

#57

Post by icebraining »

xd wrote: post #45
dmak wrote: post #37

Earlier quoted context omitted.

That comment didn't even come across as elitist. There was no need to get personal.

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?

Even if he hadn't explained why, and he did, it still wouldn't be elitist.

Re: Software in 2014

#58

Post by JackMorgan »

xd wrote: 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…

My perception is most developers who choose to use PHP these days for new development efforts either do so because it's their strongest language and do not want to reinvest the time to retool, or because of political reasons orthogonal to PHP's technical chops. Thankfully, it is still actively developed, so those who make that choice are able to take advantage of such new features.

I totally understand the choice to work in shops that have legacy php code: they have money and often times don't want to change off php. Handily enough, most of us like working for money.

What caused me to retool away from php was the fear that not enough new systems were being built in it, leaving a diminishing pool of jobs for a constant pool of developers not wanting to retool. I figured I'd give up my space to someone else, and seek my fortunes on other stacks. I don't think there is anything wrong with deciding X language will be the one you ride into the sunset on (some COBOL programmers I know make crazy money due to the economics of the ratio of jobs/developers). I just personally considered the risk of a job shortage to outweigh the rush of a talent shortage. (And I am so practiced at retooling, I could probably be ready to interview for a PHP job in a few weeks if I had to).

I think of choice of stacks from the agile way, "make it fast to change, and you'll be ready to snatch up arbitrage opportunities when they arise." Rather than the waterfall way, "pick the right tech that will last your career at the point of maximum ignorance".

I think most people mock PHP just because it's fashionable to do so, it's the "easy joke" that vb6 used to be. I wouldn't take it personally, you should own your choices.

Re: Software in 2014

#59

Post by pgeorgi »

grey-area wrote: post #43
xd wrote: 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…

baseless statements from so called software professionals You're calling this guy[1] a 'so-called software professional' because he criticised PHP? [1] http://en.wikipedia.org/wiki/Tim_Bray

To be fair, he _did_ bring XML upon us...

Re: Software in 2014

#60

Post by chrisdevereux »

grey-area wrote: post #34
coldtea wrote: post #19

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

First of all, you have to do your mobile development twice This is not wrong, in fact with Windows Phone and Firefox OS it'll soon become 3 x or 4 x, and more importantly compared to the web you have to make that choice of which to target, test and support - with web software it doesn't come up. The landscape for x-platform software is pretty limited, and having to use a framework like phonegap is far from ideal and…

> I do think it's a shame that the providers of these platforms lock them down to APIs in their chosen languages/frameworks

I never understand this point. All APIs are exposed via some protocol. Whether it's javascript, C, Objective-C or HTTP.

High-level APIs like HTML5 or Cocoa need to be exposed in a high-level language. The restrictions imposed by js or obj-c are an inescapable part of what make these environments better than what we used before.

Does anyone really want to go back to using thin wrappers around C APIs?

Post reply on HN