Hacker News Reader

Comment by yagodragon | Hacker News Reader

When I started programming a few years back, I was told that PHP is legacy tech and a terrible language I should avoid like a plague. After years of battling with Node.js on the backend, I took a closer look at modern PHP and the Laravel framework and I was amazed by how good the developer experience was. The language itself feels like a lite version of Java. I believe everyone starting on web development should know PHP. It's hugely deployed, it has a very mature and rich ecosystem and it's a great language to build your side project/business without spending your time on meaningless tasks. Don't be driven by FOMO like I was, there's no such thing as a "perfect programming language". Every language has it's quirks and that's fine. PHP might be old and boring but it helps you get things done faster than using the new coolest language.

View on HN

> there's no such thing as a "perfect programming language". Every language has it's quirks and that's fine. PHP might be old and boring but it helps you get things done faster than using the new coolest language.

I disagree with you on this point. I worked with PHP for two years on some legacy systems, as well as some Laravel-based systems. While Laravel yields results that are worlds away from PHP build in the 90's, I still wasted dozens of hours because of poor constructs that the language is unfortunately coupled to. I documented each instance where I wasted a significant amount of time due to issues like scoping issues, closure problems, arrays-that-are-arrays-sometimes-but-maps-other-times, etc.

PHP has gotten better. But there are so many good choices that provide much better tooling, guarantees, etc. Examples: Ruby, Go, and Elixir. Heck, even Perl is more sane about its data types in some ways by enforcing consistent comparisons with `==` vs. `eq` and much more robust data structures.

I agree that every language has it's quirks. But I think PHP has so many that it seriously gets in the way often. I don't think it offers any significant velocity gains over using, say, Ruby.

Never heard anyone complain about scoping or closure issues with PHP. I'd be interested to hear more if you recall.

I don’t believe there are maps in PHP - just plain arrays which to be honest are pretty simple to use. Unlike say JavaScript where arrays are always numerically indexed, PHP can use any value as an index.

JavaScript, by contrast, doesn't have arrays - it just has objects, which can have numerical keys.

  a = []
  a.foo = 'bar' // works!

  b = {}
  b[0] = 42 // also works!

I happen to think these designs are both INSANE, but even if you like them, PHP has no advantage here.

so isn't it like PHP, which doesn't have lists, only maps with integer keys?

With the exception that unlike (I think?) PHP, JS also uses maps (w hich can only have string keys [1]) to implement objects and classes. Hence their being called objects, not maps.

[1] So how do arrays have numerical keys? Well... actually they don't. I was trying to make JS look better than it is in my original comment. Actually, array keys are stringified versions of numbers, and values are automatically cast to string when you put them in indexing braces.

  Object.keys([1, 2])
  --> ["0",  "1"]

As you can imagine, this leads to gotchas when you assume that a JS object can have, say, a date as a key

  b = {}; b[new Date()] = 10;
  Object.keys(b)
  --> [
    "Sat Nov 09 2019 23:15:58 GMT-0800 (Pacific Standard Time)"
  ]

I’m pretty sure this is wrong. JS objects and arrays are different. The former will only yield elements from the array itself when iterated on, and has a consistent iteration order, while the later does not.

https://www.ecma-international.org/ecma-262/#sec-array-exoti...

Order is consistent in both

https://www.stefanjudis.com/today-i-learned/property-order-i...

JS arrays are array-like objects. That's the official line anyway.

That's because arrays happen to override the special [Symbol.iterator] method:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Arrays are objects of class Array which have special literals, override the toString() method, and update the non-enumerable "length" property on certain operations.

Try calling Object.keys([1, 2, 3]), or even better try Object.getOwnPropertyNames([1, 2, 3])

i think that's just a matter of naming – afaik PHP "arrays" are what you'd call a map/dict/hash in other languages

I believe it is just a naming issue. Not even sure that PHP devs have agreed on how to name the type. Internally, PHP calls them both arrays and hash tables if I understand correctly.

In Zend/zend_types.h[1] of PHP source:

    typedef struct _zend_array zend_array;
    typedef struct _zend_array HashTable;
    struct _zend_array {
        ...
    };

That being said AFAICT, HashTable and zend_array are used interchangeably throughout the source. I am not a C programmer, but I did write a couple of PHP extensions and that was my general understanding. Perhaps it is a compatibility issue or just used to abstract types differently in various areas of the C API.

Check out [2] for a deeper understanding of how arrays are handled internally in PHP.

[1]: https://github.com/php/php-src/blob/php-7.3.11/Zend/zend_typ...

[2]: https://nikic.github.io/2014/12/22/PHPs-new-hashtable-implem...

rtm ?

"An array in PHP is actually an ordered map."

https://www.php.net/manual/en/language.types.array.php

> arrays-that-are-arrays-sometimes-but-maps-other-times

