9 ms·

A language that changes the semantics of functions between minor versions has no "right way". "count()"less examples of crap. I have currently two weeks of code

A language that changes the semantics of functions between minor versions has no "right way". "count()"less examples of crap. I have currently two weeks of code migration behind me because code running correctly on 7.0 fails on 7.3 -- while I see the reason for change was necessary I also see the hopelessness of rebuilding a flawed house with a fundament build on a pile of manure. And the good news given to me by a colleague is that they pulled the same stunt going from 7.3 to 7.4. It's like depending on stumbling alcoholics instead of language designers. Not much has changed since core devs tried to mitigate an overflow by testing for "$variable < MAXINT".

cies 5y ago
Totally agree. This is beyond taste or preference. Yes you can build a great app in PHP. But so you can in Kotlin or Ruby or ... Yes some have a career by starting with PHP. But that does not make it a good language for beginners. Same can be said (and to me is verrrry true) fro JavaScript. Language design matters. It shapes how you think about code. Talk to people who've learned AND USED many languages including some esoteric ones like Haskell, a LISP or OCaml. Then see what they have to say PHP and JS for beginners.
- berkes 5y ago
  For me, a "beginner friendly language" has these properties: * A welcoming, helping and open community. * Built-in guidance or enforcement away from The Wrong Way and towards The Right Way. E.g. by making the former hard to do and the latter easy. * Ecosystem of high-quality, properly designed libraries and sample code. I see this in e.g. Rust. But e.g. JavaScript or PHP fail on all my three points. As does my main language, Ruby, sadly.
  - magic123_ 5y ago
    While I agree on your three points, I don't think I would recommend Rust to a beginner developer.
    - berkes 5y ago
      Me neither. And I'm still not certain why not. You'll have a "hello world" in minutes. Even through something like Actix. Probably faster than your average "ruby on rails hello-world" or "react hello world". As those require a lot of up-front tooling to be set up. I guess my reluctance is that Rust very early on requires knowledge of memory-management (borrower) and intricacies such as Result and Option. While those are good to learn for a beginner at some point, that beginner probably wants to defer them to a moment that they have actual software deployed and dabble into multithreading, get runtime exceptions back and see the software crashing. Still, I think languages that don't even allow you to think about such stuff, like Python, Ruby or JS, do the beginner a disservice: typing, shared-memory, runtime exceptions and undefined behaviour are a real thing, and a beginner should at least see that the libraries and examples all take these issues into consideration. Instead of waving it away with "we have tests to cover most of it. probably" I'm Ruby dev, I deal with this daily; Learning Rust and using it in production has made me a much better Ruby dev.
  - syshum 5y ago
    #2: Strict Programming lang's. I often seen frustrate new programmers, specially young new programmers making them want to give up on programming all together so I don't know if I would call that beginner friendly, I certainly would not call rust beginner friendly I guess however we would need to define what a "beginner" target is, are we talking adults that want to learn programmed to change fields, or children wanting to inspire them to peruse programming as a career, or someone between the 2 groups
    - cies 5y ago
      If you want to learn programming, knowing how to use type systems is valuable skill from day one. For children see this (very different objectives indeed): https://www.rollapp.com/app/kturtle https://www.rollapp.com/app/kturtle
    - lbriner 5y ago
      You are right of course. The thing that many people miss is that learning isn't just one thing from, say, Hello World to a fully fledged application but it involves learning diferent types of things in different orders. For example, going straight-to-web can be hard since it involves several different concepts HTML is not CSS is not JS is not backend code (mostly!). So it is sometimes better to teach the basics in a desktop or console app using a single language with a single paradigm. Once they understand that, you could introduce other abstractions and explain why sometimes strong type-checking is useful and other times it is unecessary and time-wasting.
      - syshum 5y ago
        While I can understand that approach, I do wonder if my origin to programming is common or not. I did not get in to programming to become a programmer. I learned programming to solve a problem I was having, in my case I did start out in web development in the 90's. I wanted a website that did something that I could not find premade software that did it in the way I wanted so I wrote my own. I also learned of open source and and other communities via this process. Had I just stuck with the commercial software solution I bought, that was terrible, I would have missed out on on a skill I eventually learned to love. The website (and company around it) I built was never successful, but from that experience I learned a skill that carried me to the career I now have
