7 ms·

Anybody else feeling that strict typing and long var names are not worth all the visual overload? Example: https://github.com/wikimedia/parsoid/blob/master/src

Anybody else feeling that strict typing and long var names are not worth all the visual overload? Example: https://github.com/wikimedia/parsoid/blob/master/src/Parsoid.php#L235 https://github.com/wikimedia/parsoid/blob/master/src/Parsoid... This is how I would write the function definition: function html2wikitext($config, $html, $options = [], $data = null) This how Wikimedia did it: public function html2wikitext( PageConfig $pageConfig, string $html, array $options = [], ?SelserData $selserData = null ): string I see this "strictness over readability" on the rise in many places and I think it is a net negative. Not totally sure, but this seems to be the old JS function definition: https://github.com/abbradar/parsoid/blob/master/lib/parse.js#L70 https://github.com/abbradar/parsoid/blob/master/lib/parse.js... A bit cryptic and it suffers from the typical promise / async / callback / nesting horror so common in the Javascript world: _html2wt = Promise.async(function *(obj, env, html, pb)

luckylion 7y ago
I like long names because autocomplete usually means typing speed doesn't matter and they are more verbose, so less thinking when I come back to the code next week. Same goes for strong typing, it makes you think when you write it so you (or somebody else) have to think less when you read it, and obviously it keeps you from making mistakes, helps the IDE make useful suggestions etc.
- TicklishTiger 7y ago
  Me: Many people like X. Anybody here who likes Y? You: I like X!
  - luckylion 7y ago
    Sorry, I'm bad at reading, I understood your question as mostly "why do people like X?"
  - darkwater 7y ago
    But you also say > I see this "strictness over readability" on the rise in many places and I think it is a net negative. which makes your tastes a bit more... absolute to say something. So it makes sense to me that people reply to your negative view with counter arguments.
ablomen 7y ago
I did not like/see the real benefit of strict typing until actually using Typescript. Now for me the more verbose code and extra typing is vastly outweighed by knowing what arguments the function actually wants, especially when using 3rd party libraries. The time saved by real-time type checking in my editor compared to edit->run->crash->edit is almost unbelievable and the amount of errors in code I ported over that we did not come across in production is also huge. So no, I think the visual overload is definitely worth it.
hnzix 7y ago
Strict typing has an overhead, but the payoff is apparent when working with a large dev team of variable skill levels. People can make a mess in any language but it's easier to decode with strict typing. For lone wolf coding or rapid prototyping the equation is different.
- b3kart 7y ago
  I've never worked in a large team that has used a dynamically typed language. To me it sounds like a nightmare, especially given that I know how little time is typically left for documentation. I see that it could work if you enforce type annotations. But then you might as well use a strongly typed language.
  - hnzix 7y ago
    I've worked on a 15 person team using Perl that was actually pleasant because everyone was A grade, actively did code reviews and the two seniors were A+ and would kick your ass for bad code. But most teams aren't like that so would benefit from strong typing.
    - acqq 7y ago
      And Perl has many aspects of strength compared with Python or Javascript. See for example: https://news.ycombinator.com/item?id=22282080 https://news.ycombinator.com/item?id=22282080 and https://news.ycombinator.com/item?id=22282306 https://news.ycombinator.com/item?id=22282306 For what comes out of the box with Perl regarding undefined variables. Perl has "my" "local" and "ours" for the start but even more: the array and hash variables have by design different syntax, which helps immensely: the sigils are of real help as a kind of written "type." It's like in old Basics string variables looked different from the numeric ones, and Larry Wall acknowledged he was inspired by that. I can go on and on. Perl looks hard to the uninitiated but it can produce much more stable code, in my experience, than the "typical" scripting languages like Python and Javascript. Stable in the sense that you know it will work after it compiles, not only once you test with every possible input. But yes, the people using it should know learn enough before they start contributing, and in a lot of places it's preferred to have people who barely know the basics of what they use (because they are "cheap" and "easily replaceable").
