4 ms·

Haskell has always officially inspired Python tooling. But Python does things in it's own way, and they are not random, they are the result of an opinion. Firs

Haskell has always officially inspired Python tooling. But Python does things in it's own way, and they are not random, they are the result of an opinion. First class citizen functions, short lambdas, comprehension lists, generators, map(), filter(), itertools, operator and functools are quite a rich toolbox already. But you won't have more. It's a choice. The idea is to have enough to be productive, and not enough to be dogmatic. The experience of Guido, and it's one that I share, is that too much functional tooling drives a style that favors expressive writing at the expense of ease of reading. It's not by chance that LISP and Haskell are considered hard languages to get into, while Python is considered easy to start with. It has a cost, since no language is perfect, but that's the path this language follows and requesting a snake to fly will only bring you disappointments. Python tries to strike the balance between the importance of a rich expressiveness and the non negotiable necessity of keeping the code readable: you read a line much more often that you write it, after all. It's a key philosophy of the language. It shaped and will shape numerous decisions around it. This PEP is a perfect example : it tooks years for the concept to be integrated in Python, and the last debate about this concrete implementation took months. The result is a carefully crafted feature with a lot of details to discourage abuse and remove the needs for pondering when to use it or not.

nikofeyn 8y ago
you are right that python is an opinionated choice, but that particularly chosen philosophy is what people disagree with. the philosophy is somewhat stubborn as well. and i think you are leaving out functional languages which share python's readability, if not surpass it, while remaining much more expressive. that's f# and ocaml. f#, in my opinion, is superior in everyway to python and subsumes python's abilities of readability, easiness, oop, and scripting, while greatly raising the ceiling of possibility. it's criminally underused, especially in areas where python has been chosen. and i disagree lisp is harder to get into. racket is just as easy to learn as python, if not easier, due to its regularity. the how to code / systematic program design course on edX and the book how to design programs showcases this.
- sametmax 8y ago
  I heard good things about F# and I did like C#, so I wanted to give an honest look at your arguments. The first thing I checked is your very vocal assurance that F# is a better scripting language than Python. That seemed very weird to me, after all it's Python strong point. Since I script a lot, I looked for the most popular F# lib to parse script arguments. Argu seems the winner, according to http://fsharpworks.com/survey.html http://fsharpworks.com/survey.html. Their tutorial is pretty good (https://fsprojects.github.io/Argu/tutorial.html https://fsprojects.github.io/Argu/tutorial.html), and here is their hello world. 24 lines of, packing a dense symbology and using a lot of the specific language features: open Argu type CLIArguments = | Working_Directory of path:string | Listener of host:string * port:int | Data of base64:byte[] | Port of tcp_port:int | Log_Level of level:int | Detach with interface IArgParserTemplate with member s.Usage = match s with | Working_Directory _ -> "specify a working directory." | Listener _ -> "specify a listener (hostname : port)." | Data _ -> "binary data in base64 encoding." | Port _ -> "specify a primary port." | Log_Level _ -> "set the log level." | Detach _ -> "detach daemon from console." let parser = ArgumentParser.Create<CLIArguments>(programName = "gadget.exe") let results = parser.Parse [| "--detach" ; "--listener" ; "localhost" ; "8080" |] printfn "%A" results.GetAllResults();; The same thing with click, the Python most popular solution, is 11 lines, and it's shaped around almost only regular calls and parameters: import click as cli, base64, urllib.parse as url @cli.command("gadget.exe") @cli.option('--working-directory', help='specify a working directory.', type=cli.File('rb')) @cli.option('--listener', help="specify a listener (hostname : port)", type=url.urlparse) @cli.option('--data', help='binary data in base64 encoding.', type=base64.b64decode) @cli.option('--port', help='"specify a working directory.', type=cli.File('rb')) @cli.option('--log-level', help='set the log level.', type=int) @cli.option('--detach', is_flag=True, help='detach daemon from console') def hello(**kwargs): print(kwargs) hello(["--detach", "--listener", "localhost:8080"]) I have a hard time finding the motivation to look for the truth behind your other arguments after that.
  - nikofeyn 8y ago
hellofunk 8y ago
> The experience of Guido, and it's one that I share, is that too much functional tooling drives a style that favors expressive writing at the expense of ease of reading. This is absolutely dead on accurate. As a Clojure developer, using one of the most expressive -- dare I say, artistic -- programming languages ever created, I can say that I am totally in the zone writing code which is elegant and terse and really packs a punch, does clever things.... and then just a few days later, it is very hard for my own brain to parse my own code and figure out what it does. For each line of code you write once, it will be read dozens of times by you or others. Code is for reading. Languages that get this right make things a lot easier for everyone.
- roman_g 8y ago
  What other languages do you think "made it right" ?