- lowwave 5y ago
  > Same can be said (and to me is verrrry true) fro JavaScript. Not if you use JS like Scheme: https://www.crockford.com/little.html https://www.crockford.com/little.html In fact JS is much more pleasant to write than PHP, the main reason to move way from PHP after using it for over 10 years.
  - conradfr 5y ago
    I guess it's a matter of preference because I find writing Javascript tedious, the forced async when not needed, or that for some reason Node doesn't give me a line and a description when I make a mistake, it just ... fails?
  - mkdirp 5y ago
    JavaScript: the language that can barely understand itself is better than PHP! The language, where JetBrain's IDE (arguably one of the best IDEs when it comes to understanding languages, consistently better than any LSPs among other things) can barely understand it fully, is better than PHP! The language that has consistently added new features, but have yet to fix horrible messes of legacy design. The majority of Gary Bernhardt's 2012 talk "wat"[0] is still relevant today with JavaScript. PHP's devs at least are actively trying to address the majority of issues people have had problems with, and have done so successfully for many of the issues it had. In my opinion the only thing JavaScript has going for it over PHP is its ability to develop frontend and backend code using the same language, but then, you know, you'll need a million NPM dependencies if you pull in some of the simplest packages. Until TypeScript takes over JavaScript I refuse to believe anyone who understands either languages fully prefers JS over PHP. I've yet to dabble in Deno, but I'm hoping that it also addresses much of the issues with JS, but I'm doubtful since it's also based on V8. [0] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
    - cies 5y ago
      The linked talk is soo true and so hilarious.
    - infensus 5y ago
- nesarkvechnep 5y ago
  Elixir is one such language for beginners.
deleted 5y ago
[deleted]
dotancohen 5y ago
I've upgraded quite a few PHP systems, and 7.2 was the major stumbling block that I've seen for most projects. Which "changes the semantics of functions between minor versions" are you referring to? In the 7.0 update there was the changing of order that e.g. $foo[bar]->boom[baz] would be evaluated, but obviously that isn't your complaint.
medv 5y ago
PHP versions don’t follow semver. And yes, it’s ok. Semver not a silver bullet.
pooya72 5y ago
Also a lot of the positive changes were do to the efforts of Nikita Popov[1] who has now left. It's led to the creation of the PHP foundation.[2] I haven't kept up to date with the foundation's efforts. [1]:https://www.npopov.com/aboutMe.html https://www.npopov.com/aboutMe.html [2]:https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundation/ https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundati...
- Darmody 5y ago
  Nikita is a beast, one of the smartests guys around. I wish I was half as smart as he is.
kilburn 5y ago
I was curious about this rant since I'm maintaning a number of PHP projects and I haven't had any issues with "count". In the Changelog section of the "count" docs at https://www.php.net/manual/en/function.count.php https://www.php.net/manual/en/function.count.php we find: > 7.2.0 - count() will now yield a warning on invalid countable types passed to the value parameter. So in 7.2.0 they started raising a warning in cases where the application was doing a stupid thing (calling count on a non-countable object). Notice that PHP's warnings won't stop execution by default. The expected side-effect here is that you get a warning in the logs and everything keeps working normally. Of course, many development setups halt execution on warnings, but this is a decision that devs make to "force" them to writte better code, not something enforced by PHP itself. > 8.0.0 - count() will now throw TypeError on invalid countable types passed to the value parameter. In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say. Of course it would've been better if this was an error from the beginning, but given a mistake was made here, this is definitely the best way to correct it I can think of. I'm sorry it took time for you to fix the legacy apps you've inherited. However, calling this out as an example of bad programming language evolution seems very wrong to me. I for one would LOVE that all languages and libraries in my project's dependency chains where as dilligent as in this example.
- throwaway_r211 5y ago
  > In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say. Breaking changes (at runtime no less) are the worst way to improve any language. They should have created a new count method if they wanted to change behavior in a breaking way. Forcing millions of developers to comb through their code just because some designer doesn't like the way someone else does something is just narcissistic. p.s. Semver isn't worth the shit paper its printed on, it can't even version itself and all it does is give shit developers shit excuses to impose their own naval gazing induced shitstorms on other developers.
  - mszcz 5y ago
    I don't think that having two different count()s with different edge-case behavior is the way it should've been improved. If someone used the method incorrectly in the past it's part their fault for writing it incorrectly and part PHP's that it didn't fail (and "fail" is also kind of a stretch since the behavior was described in the docs IIRC).
cletus 5y ago
I assume then that you disqualify Python for the same reason? Python 3.x has decided that breaking changes in minor releases is fine. My favourite: string prefixes (eg s'foo', u'foo') were legal in 2.x, removed in 3.0, added back in 3.3. There are other subtle breakages (eg open() flags). Hating on PHP is a tired cliche at this point.
- faho 5y ago
  >Python 3.x has decided that breaking changes in minor releases is fine. My favourite: string prefixes (eg s'foo', u'foo') were legal in 2.x, removed in 3.0, added back in 3.3. Python 3.0 was very much not a minor release, so your example is invalid. The general point that Python does breaking changes in minor releases stands, but they do typically go through a deprecation period first.