b3kart 7y ago
Reformat your example slightly, and suddenly it's not so bad: public function html2wikitext( PageConfig $pageConfig, string $html, array $options = [], ?SelserData $selserData = null ): string I am sure an IDE could do that for you. That being said, I think the Python way of formatting type annotations ("variable : type") is more readable than C-style "type variable = ...", especially when the annotation is optional.
nicoburns 7y ago
I'll bet the typed version is a lot more readable with syntax highlighting.
Cthulhu_ 7y ago
Your first function definition leans HEAVILY on implicit knowledge - what does $config mean? What does $html mean? What are valid properties of $config and $data? This is fine in smaller codebases, 'your' code, and code that you can read to a point where you can extrapolate these variables from the implementation, but this simply does not scale beyond a certain code size - or more importantly, a certain amount of contributors. It can be compensated with documentation (phpDoc), but that is just as verbose if not moreso than adding type information - although you should probably do both. Type systems come into place where you are not expected anymore to fully comprehend the code. They are useful when you are just a consumer / user of this function and all you want to do is convert some html to wiki text without having to understand the internals of that particular function (and whatever else goes on beyond it). Types are documentation, prevent shooting yourself in the foot, reduce trial-and-error, and avoid the user having to read and comprehend hundreds - thousands of lines of code.
- aurbano 7y ago
  This. Passing a variable named $config, or options, settings... etc, to a function with no type definition is the recipe for unmaintainability.
- egeozcan 7y ago
  Why would you add a docblock on top of your already typed functions? Maybe just description would be cool but phpdoc with all the duplicated parameter definitions? I think it's unnecessary but would love to hear other perspectives.
  - Eremotherium 7y ago
    You can add e.g. descriptions to your params if needed. Also phpdoc understands types like string[] for arrays and union types like (int|string) for untyped params.
ulucs 7y ago
Honestly, I think the tooling should allow you to write just function html2wikitext($config, $html, $options = [], $data) and then infer the types, and subsequently enforce them. The typechecker should only complain when it can't infer the types (a-la strict). If you use tooling to reduce verbosity, you'll have best of both worlds simultaneously.
Piskvorrr 7y ago
You can then e.g. run a static analyzer over it, which can say things like 'in SomeOtherFile.php:130, you're passing $config="nope"; this is a string, not what the function expects to handle' or 'html2wikitext is supposed to return string, you're returning a DateTimeImmutable at line 160'. Same with the access modifiers: 'private function whatever() is unused'. Further, documentation: "of course everybody knows what you're supposed and forbidden to pass into $data" - NOT. Even if it's just you writing the code: the you+1year will have trouble reading it (been there). Not even when it's supposed to be documented. If you have an explicit data structure, this becomes far more evident, even before any documentation (note: not replacing it). I'm not interested in playing computer in my head any more, juggling internal state that's completely superfluous to me: am I a higher primate? Yes. Are higher primates tool users? Also yes. Should I let machines do the menial tasks for me, leaving me to do the creative ones? A hundred times yes. (NB: this is not a silver bullet - e.g. won't help against logic errors - but it's a useful guard against going completely off the rails)
plopz 7y ago
I agree with you, I prefer your structure. I actually wish PHP hadn't added typing, if I wanted that I wouldn't have chosen PHP in the first place.

luckylion 7y ago

I like long names because autocomplete usually means typing speed doesn't matter and they are more verbose, so less thinking when I come back to the code next week. Same goes for strong typing, it makes you think when you write it so you (or somebody else) have to think less when you read it, and obviously it keeps you from making mistakes, helps the IDE make useful suggestions etc.

TicklishTiger 7y ago
Me: Many people like X. Anybody here who likes Y? You: I like X!
- luckylion 7y ago
  Sorry, I'm bad at reading, I understood your question as mostly "why do people like X?"
- darkwater 7y ago
  But you also say > I see this "strictness over readability" on the rise in many places and I think it is a net negative. which makes your tastes a bit more... absolute to say something. So it makes sense to me that people reply to your negative view with counter arguments.

ablomen 7y ago

I did not like/see the real benefit of strict typing until actually using Typescript. Now for me the more verbose code and extra typing is vastly outweighed by knowing what arguments the function actually wants, especially when using 3rd party libraries. The time saved by real-time type checking in my editor compared to edit->run->crash->edit is almost unbelievable and the amount of errors in code I ported over that we did not come across in production is also huge. So no, I think the visual overload is definitely worth it.

hnzix 7y ago

Strict typing has an overhead, but the payoff is apparent when working with a large dev team of variable skill levels. People can make a mess in any language but it's easier to decode with strict typing. For lone wolf coding or rapid prototyping the equation is different.