marcosdumay 8y ago
Map, filter and a lot of the itertools contents lose most of their possible power if you let easy lambdas and function composition out. The only dogmatic position here is the Python one, that based on opinion alone, and is leaving a lot of good structures out for no gain at all.
ernst_klim 8y ago
>It's not by chance that LISP and Haskell It's only because Python is familiar and Haskell is not. Objectively both Haskell and Lisp are dramatically more simple to comprehend than python.

nikofeyn 8y ago

you are right that python is an opinionated choice, but that particularly chosen philosophy is what people disagree with. the philosophy is somewhat stubborn as well. and i think you are leaving out functional languages which share python's readability, if not surpass it, while remaining much more expressive. that's f# and ocaml. f#, in my opinion, is superior in everyway to python and subsumes python's abilities of readability, easiness, oop, and scripting, while greatly raising the ceiling of possibility. it's criminally underused, especially in areas where python has been chosen. and i disagree lisp is harder to get into. racket is just as easy to learn as python, if not easier, due to its regularity. the how to code / systematic program design course on edX and the book how to design programs showcases this.

sametmax 8y ago
I heard good things about F# and I did like C#, so I wanted to give an honest look at your arguments. The first thing I checked is your very vocal assurance that F# is a better scripting language than Python. That seemed very weird to me, after all it's Python strong point. Since I script a lot, I looked for the most popular F# lib to parse script arguments. Argu seems the winner, according to http://fsharpworks.com/survey.html http://fsharpworks.com/survey.html. Their tutorial is pretty good (https://fsprojects.github.io/Argu/tutorial.html https://fsprojects.github.io/Argu/tutorial.html), and here is their hello world. 24 lines of, packing a dense symbology and using a lot of the specific language features: open Argu type CLIArguments = | Working_Directory of path:string | Listener of host:string * port:int | Data of base64:byte[] | Port of tcp_port:int | Log_Level of level:int | Detach with interface IArgParserTemplate with member s.Usage = match s with | Working_Directory _ -> "specify a working directory." | Listener _ -> "specify a listener (hostname : port)." | Data _ -> "binary data in base64 encoding." | Port _ -> "specify a primary port." | Log_Level _ -> "set the log level." | Detach _ -> "detach daemon from console." let parser = ArgumentParser.Create<CLIArguments>(programName = "gadget.exe") let results = parser.Parse [| "--detach" ; "--listener" ; "localhost" ; "8080" |] printfn "%A" results.GetAllResults();; The same thing with click, the Python most popular solution, is 11 lines, and it's shaped around almost only regular calls and parameters: import click as cli, base64, urllib.parse as url @cli.command("gadget.exe") @cli.option('--working-directory', help='specify a working directory.', type=cli.File('rb')) @cli.option('--listener', help="specify a listener (hostname : port)", type=url.urlparse) @cli.option('--data', help='binary data in base64 encoding.', type=base64.b64decode) @cli.option('--port', help='"specify a working directory.', type=cli.File('rb')) @cli.option('--log-level', help='set the log level.', type=int) @cli.option('--detach', is_flag=True, help='detach daemon from console') def hello(**kwargs): print(kwargs) hello(["--detach", "--listener", "localhost:8080"]) I have a hard time finding the motivation to look for the truth behind your other arguments after that.
- nikofeyn 8y ago

hellofunk 8y ago

> The experience of Guido, and it's one that I share, is that too much functional tooling drives a style that favors expressive writing at the expense of ease of reading. This is absolutely dead on accurate. As a Clojure developer, using one of the most expressive -- dare I say, artistic -- programming languages ever created, I can say that I am totally in the zone writing code which is elegant and terse and really packs a punch, does clever things.... and then just a few days later, it is very hard for my own brain to parse my own code and figure out what it does. For each line of code you write once, it will be read dozens of times by you or others. Code is for reading. Languages that get this right make things a lot easier for everyone.

roman_g 8y ago
What other languages do you think "made it right" ?

marcosdumay 8y ago

Map, filter and a lot of the itertools contents lose most of their possible power if you let easy lambdas and function composition out. The only dogmatic position here is the Python one, that based on opinion alone, and is leaving a lot of good structures out for no gain at all.

ernst_klim 8y ago

>It's not by chance that LISP and Haskell It's only because Python is familiar and Haskell is not. Objectively both Haskell and Lisp are dramatically more simple to comprehend than python.