SergeAx 5y ago
PHP doesn't guarantee backward compatibility between minor version. It is the way things are in PHP since 5.x, when Semver wasn't even a thing.
mrunkel 5y ago
https://getrector.org/ https://getrector.org/

cies 5y ago

Totally agree. This is beyond taste or preference. Yes you can build a great app in PHP. But so you can in Kotlin or Ruby or ... Yes some have a career by starting with PHP. But that does not make it a good language for beginners. Same can be said (and to me is verrrry true) fro JavaScript. Language design matters. It shapes how you think about code. Talk to people who've learned AND USED many languages including some esoteric ones like Haskell, a LISP or OCaml. Then see what they have to say PHP and JS for beginners.

berkes 5y ago
For me, a "beginner friendly language" has these properties: * A welcoming, helping and open community. * Built-in guidance or enforcement away from The Wrong Way and towards The Right Way. E.g. by making the former hard to do and the latter easy. * Ecosystem of high-quality, properly designed libraries and sample code. I see this in e.g. Rust. But e.g. JavaScript or PHP fail on all my three points. As does my main language, Ruby, sadly.
- magic123_ 5y ago
  While I agree on your three points, I don't think I would recommend Rust to a beginner developer.
  - berkes 5y ago
    Me neither. And I'm still not certain why not. You'll have a "hello world" in minutes. Even through something like Actix. Probably faster than your average "ruby on rails hello-world" or "react hello world". As those require a lot of up-front tooling to be set up. I guess my reluctance is that Rust very early on requires knowledge of memory-management (borrower) and intricacies such as Result and Option. While those are good to learn for a beginner at some point, that beginner probably wants to defer them to a moment that they have actual software deployed and dabble into multithreading, get runtime exceptions back and see the software crashing. Still, I think languages that don't even allow you to think about such stuff, like Python, Ruby or JS, do the beginner a disservice: typing, shared-memory, runtime exceptions and undefined behaviour are a real thing, and a beginner should at least see that the libraries and examples all take these issues into consideration. Instead of waving it away with "we have tests to cover most of it. probably" I'm Ruby dev, I deal with this daily; Learning Rust and using it in production has made me a much better Ruby dev.
- syshum 5y ago
  #2: Strict Programming lang's. I often seen frustrate new programmers, specially young new programmers making them want to give up on programming all together so I don't know if I would call that beginner friendly, I certainly would not call rust beginner friendly I guess however we would need to define what a "beginner" target is, are we talking adults that want to learn programmed to change fields, or children wanting to inspire them to peruse programming as a career, or someone between the 2 groups
  - cies 5y ago
    If you want to learn programming, knowing how to use type systems is valuable skill from day one. For children see this (very different objectives indeed): https://www.rollapp.com/app/kturtle https://www.rollapp.com/app/kturtle
  - lbriner 5y ago
    You are right of course. The thing that many people miss is that learning isn't just one thing from, say, Hello World to a fully fledged application but it involves learning diferent types of things in different orders. For example, going straight-to-web can be hard since it involves several different concepts HTML is not CSS is not JS is not backend code (mostly!). So it is sometimes better to teach the basics in a desktop or console app using a single language with a single paradigm. Once they understand that, you could introduce other abstractions and explain why sometimes strong type-checking is useful and other times it is unecessary and time-wasting.
    - syshum 5y ago
      While I can understand that approach, I do wonder if my origin to programming is common or not. I did not get in to programming to become a programmer. I learned programming to solve a problem I was having, in my case I did start out in web development in the 90's. I wanted a website that did something that I could not find premade software that did it in the way I wanted so I wrote my own. I also learned of open source and and other communities via this process. Had I just stuck with the commercial software solution I bought, that was terrible, I would have missed out on on a skill I eventually learned to love. The website (and company around it) I built was never successful, but from that experience I learned a skill that carried me to the career I now have
lowwave 5y ago
> Same can be said (and to me is verrrry true) fro JavaScript. Not if you use JS like Scheme: https://www.crockford.com/little.html https://www.crockford.com/little.html In fact JS is much more pleasant to write than PHP, the main reason to move way from PHP after using it for over 10 years.
- conradfr 5y ago
  I guess it's a matter of preference because I find writing Javascript tedious, the forced async when not needed, or that for some reason Node doesn't give me a line and a description when I make a mistake, it just ... fails?
