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

Taking PHP Seriously

slack.engineering

Post reply on HN
Print view View original

271–280 of 673 posts

Re: Taking PHP Seriously

#271

Post by chiefalchemist »

swalsh wrote: post #250
calsy wrote: post #191

Earlier quoted context omitted.

So people who don't care make successful projects and PHP is a garbage language that is responsible for more successful projects than any other server side scripting language. LOGIC.

My point is that the people don't care about the tech. They're worrying about the problem they're trying to solve. New companies that priotitize tech over finding and pleasing their customers don't live long enough to see the benefits. Just my observation. I've been through the "but if you don't build it right today you'll have to build it again tomorrow... that makes no sense" phase. I made some great code, but very…

That's really the question. Is language choice a signal for other properties of the culture? And if so, which of those cause success?

Re: Taking PHP Seriously

#272

Post by NMDaniel »

ux-app wrote: post #183
brian-armstrong wrote: post #152

Earlier quoted context omitted.

An easier way to avoid those warts would be to pick a different language

and miss out on all the awesome aspects of the language/environment?

There are plenty of great server-side languages and environments. C#,Java,Scala,Python,Ruby,Haskell.

If this was about JavaScript and Front-End I might've agreed with you (there are transpilers but interoperability with JS modules can be tricky), however in the realm of servers there's so much freedom.. so why choose PHP out of them all?

Re: Taking PHP Seriously

#273

Post by wyager »

codedokode wrote: post #243
wyager wrote: post #221

Earlier quoted context omitted.

Rust and Haskell are both extremely well designed. Most of the "top languages" by percentage usage are 20+ years old, so I can't fault them that much for being badly designed, but we should definitely stop using them.

Rust looks very complicated to me because there are "lifetimes" and you need to think where to put those single quotes properly. Not a language for a beginner. Haskell doesn't support OOP if I remember correctly. And it is complicated too.

I never said it was for a beginner, just that it was well designed. Lifetimes are no more complicated than stuff you regularly run into in C++, though.

Python is a great beginner-friendly language, but that doesn't mean it's well-designed in other respects or appropriate for large software projects.

It wouldn't really make sense for Haskell to "support OOP" in the usual since. The OOP paradigm is mostly useful when you have mutability. Another way of looking at it is that you don't need OOP in Haskell because it exposes better ways of interacting with data that aren't present in most OO languages, like ADTs and Typeclasses.

Re: Taking PHP Seriously

#274

Post by aikah »

bkanber wrote: post #204
astrodust wrote: post #165

Earlier quoted context omitted.

This really depends on your definition of "great".

Who does it better?

Unless you are using ReactPHP, PHP doesn't handle Http requests in any serious production configuration, the server fronting PHP does( Apache ,Nginx). But PHP wasn't design with Async programming in mind so using ReactPHP is more than tricky since most operations are blocking.

Re: Taking PHP Seriously

#275

Post by brassic »

wyager wrote: post #221
Aldo_MX wrote: post #202

Earlier quoted context omitted.

Which of the top languages is actually well designed? All of them have their area of opportunity.

Rust and Haskell are both extremely well designed. Most of the "top languages" by percentage usage are 20+ years old, so I can't fault them that much for being badly designed, but we should definitely stop using them.

Haskell is also more than 20 years old.

Re: Taking PHP Seriously

#276

Post by bkanber »

tonyarkles wrote: post #214
bkanber wrote: post #198

Earlier quoted context omitted.

Symfony, Aura, Laravel, Guzzle, Composer, Zend Framework, Lithium, SwiftMailer

Those are all frameworks and libraries, aren't they?

Sure, but most of the OSS for Python and Ruby is frameworks and libraries too... If you want an application check out phabricator, though I'm not a fan of their DB schema design.

Re: Taking PHP Seriously

#277

Post by calsy »

swalsh wrote: post #250
calsy wrote: post #191

Earlier quoted context omitted.