b3kart 7y ago
I've never worked in a large team that has used a dynamically typed language. To me it sounds like a nightmare, especially given that I know how little time is typically left for documentation. I see that it could work if you enforce type annotations. But then you might as well use a strongly typed language.
- hnzix 7y ago
  I've worked on a 15 person team using Perl that was actually pleasant because everyone was A grade, actively did code reviews and the two seniors were A+ and would kick your ass for bad code. But most teams aren't like that so would benefit from strong typing.
  - acqq 7y ago
    And Perl has many aspects of strength compared with Python or Javascript. See for example: https://news.ycombinator.com/item?id=22282080 https://news.ycombinator.com/item?id=22282080 and https://news.ycombinator.com/item?id=22282306 https://news.ycombinator.com/item?id=22282306 For what comes out of the box with Perl regarding undefined variables. Perl has "my" "local" and "ours" for the start but even more: the array and hash variables have by design different syntax, which helps immensely: the sigils are of real help as a kind of written "type." It's like in old Basics string variables looked different from the numeric ones, and Larry Wall acknowledged he was inspired by that. I can go on and on. Perl looks hard to the uninitiated but it can produce much more stable code, in my experience, than the "typical" scripting languages like Python and Javascript. Stable in the sense that you know it will work after it compiles, not only once you test with every possible input. But yes, the people using it should know learn enough before they start contributing, and in a lot of places it's preferred to have people who barely know the basics of what they use (because they are "cheap" and "easily replaceable").

b3kart 7y ago

Reformat your example slightly, and suddenly it's not so bad: public function html2wikitext( PageConfig $pageConfig, string $html, array $options = [], ?SelserData $selserData = null ): string I am sure an IDE could do that for you. That being said, I think the Python way of formatting type annotations ("variable : type") is more readable than C-style "type variable = ...", especially when the annotation is optional.

nicoburns 7y ago

I'll bet the typed version is a lot more readable with syntax highlighting.

Cthulhu_ 7y ago

Your first function definition leans HEAVILY on implicit knowledge - what does $config mean? What does $html mean? What are valid properties of $config and $data? This is fine in smaller codebases, 'your' code, and code that you can read to a point where you can extrapolate these variables from the implementation, but this simply does not scale beyond a certain code size - or more importantly, a certain amount of contributors. It can be compensated with documentation (phpDoc), but that is just as verbose if not moreso than adding type information - although you should probably do both. Type systems come into place where you are not expected anymore to fully comprehend the code. They are useful when you are just a consumer / user of this function and all you want to do is convert some html to wiki text without having to understand the internals of that particular function (and whatever else goes on beyond it). Types are documentation, prevent shooting yourself in the foot, reduce trial-and-error, and avoid the user having to read and comprehend hundreds - thousands of lines of code.

aurbano 7y ago
This. Passing a variable named $config, or options, settings... etc, to a function with no type definition is the recipe for unmaintainability.
egeozcan 7y ago
Why would you add a docblock on top of your already typed functions? Maybe just description would be cool but phpdoc with all the duplicated parameter definitions? I think it's unnecessary but would love to hear other perspectives.
- Eremotherium 7y ago
  You can add e.g. descriptions to your params if needed. Also phpdoc understands types like string[] for arrays and union types like (int|string) for untyped params.

ulucs 7y ago

Honestly, I think the tooling should allow you to write just function html2wikitext($config, $html, $options = [], $data) and then infer the types, and subsequently enforce them. The typechecker should only complain when it can't infer the types (a-la strict). If you use tooling to reduce verbosity, you'll have best of both worlds simultaneously.

Piskvorrr 7y ago

You can then e.g. run a static analyzer over it, which can say things like 'in SomeOtherFile.php:130, you're passing $config="nope"; this is a string, not what the function expects to handle' or 'html2wikitext is supposed to return string, you're returning a DateTimeImmutable at line 160'. Same with the access modifiers: 'private function whatever() is unused'. Further, documentation: "of course everybody knows what you're supposed and forbidden to pass into $data" - NOT. Even if it's just you writing the code: the you+1year will have trouble reading it (been there). Not even when it's supposed to be documented. If you have an explicit data structure, this becomes far more evident, even before any documentation (note: not replacing it). I'm not interested in playing computer in my head any more, juggling internal state that's completely superfluous to me: am I a higher primate? Yes. Are higher primates tool users? Also yes. Should I let machines do the menial tasks for me, leaving me to do the creative ones? A hundred times yes. (NB: this is not a silver bullet - e.g. won't help against logic errors - but it's a useful guard against going completely off the rails)

plopz 7y ago

I agree with you, I prefer your structure. I actually wish PHP hadn't added typing, if I wanted that I wouldn't have chosen PHP in the first place.