- mkdirp 5y ago
  JavaScript: the language that can barely understand itself is better than PHP! The language, where JetBrain's IDE (arguably one of the best IDEs when it comes to understanding languages, consistently better than any LSPs among other things) can barely understand it fully, is better than PHP! The language that has consistently added new features, but have yet to fix horrible messes of legacy design. The majority of Gary Bernhardt's 2012 talk "wat"[0] is still relevant today with JavaScript. PHP's devs at least are actively trying to address the majority of issues people have had problems with, and have done so successfully for many of the issues it had. In my opinion the only thing JavaScript has going for it over PHP is its ability to develop frontend and backend code using the same language, but then, you know, you'll need a million NPM dependencies if you pull in some of the simplest packages. Until TypeScript takes over JavaScript I refuse to believe anyone who understands either languages fully prefers JS over PHP. I've yet to dabble in Deno, but I'm hoping that it also addresses much of the issues with JS, but I'm doubtful since it's also based on V8. [0] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
  - cies 5y ago
    The linked talk is soo true and so hilarious.
  - infensus 5y ago
nesarkvechnep 5y ago
Elixir is one such language for beginners.

deleted 5y ago

[deleted]

dotancohen 5y ago

I've upgraded quite a few PHP systems, and 7.2 was the major stumbling block that I've seen for most projects. Which "changes the semantics of functions between minor versions" are you referring to? In the 7.0 update there was the changing of order that e.g. $foo[bar]->boom[baz] would be evaluated, but obviously that isn't your complaint.

medv 5y ago

PHP versions don’t follow semver. And yes, it’s ok. Semver not a silver bullet.

pooya72 5y ago

Also a lot of the positive changes were do to the efforts of Nikita Popov[1] who has now left. It's led to the creation of the PHP foundation.[2] I haven't kept up to date with the foundation's efforts. [1]:https://www.npopov.com/aboutMe.html https://www.npopov.com/aboutMe.html [2]:https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundation/ https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundati...

Darmody 5y ago
Nikita is a beast, one of the smartests guys around. I wish I was half as smart as he is.

kilburn 5y ago

I was curious about this rant since I'm maintaning a number of PHP projects and I haven't had any issues with "count". In the Changelog section of the "count" docs at https://www.php.net/manual/en/function.count.php https://www.php.net/manual/en/function.count.php we find: > 7.2.0 - count() will now yield a warning on invalid countable types passed to the value parameter. So in 7.2.0 they started raising a warning in cases where the application was doing a stupid thing (calling count on a non-countable object). Notice that PHP's warnings won't stop execution by default. The expected side-effect here is that you get a warning in the logs and everything keeps working normally. Of course, many development setups halt execution on warnings, but this is a decision that devs make to "force" them to writte better code, not something enforced by PHP itself. > 8.0.0 - count() will now throw TypeError on invalid countable types passed to the value parameter. In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say. Of course it would've been better if this was an error from the beginning, but given a mistake was made here, this is definitely the best way to correct it I can think of. I'm sorry it took time for you to fix the legacy apps you've inherited. However, calling this out as an example of bad programming language evolution seems very wrong to me. I for one would LOVE that all languages and libraries in my project's dependency chains where as dilligent as in this example.

throwaway_r211 5y ago
> In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say. Breaking changes (at runtime no less) are the worst way to improve any language. They should have created a new count method if they wanted to change behavior in a breaking way. Forcing millions of developers to comb through their code just because some designer doesn't like the way someone else does something is just narcissistic. p.s. Semver isn't worth the shit paper its printed on, it can't even version itself and all it does is give shit developers shit excuses to impose their own naval gazing induced shitstorms on other developers.
- mszcz 5y ago
  I don't think that having two different count()s with different edge-case behavior is the way it should've been improved. If someone used the method incorrectly in the past it's part their fault for writing it incorrectly and part PHP's that it didn't fail (and "fail" is also kind of a stretch since the behavior was described in the docs IIRC).

cletus 5y ago

I assume then that you disqualify Python for the same reason? Python 3.x has decided that breaking changes in minor releases is fine. My favourite: string prefixes (eg s'foo', u'foo') were legal in 2.x, removed in 3.0, added back in 3.3. There are other subtle breakages (eg open() flags). Hating on PHP is a tired cliche at this point.

faho 5y ago
>Python 3.x has decided that breaking changes in minor releases is fine. My favourite: string prefixes (eg s'foo', u'foo') were legal in 2.x, removed in 3.0, added back in 3.3. Python 3.0 was very much not a minor release, so your example is invalid. The general point that Python does breaking changes in minor releases stands, but they do typically go through a deprecation period first.

SergeAx 5y ago

PHP doesn't guarantee backward compatibility between minor version. It is the way things are in PHP since 5.x, when Semver wasn't even a thing.

mrunkel 5y ago

https://getrector.org/ https://getrector.org/