So people who don't care make successful projects and PHP is a garbage language that is responsible for more successful projects than any other server side scripting language. LOGIC.

My point is that the people don't care about the tech. They're worrying about the problem they're trying to solve. New companies that priotitize tech over finding and pleasing their customers don't live long enough to see the benefits. Just my observation. I've been through the "but if you don't build it right today you'll have to build it again tomorrow... that makes no sense" phase. I made some great code, but very…

The primary objective of programming is to 'provide a solution to a given problem'. Everything else is secondary. If PHP is capable of providing that solution faster and cheaper than its competitors, it will always be the winner. PHP is a practical language and its success demonstrates that fact.

Re: Taking PHP Seriously

#278

Post by TazeTSchnitzel »

lol768 wrote: post #71

Does anyone know how the types in PHP7 compare to what's offered by Hack? It looks like generics aren't yet in the core language ( https://wiki.php.net/rfc/generics ), but I believe return type hints work. I think we're also still missing property/field type hints ( https://wiki.php.net/rfc/property_type_hints ).

PHP 7's type declarations are enforced at runtime, rather than Hack's compile-time types.

This has its pros and cons. This means these declarations are always enforced, even when calling between typed and untyped code. However, there's no compiler to catch you out, at least not just from using the interpreter. Your IDE, or an external type checker (e.g. Phan) can check them for you, though.

PHP 7 also gives you a choice between weak and strict type coercion modes, whereas Hack lets you choose between enforced type declarations and unenforced type declarations.

As for the specific things you can type in PHP 7.0, there's parameter and return type declarations for `int`, `float`, `string`, `bool`, `array`, any class or method, and `callable` (a function name, method reference or closure). PHP 7.1 brings nullable types (prefix any type name with `?`), `iterable` (an array or an object implementing `Traversable`) and the `void` return type (enforces that a function doesn't use `return` with a value).

Notable omissions are generics (even for arrays), and property types. There was a proposal for the latter, but it was rejected, for better or worse. As bkanber mentions, however, IDEs can still check property types if they're annotated using docblocks. Hack also has a few extra special types that PHP lacks.

Re: Taking PHP Seriously

#279

Post by napsterbr »

tonyarkles wrote: post #106

I've been doing consulting for several years now, as well as a MSc thesis that involved me looking at a number of open source codebases. I am generally in the "PHP is garbage" camp, but I keep hearing people say that nice codebases in PHP are possible. I've never seen one, but I am perpetually open to the idea that they exist. Does anyone have a good example of an open-source PHP project that will enlighten me?

Phabricator

Re: Taking PHP Seriously

#280

Post by tracker1 »

rpeden wrote: post #210
tracker1 wrote: post #129

Earlier quoted context omitted.

That's a fair criticism in node... I wouldn't want to work on it without an SSD (deployment is a different story)... the spinup and even npm install time on an HDD is dramatically slower than SSD. It's also not that hard to roll your own system and avoid many of the modules and frameworks in the space. The first API I wrote using node wasn't bad at all, and in the end actually simpler than the rewrite using express..…

Yeah, the size of my node_modules directory doesn't bother me that much. I've worked on some large Node projects in the past, and didn't care too much about how many modules I had installed because I wasn't exactly running out of disk space. It only really bothered me in an aesthetic sense; although everything worked fine, it just felt messier than necessary. The huge JS bundles we're sending to the browser after run…

Yeah, the migration to ES6-style modules, Webpack2 etc will help a lot. There's still some bits to work out... about ready to do a new version of a few module in NPM and just declare that said module need to be used with babel+es6, async functions and decorator transforms... I'm tired of waiting, and it'll make the modules themselves cleaner not having to transform before publishing to npm in the end.

It's funny that a lot of this stuff is finally making it into the browsers and platform, when I've been using it for almost 2 years now. Looks like async is going in behind a flag in node 7.

Post reply on HN