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

231–240 of 265 posts

Re: Software in 2014

#231

Post by codygman »

kayoone wrote: post #142

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

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 ;)

Re: Software in 2014

#232

Post by auvrw »

weland wrote: 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?

lol, sir, lol.

Re: Software in 2014

#233

Post by codygman »

paukiatwee wrote: post #6

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.

For the majority that aren't concerned with realtime processing (total fine grained control isn't needed) concurrent FP is much simpler than the alternatives. FP code (ala Haskell) can also be very aggressively optimized.

Also, most of the time programmers shoot themselves in the foot with that total fine grained control some languages give. This doesn't mean they don't need to exist, just that FP can server a majority who think they need total control much better with more than acceptable performance.

Re: Software in 2014

#234

Post by alien3d »

troels wrote: post #11

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.

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

Re: Software in 2014

#235

Post by lobster_johnson »

fit2rule wrote: post #29

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…

As an aside: Moai is great, but it has a problem with lack of developer activity, to the point that a cynical person could (especially with the abrupt shutdown of Moai Cloud) consider it to be abandoned.

For example, the current official Moai site's link to the downloadable SDK is broken, and there is currently nowhere to download the SDK; you have to build it yourself. There isn't even a proper official release beyond 1.3. And the current master branch has a bunch of outstanding issues, such as a Lua/C-binding-related segfault and the fact that you can't build the code with XCode 5.0.

Right now there are several unofficial forks that could become the new master. Unfortunately, of all the game companies that use Moai, very few of them seem to be contributing code back. At the very least some of them could get together to coordinate stewardship of the project, something which seems completely lacking right now.

Re: Software in 2014

#236

Post by aryastark »

memracom wrote: post #151
zxcdw wrote: 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…

Oh god. It's Perl. And no need to drag it through the mud here. It's pretty much the only language that gets Unicode right. It has nothing in common with the abject misery that is PHP. Perl came out in '87. Erlang came out in '86. I don't know what you're high on, other than trends and trendwhores.

Clojure isn't new. Not to take a dig at Rich Hickey, but everything he is doing with immutable objects was done more than a decade ago by the likes of Henry Baker (http://home.pipeline.com/~hbaker1/home.html). Of course, everything that has ever been tried at all has been tried in some variant of Lisp/Scheme at one point in time.

Re: Software in 2014

#237

Post by e28eta »

derefr wrote: post #194
weland wrote: post #120

Earlier quoted context omitted.

> Yet, because it runs in the browser and is available everywhere, that's why I use Google's Docs. And GMail's web interface is better than any email client I tried until now. IMHO, this is a case of solving a problem at a wrong level. I also find that matches provide neither a sufficiently long-lasting, nor a sufficiently intense fire to cook. Longer and thicker matches would obviously be a solution to this, and it…

> The "mobile" part ceases being true when their battery is only sufficient to allow them to be mobile for the duration of an entry-level delayed road trip. I'd much rather have a dumphone and a tablet than a smartphone. You sound like someone who lives in a somewhat-rural area. Smartphones are somewhat like smart cars, in that they're basically built for urbanites--people who mostly either end up at home each night…

Precisely. There's an engineering trade off between processing power, display size, resolution, brightness, and battery life. I don't think battery life has ever been the feature that sells gadgets.

I read somewhere that SJ set the bar for iPad battery life at ~10 hours, and I think that set consumer expectations across the industry. Think of the iPad 3: it got thicker and heavier, in order to maintain battery life when faced with the retina screen.

My hypothesis: For each device category, there is an "accepted" battery life that new devices must meet. Beyond that, what sells better: a 15% boost in speed or in battery life?

When people stop using performance benchmarks and start using battery life, then companies may take notice. Until then, resign yourself to 1-2 days of battery on a smartphone.

Re: Software in 2014

#238

Post by was_hellbanned »

72deluxe wrote: post #91

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…

IMO, as a long-time desktop developer (occasional early mobile and web), unless you're interfacing with hardware, there is probably no reason for you to be writing a true native desktop application.

At this point, even if I were writing business CRUD apps, I think I'd be reluctant to start using, say, C# and .Net, preferring some kind of packaged system allowing me to, effectively, write desktop apps using mobile languages and stacks.

Re: Software in 2014

#239

Post by ekianjo »

efuquen wrote: post #195
weland wrote: post #120

Earlier quoted context omitted.

> Yet, because it runs in the browser and is available everywhere, that's why I use Google's Docs. And GMail's web interface is better than any email client I tried until now. IMHO, this is a case of solving a problem at a wrong level. I also find that matches provide neither a sufficiently long-lasting, nor a sufficiently intense fire to cook. Longer and thicker matches would obviously be a solution to this, and it…

> Yes; and I do think smartphones are a terrible piece of engineering. I can't read that and not scoff. I don't know how you can seriously argue that smartphones aren't a great piece of engineering. The power, accessibility, and flexibility offered in a device that easily fits in your pocket is pretty amazing in my book. Yes, battery technology isn't the best, but to say somehow that what has happened in the smartpho…

Mmmm. It's not a great piece of engineering because they compromise on the wrong thing: mobility, precisely because of their tendency to eat up the battery in less than a day. When you need to charge a mobile device every single day, it's not meeting the ideal specifications you want to have, so yeah, in that sense it's shitty engineering we have been forced to swallow. And that's not going in the good direction when you keep putting more cores and more watts in in the smartphones' innards, while the battery technology is very slow to evolve.

Re: Software in 2014

#240

Post by ksk »

14113 wrote: post #171
ksk wrote: post #113

Earlier quoted context omitted.

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

Quite a lot! However, quite a lot of them aren't exactly writing for consumers, but for the business market.

Are you guessing or do you have any information? Its hard to find good data on this.
Post reply on HN