god, the time i spent going paranoid debugging a stray "undefined array index 0" just to find out

  array_filter(
    is_uppercase,
    ['a', 'B', 'c', 'D']
  )

returns

  [1 => 'B', 3 => 'D']

and not

  ['B', 'D']

like every other `filter(...)` i've used...

EDIT to be fair, i see the rationale – having the index of the filtered element is useful sometimes, and requires some contortions with the usual impl of filter. it's quite neat, because you get both the index and the elements! but it's just... surprising as the default, and PHP's conflation of maps and lists obscures it – all the docs say is "array keys are preserved", which makes sense in retrospect, but doesn't really jump out for something with this much impact

On the other hand, having learned PHP inside-out as my first language, this is perfectly natural to me, and I miss the flexibility of PHP arrays in other languages :)

This is exactly the sort of thing that bites. It totally breaks your functional pipelines: now you have to thread everything through `array_values`. Ew ew ew. No thank you.

PHP has come a long way, and nowadays it's in the same category as Python. Worse in many ways, but better by other, like the type declarations and their (runtime) enforcing.

Yet there are still many ugly sides to PHP, and Laravel illustrates most of them. There is so much magic that IDE can't follow: some classes have a `__call()` magic function that redirect methods calls to other instances. Some functions return values of varying types, with no common interface.

I've worked with several PHP frameworks, and Laravel is by far the worst. Its awful documentation plays a big role in this (no real reference doc, just a tutorial ; no links to classes or function in the doc ; the API doc is a joke ; the acclaimed "laracasts" are useless for serious work). The fact that this framework is dominant in the PHP community is worrying.

How long ago was your experience? I started using Laravel early last year, took a hiatus and have been actively developing in it for the past 7 months. This is coming from years with Perl Dancer / Dancer2. I have not run into these issues. But I have to admit my own bias in preferring the “show me how” instructional method over “tell me everything, no matter how esoteric”. I’ve also found Laravel superior to Dancer in every way. But I did have to get into a different mindset.

> But I have to admit my own bias in preferring the “show me how” instructional method over “tell me everything, no matter how esoteric”.

I don't think it's about preferring one approach or the other.

A good library/framework should have both instructional documentation and reference documentation. They have different use-cases and are not interchangeable.

Comparing Dancer with Laravel is a bit apples to organges, no? Mojolicious or Catalyst would make a better comparison with Laravel.

Laravel is popular because it allows you to setup your project very quickly.

And then the trouble starts. Remember what properties your models had? No? Well so doesn't your IDE. There is just too much magic going on to keep things maintainable.

If you like a framework like Laravel you should go with Symfony instead. But don't use annotations. Keeps things separated so you and your colleagues can find routing and database information at logical places instead of all over the place in classes.

Regarding model properties - there’s a standard documentation syntax that can be used to document that and give you autocomplete in your IDE (Laravel IDE helper can also auto generate these for you).

Not ideal - since it’s not enforced in anyway (the same as local scope type doc declarations). But can be useful.

For model properties and a few other IDE related issues with laravel you can use ide helper which generates annotations on your models by inspecting the schema in the database. The ide then uses the annotations and gives you property auto complete among other things.

https://github.com/barryvdh/laravel-ide-helper

Laravel, from my own experience is full of deep rooted magic, and assumptions. Also it throws SOLID out the window.

We use Symfony at work and we turned off the annotations package, use XML mapping for our models.

Of course, Symfony and Doctrine do have some frustation points.

I have the same experience. Laravel is way too magical for me.

I use Symfony for quite some time and at one point I stopped using Doctrine data mapper. The DBAL and the query builder are enough.

If it were up to me, it would all be SQL queries. Maybe even use the library I rebuilt - https://github.com/ellisgl/GeekLab-GLPDO2

I would recommend you to give Yii[0] a try. It is a solid, consistent and well thought framework with a vey good documentation. Unfortunately, It has always been eclipsed by new kids on the block frameworks like Laravel but really deserve more credits (provided you accept to let some of the laravel magic go).

I work for a web development company and We have been successfully using Yii for years now, including for medium size projects (in terms of LOC and exposure).

Just my two cents

[0] https://www.yiiframework.com

> Its awful documentation plays a big role in this

Laravel is lauded by many for its fantastic documentation. It's not comprehensive, but it's still pretty extensive, easy to read, and the gaps are only for niche situations.

As far as the API docs, what is your complaint about them?

Where are the api docs?

I know absolutely nothing about Laravel and haven't touched PHP in nearly 20 years - but within about 10 seconds on Google I found the following, which at first glance looks pretty comprehensive:

https://laravel.com/api/4.2/

That is an old version, the current being https://laravel.com/api/6.x/ but I have to agree, I have found them to be great. There is no reference to the API docs from the main website though, which I have always found odd.

There is - I guess it's not super easy to find. But if you go to the main documentation page, it's under the "Prologue" heading.

