<story><title>OO in Python is mostly pointless</title><url>https://leontrolski.github.io/mostly-pointless.html</url></story><parent_chain><item><author>fleabitdev</author><text>How do you compensate for the lack of type-dependent name resolution? MyModule.foo(my_t) seems verbose, compared to my_t.foo()</text></item><item><author>Ankintol</author><text>&amp;gt; In general, object orientation is a reasonably elegant way of binding together a compound data type and functions that operate on that data type. Let us accept this at least, and be happy to use it if we want to!&lt;p&gt;Is it elegant? OO couples data types to the functions that operate on them. After years of working on production OO I&amp;#x27;ve still never come across a scenario where I wouldn&amp;#x27;t have been equally or better served by a module system that lets me co-locate the type with the most common operations on that type with all the auto-complete I want:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  &amp;#x2F;&amp;#x2F;type
  MyModule {
    type t = ...
  
    func foo = ...
    func bar = ...
  }

&lt;/code&gt;&lt;/pre&gt;
If I want to make use of the type without futzing around with the module, I just grab it and write my own function</text></item><item><author>gorgoiler</author><text>In general, object orientation is a reasonably elegant way of binding together a compound data type and functions that operate on that data type.  Let us accept this at least, and be happy to use it if we want to!  It is &lt;i&gt;useful&lt;/i&gt;.&lt;p&gt;What are emphatically &lt;i&gt;not&lt;/i&gt; pretty or useful are Python’s leading underscores to loosely enforce encapsulation. Ugh.  I’d sooner use camelCase.&lt;p&gt;Nor do I find charming the belligerent lack of any magical syntactic sugar for `self`. Does Python force you to pass it as an argument to make some kind of clever point?  Are there psychotic devs out there who call it something other than `self`? Yuck!&lt;p&gt;And why are some classes (int, str, float) allowed to be lower case but when I try to join that club I draw the ire from the linters?  The arrogance!&lt;p&gt;...but I still adore Python.  &lt;i&gt;People call these things imperfections but it’s just who we are.&lt;/i&gt;&lt;p&gt;PS I liked the Python5 joke a lot.</text></item></parent_chain><comment><author>dan-robertson</author><text>Most of the time you have:&lt;p&gt;- short names inside modules. I.e. you might have a function called Foo.merge(...) instead of x.merge_with_foo(...)&lt;p&gt;- a way to bring modules into scope so you don’t need to specify the name&lt;p&gt;- not using that many modules. Most lines of code won’t have more than one or two function calls so it shouldn’t matter that much (other techniques can be used in complicated situations)&lt;p&gt;The key advantage of type-dependant name resolution is in using the same names for different types. You might want to write code like foo.map(...) and it is ok if you don’t know the exact type of foo. With modules you may need to know whether to call SimpleFoo.map or CompoundFoo.map.</text></comment>
<story><title>OO in Python is mostly pointless</title><url>https://leontrolski.github.io/mostly-pointless.html</url></story><parent_chain><item><author>fleabitdev</author><text>How do you compensate for the lack of type-dependent name resolution? MyModule.foo(my_t) seems verbose, compared to my_t.foo()</text></item><item><author>Ankintol</author><text>&amp;gt; In general, object orientation is a reasonably elegant way of binding together a compound data type and functions that operate on that data type. Let us accept this at least, and be happy to use it if we want to!&lt;p&gt;Is it elegant? OO couples data types to the functions that operate on them. After years of working on production OO I&amp;#x27;ve still never come across a scenario where I wouldn&amp;#x27;t have been equally or better served by a module system that lets me co-locate the type with the most common operations on that type with all the auto-complete I want:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  &amp;#x2F;&amp;#x2F;type
  MyModule {
    type t = ...
  
    func foo = ...
    func bar = ...
  }

&lt;/code&gt;&lt;/pre&gt;
If I want to make use of the type without futzing around with the module, I just grab it and write my own function</text></item><item><author>gorgoiler</author><text>In general, object orientation is a reasonably elegant way of binding together a compound data type and functions that operate on that data type.  Let us accept this at least, and be happy to use it if we want to!  It is &lt;i&gt;useful&lt;/i&gt;.&lt;p&gt;What are emphatically &lt;i&gt;not&lt;/i&gt; pretty or useful are Python’s leading underscores to loosely enforce encapsulation. Ugh.  I’d sooner use camelCase.&lt;p&gt;Nor do I find charming the belligerent lack of any magical syntactic sugar for `self`. Does Python force you to pass it as an argument to make some kind of clever point?  Are there psychotic devs out there who call it something other than `self`? Yuck!&lt;p&gt;And why are some classes (int, str, float) allowed to be lower case but when I try to join that club I draw the ire from the linters?  The arrogance!&lt;p&gt;...but I still adore Python.  &lt;i&gt;People call these things imperfections but it’s just who we are.&lt;/i&gt;&lt;p&gt;PS I liked the Python5 joke a lot.</text></item></parent_chain><comment><author>Smaug123</author><text>If anything, this is an &lt;i&gt;aid&lt;/i&gt; to type-checking. Since MyModule.foo takes only things of type t, the type-checker&amp;#x27;s job is extremely easy and it will help you a lot more in cases when your program is incomplete.&lt;p&gt;So often when using C#-style fluent APIs I find that I&amp;#x27;m completely on my own and have to turn a half-written line into something syntactically correct before Intellisense gives me anything useful. Using an F#-style MyModule.foo, the compiler can tell me everything.</text></comment>