[HN Gopher] Python for Lisp Programmers (2000)
___________________________________________________________________
Python for Lisp Programmers (2000)
Author : optimalsolver
Score : 66 points
Date : 2021-02-22 09:15 UTC (2 days ago)
(HTM) web link (norvig.com)
(TXT) w3m dump (norvig.com)
| Blikkentrekker wrote:
| > _Interestingly, Lisp has exactly the same philosphy on this
| point: everyone uses emacs to indent their code, so they don 't
| argue over the indentation._
|
| They don't argue more or less than in, say, _C_ , but they argue.
| nojito wrote:
| Switching to F# from python solves just about every drawback that
| is listed.
| aldanor wrote:
| > The two main drawbacks of Python from my point of view are (1)
| there is very little compile-time error analysis and type
| declaration, even less than Lisp, and (2) execution time is much
| slower than Lisp, often by a factor of 10 (sometimes by 100 and
| sometimes by 1).
|
| Both have been improved on - in particular (1), with `typing`
| module, type annotations, mypy and so on. With (2), Python's
| speed has increased somewhat since, but then again, you won't be
| doing large-scale math without numpy, and for non-vectorizeable
| numeric computations you'd probably use something like jit-
| compiled numba or the like.
| samatman wrote:
| I'm not fond of the habit of glossing over the slowness of the
| Python interpreter by pointing out that you can use it as an
| FFI to fast code.
|
| That's great if you're using Python for numerics, and color
| within the lines. But: a general purpose programming language
| is used for general purposes. Even for numerics, composability
| suffers if the language itself is slow, since crossing between
| FFI packages must be done very carefully to prevent paying the
| cost of the interpreter.
|
| The fact is that Common Lisp, Julia, Swift, and LuaJIT (just to
| name a few), are substantially faster than Python, and it's not
| hard to come up with situations where this will matter. Worse,
| you might stumble into such a situation after committing to
| Python.
|
| Python has much to recommend it. But its slowness has been
| mitigated, not addressed, in the years since Norvig wrote this
| article.
| Blikkentrekker wrote:
| The startup time of the _Python_ interpreter in particular
| disqualifies it for many tasks one would otherwise use it
| for.
|
| It disqualifies it for instance for window management scripts
| for which it's latency is too high.
| neolog wrote:
| I use a python window manager, it's great.
| http://docs.qtile.org/en/latest/
| Blikkentrekker wrote:
| If the actual window manager be written in _Python_ , one
| obviously does not face the startup issue.
|
| If one attempt to send E.W.M.H. to the window manager
| using _Python_ scripts, then one is faced with that.
| gjvc wrote:
| E.W.M.H. == https://en.wikipedia.org/wiki/Extended_Window
| _Manager_Hints
| zitterbewegung wrote:
| The big thing that has allowed Python to flourish is the fact
| that it has a good foreign function interface and was easy to
| use to the point that both academics and web developers would
| learn it. It really got a second wind as ML got more and more
| popular. Not many languages can be used to create an ML
| application end to end (but building on the shoulders of Google
| and or other large big tech / ad tech companies).
| Blikkentrekker wrote:
| Everyone claims to be able to explain in hindsight why
| something became popular.
|
| I believe that the overwhelming factor of why something does
| or does not become popular is simply chaotic luck.
|
| In an alternate history where _Python_ was designed exactly
| the same, but a butterfly at Guido 's desk flapped his wings
| slightly differently, _Python_ would have been obscure.
| cutler wrote:
| Agreed. Well put.
| mumblemumble wrote:
| > I believe that the overwhelming factor of why something
| does or does not become popular is simply chaotic luck.
|
| This seems to me a bit like saying, "That color isn't
| cerulean, it's blue." Describing the specific instances of
| serendipity that have led to Python's continuing success
| doesn't imply that it wasn't dumb luck. It's just a way of
| saying, "Here's an interesting bit of dumb luck."
| bachmeier wrote:
| This is technically correct, but it's also true that if a
| group of dedicated Python enthusiasts (led by Travis
| Oliphant) hadn't created a Python ecosystem before they had
| users, we can say with certainty that Python would not have
| taken off in the numerical computing space. In 2005, when I
| was looking for a new language, I really wanted to use
| Python but it was simply not an option.
| jxy wrote:
| Python had their smearing campaign claiming TIOOWTDI against
| Perl's TIMTOWTDI, and dubious claim's of sigils (`@$`) hurt
| readability. But once Python had the ecosystem going, it
| brought back `@`, `{}`, numerous `_`, fanciful `:=`. And, of
| course, there always is more than one way to do it in Python.
|
| Python's "easy to use" is just a lie,
| https://github.com/satwikkansal/wtfpython
|
| The common lisp CFFI module is nothing short of Python's.
|
| But, I know, people hate to put their `(` in front of their
| function names, and people hate to omit `,` between there
| function arguments.
| neolog wrote:
| "Python is easy to use" is a _relative_ statement about its
| priorities. Compare to other languages that have different
| priorities. Python is easier and slower than C++, for
| example.
|
| There are many design errors in Python, of course. But most
| "wtfpython" things don't actually affect people using the
| language -- they're engineered to identify funny compiler
| optimizations and floating-point peculiarities. The real
| problems of a language aren't usually the kind of thing
| demonstrated in a couple-line snippet. Though there are
| exceptions.
| jolux wrote:
| >Python is easier and slower than C++, for example.
|
| Most languages are easier than C++, and many of them are
| faster than Python.
| neolog wrote:
| There are many dimensions that different languages
| prioritize. As you increase the number of dimensions you
| consider important, the number of languages that are
| better than $language on _all_ of your important
| dimensions tends to decrease.
| [deleted]
| bgorman wrote:
| I have recently been learning python after primarily coding in
| Clojure and Ocaml the last 36 months.
|
| It has been a pretty frustrating experience, lots of the tools
| from functional languages are there, however Python as a language
| is extremely inconsistent. All these little quirks take up a
| significant chunk of cognitive overhead. Python also liberally
| add different syntax in places where it doesn't seem to add much
| value (eg lambdas cannot destructure tuples, and don't need to
| use return). Python has really showed me the value of keeping a
| simple syntax, and having value semantics everywhere). Mutation
| just isn't a great way to write code outside of leetcode.
| xapata wrote:
| I'm not sure why they removed the ability to destructure
| sequences in args. It bugs me sometimes as well. There's
| probably a long discussion about the rationale in some PEP and
| an even longer email thread.
| mesaframe wrote:
| They did? Afaik, it's there.
| carapace wrote:
| Yeah, I was so bummed when they did that. I had a whole
| library of functions for a stack-based interpreter that
| destructured the stack in the function sig, and it was sooooo
| coooool... def add((a, (b, stack))):
| return a + b, stack def uncons(((head, tail),
| stack)): return tail, (head, stack)
|
| &c...
| pansa2 wrote:
| > _There 's probably a long discussion about the rationale in
| some PEP_
|
| PEP 3113 -- Removal of Tuple Parameter Unpacking:
|
| https://www.python.org/dev/peps/pep-3113/
| xapata wrote:
| That's a decent argument. It's more typing (in both
| senses!) to use a specific type as the parameter instead of
| unpacking in the signature, but it's just as or more
| readable that way.
| bmitc wrote:
| I fully agree with you and have expressed this sentiment many
| times. I use Racket and F# in my spare time, basically sister
| languages to what you use (!), and I have the same opinions.
| Knowing these other more structured, consistent, and principled
| languages makes Python a frustrating and difficult experience.
| Whenever I program in Python, never by choice, it's an exercise
| in unlearning sanity.
|
| Knowing these other languages and with others like them out
| there (F#, Racket, Clojure, OCaml, Elixir), I have no practical
| or intellectual need for Python.
| Tcepsa wrote:
| My favorite language has been Clojure for a long time, but
| given Python's popularity and widespread use I often wonder
| whether there is just some big underlying principle that
| would cause Python's appeal and superiority become clear, if
| only I could see it. Comments like yours and GP's help
| reassure me that there's not just some fundamental thing
| about Python that I'm missing. (And don't even get me started
| on Python's concurrency situation!)
| pjmlp wrote:
| Most of those libraries are written in C, C++ and Fortran.
|
| You can use them from any language with native FFI bindings
| capability.
| andi999 wrote:
| The appeal is the libraries, like numpy, scipy,matplotlib
| tensorflow, qiskit the quality and the ease to use them.
| Basically python became what TCL dreamt of becoming (ok,
| don't kill me).
| cutler wrote:
| Clojure now has libpython: https://github.com/clj-
| python/libpython-clj.
| andi999 wrote:
| Better late than never. How is ease of use? Does it work
| well?
| cutler wrote:
| Works well. Best of both worlds.
| Scarbutt wrote:
| Python is easy to get started with and has syntax that's
| nice to look at, easy/nice almost always wins over better.
| So now the issue is many have to keep using Python because
| of the ecosystem not because they find the language good.
| cutler wrote:
| The top 3 programming languages - JS, Python & Java - are
| all pretty uninspiring. It's all about history and
| ecosystem unfortunately.
| iLemming wrote:
| > The top 3 programming languages - JS, Python & Java -
| are all pretty uninspiring.
|
| And Clojure beautifully solves many pain points of Java
| and Javascript, and even C#. I haven't tried clj-python
| mentioned, but I hope someday soon, running Clojure code
| interoperable with Python in production becomes a
| reality.
|
| The hosted nature of the language is a brilliant idea.
| Clojure eliminates many small annoyances I hate in other
| languages - syntactical, semantical, and operational.
|
| I wish more programmers have given a heartfelt try to
| Clojure instead of whining that "Lisp is unreadable" and
| "the parentheses are awful".
| neilparikh wrote:
| I feel the same way. If I need performance, I'm going to use
| something like C, C++ or Rust. If I don't care about
| performance, I'm going to use something as high level as
| possible, like Haskell (and probably still end up getting
| performance better than Python, and probably only one order
| of magnitude away from C).
|
| Python seems to be in this weird middle area where it's not
| performant, but it's still more low level[0] than languages
| like Haskell and OCaml. If you don't need performance, you
| should go as high level as practically possible!
|
| [0] - By low level, I mean things like having to manually
| write loops, deal with state, etc. More succinctly: "A
| programming language is low level when its programs require
| attention to the irrelevant."
| konjin wrote:
| Python has been getting worse with time.
|
| I learned it in the 00's in highschool and it was a very nice
| small scripting language that you could just write dumb code
| which worked and you wrote C for where you needed performance.
|
| For some reason people have pushed it everywhere and lost the
| spark it used to have.
| macintux wrote:
| Functions (and I assume lambdas) could destructure tuples in
| Python 2.x. I started my first serious Python project in
| 2.something before discovering it was nearly eol, and learning
| that all of my tuple management was broken under version 3 was
| quite demoralizing.
|
| I find the mutability of values and object orientation of 3rd
| party libraries to be among the most alienating aspects of
| Python, but overall it's too useful for me to ignore, so I live
| with it.
|
| I just don't find layering on functional capabilities to an OO
| language to be nearly as useful as a true FP solution. As you
| said, too much cognitive overhead.
| BalinKing wrote:
| Huh, apparently[0] they removed lambdas' ability to do that
| in Python 3!
|
| [0] https://stackoverflow.com/a/11328422/2391244
| fmakunbound wrote:
| > Macros for metaprogramming ... No macros; write your own
| parsers
|
| Ooof, sounds like a lot of effort. Is anyone doing that in
| Python?
| benhoyt wrote:
| Plenty of people write literal parsers in Python, for things
| like HTML template languages -- however, that's not really
| related to macros.
|
| The most crazy thing I've seen along these lines (but it leads
| to really nice syntax) is PonyORM (https://ponyorm.org/), which
| allows you to write Python generator expressions like this:
| select(c for c in Customer if sum(c.orders.price) > 1000)
|
| And Pony will translate it to SQL like this:
| SELECT "c"."id" FROM "customer" "c" LEFT JOIN
| "order" "order-1" ON "c"."id" = "order-1"."customer"
| GROUP BY "c"."id" HAVING
| coalesce(SUM("order-1"."total_price"), 0) > 1000
|
| But how it does this is pretty funky. Python doesn't actually
| provide the AST for already-compiled code, just the bytecode.
| So Pony decompiles the bytecode back to an AST, and then
| converts the Python AST into SQL. More here (from the PonyORM
| author): https://stackoverflow.com/a/16118756/68707
| jolux wrote:
| Sounds a lot like LINQ in .NET.
___________________________________________________________________
(page generated 2021-02-24 23:01 UTC)