I agree in regards to Larvel. It was a breath of fresh air in the early days but they have baked so much magic into it and break backwards compatibility constantly that I have long given up even considering it. I will second the recommendation for symfony [1]. It lets you compose your app of just what components you need instead of the everything and the kitchen sink approach. However, composable systems are my preference but may not be for everyone.

[1] https://symfony.com/

php is definitely better these days (i used to use it early in my career), but unless you're already knee-deep in php, i can't think of a web project where php/laravel would generally be a better choice than ruby/rails. alas, ruby has become passé too, in favor of javascript, a decidedly unrefined language.

javascript has too many hidden ways to shoot yourself in the foot, and just hasn't evolved for developer happiness the way php and ruby have.

As a Laravel dev who almost went down the Rails path, I’m curious: what advantages do you think Rails has over Laravel at this point?

Definitely not performance [1]. Maybe aesthetics?

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Which part do you see that is not performance in that benchmark which shown the average time? I have tried benchmark on my own and PHP took longer than RubyJIT.

Every benchmark on that page is faster for PHP

"Every benchmark on that page is faster for PHP"

Let me advice you to benchmark it "accuracy" on your machine setup, don't rely what is on that page.

Make sure the error with --jit-verbose=1 which will show whether it uses MJIT correctly.

ruby --jit-verbose=1

- N-Body single core

Ruby 2.6.3 6:22.00s

RubyJIT 2.6.3 3:58.18s

PHP 7.3.xx 4:10.90s

> will show whether it uses MJIT correctly

    …
    JIT success (511.7ms): initialize@nbody.rb:14 -> /tmp/_ruby_mjit_p5804u105.c
    JIT success (397.5ms): block in offset_momentum@nbody.rb:68 -> /tmp/_ruby_mjit_p5804u106.c
    JIT success (607.0ms): block in energy@nbody.rb:50 -> /tmp/_ruby_mjit_p5804u108.c
    JIT compaction (53.6ms): Compacted 111 methods -> /tmp/_ruby_mjit_p5804u111.so
    Successful MJIT finish

    real 6m4.201s
    user 6m42.813s
    sys 0m4.041s



    $ time /opt/src/php-7.3.11/bin/php -n  nbody.php 50000000
    -0.169075164
    -0.169059907

    real 5m24.915s
    user 5m24.808s
    sys 0m0.020

As for mine, Ruby slightly faster 4:05s - 4:09s which is close to PHP in timing.

ruby 2.7.0dev (2019-11-23T07:06:30Z master b563439274) [x86_64-darwin18]

gtime -v /usr/local/bin/ruby --jit -W0 nbody.rb 50000000 -0.169075164 -0.169059907

Command being timed: "/usr/local/bin/ruby --jit -W0 nbody.rb 50000000"

User time (seconds): 249.30 System time (seconds): 0.58 Percent of CPU this job got: 100% Elapsed (wall clock) time (h:mm:ss or m:ss): 4:08.97

---

PHP 7.3.11 (cli) (built: Oct 24 2019 11:29:52) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies with Zend OPcache v7.3.11, Copyright (c) 1999-2018, by Zend Technologies

gtime -v php -n nbody.php 50000000

-0.169075164 -0.169059907

Command being timed: "php -n nbody.php 50000000" User time (seconds): 248.02 System time (seconds): 0.49 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 4:09.82

honestly i haven't looked at laravel recently enough to remember the specifics (although others here seem to have), but 2 general stengths are (1) ruby is more consistent, intuitive and fun vs. php, and (2) rails has reasonable defaults, easy configurability on top of that, and a nice ecosystem of both built-in and community-built widgets. it's so fast to get up and running with rails.

but i'd pick php over js any day! (probably even over python/django, unless data mining is a core concern)

Polish and refinement. Ruby's expressiveness and clean design make possible a level of elegance in Rails that I haven't seen in any other web framework. Ruby lends itself to DSLs much more than most other languages, Clojure excepted, and its meta-programming makes possible a number of shortcuts which help you to get a project up and running in record time. Add to that the magnitude of commits to the Rails project over its 14-year history and you have an ideal tool for SME web projects.

Considering PHP's pseudo-Java verbosity I wouldn't exactly classify it as a fast-to-develop language. Doc-block comments are an abomination if you come from Ruby,Python or Javascript and if you follow the numerous PSRs to the letter you're lucky if you can fit a couple of lines of real code on a screen surrounded as they will be by space-wasting blank lines, doc-block annotations and KR-style braces.

I guess you have not read the post you are commenting. One of the rationale behind union types is to reduce the doc-block comments. It is also, I believe, one of the idea of introducing a stronger type system in PHP.

From the original post: [quote] Supporting union types in the language allows us to move more type information from phpdoc into function signatures, ... [/quote]

There's no such thing as the perfect programming language, but there are languages that are plainly bad.

For example: I don't think anyone would seriously defend the idea that brainfuck is a reasonable language to write production code in.

Reply on news.ycombinator.com