Live data from Hacker News

Lisp-stick on a Python

docs.hylang.org

161–170 of 170 posts

Re: Lisp-stick on a Python

#161
post #66

Earlier quoted context omitted.

I haven't used VS in a decade, but you needed to restart your program after changing the code. Also, C++ linkage, while far faster than rust isn't the fastest thing, and compilation can be slow too (particularly with the popularity of header-only libraries).

> I haven't used VS in a decade, but you needed to restart your program after changing the code. Well then you need to learn your tools better. VS has had Edit and Continue since 2005.

i dont think you know the full limitations of hot reload in VS

Re: Lisp-stick on a Python

#162

Earlier quoted context omitted.

You beat me to it. One wonders if this might become a python13 feature, whenever they get around to branching the CPython repository.

I’m contemplating pushing for it in 3.12, but it’s probably more than a year’s worth of work to implement and shepherd the PEP through. So 3.13 is more likely. And I’m not sure it won’t get shot down anyway. It’s a big step for Python.

I'm still not even using Typing, but, in the feature wars, it's an obvious step in the direction of maintaining featuritis parity with c++. /snark

Re: Lisp-stick on a Python

#163
post #136

Earlier quoted context omitted.

> I always wonder how different the history of prog.langs would be if early on one of the many indent/offside rule based 2-D notations had become popular with "boring code" writers in Lisp and not eschewed by "fancy macro writers" in Lisp. That sounds interesting but is hard to search for, have you got an example?

This is the latest for Scheme according to Wikipedia's Offside Rule article [1]: http://srfi.schemers.org/srfi-119/srfi-119.html I have not read this "Wisp" spec lately, but IIRC it has many back references to prior attempts..at least in the Scheme community..not sure about the common-lisp community. EDIT: To elaborate on my `quote do:`, this is a little macro to avoid doing many tedious code repetitions: macro strp(…

That looks pretty good honestly!

As someone who loves both Lisp and Pascal, I really need to revisit Nim.

Re: Lisp-stick on a Python

#164
post #156

Earlier quoted context omitted.

Vouched your comment. I love how it got flagged for pointing out how that guy's been living in a cave for 17 years lol

i think its sad that people are so brave to troll on the internet yet in real life ... :(

What are you referring to? My username is my real name.

Re: Lisp-stick on a Python

#165
post #136

Earlier quoted context omitted.

This is the latest for Scheme according to Wikipedia's Offside Rule article [1]: http://srfi.schemers.org/srfi-119/srfi-119.html I have not read this "Wisp" spec lately, but IIRC it has many back references to prior attempts..at least in the Scheme community..not sure about the common-lisp community. EDIT: To elaborate on my `quote do:`, this is a little macro to avoid doing many tedious code repetitions: macro strp(…

That looks pretty good honestly! As someone who loves both Lisp and Pascal, I really need to revisit Nim.

You sound like you are in just the right demographic to love Nim...The Forum [1] is a good place to get support.

https://forum.nim-lang.org/

Re: Lisp-stick on a Python

#166
post #112
post #61

Earlier quoted context omitted.

Common lisp doesn't require tail call elimination either, fwiw

But every implementation except clisp, ECL and clisp do it reliably.

sbcl doesn't always do it, depending on optimization settings, and clisp does do it when compiling; by "reliably" perhaps you meant "by default"?

Re: Lisp-stick on a Python

#167
post #27

Earlier quoted context omitted.

No, Python does not have tail recursion optimization, because Guido decided that he wanted to preserve stack frames for better tracebacks. The language team may revisit that decision someday. I assume you're referring to an optimization, because one can write tail recursion in any language that supports subroutines.

Thanks, that is what I thought, but didn't trust my memory. Yes, I did mean optimization - without it you can blow through your stack quickly (and the traceback will be long and redundant :)

In those cases, you may wish to use a dynamic programming technique. A bit of caching might be a greater optimization than tail call elimination. The `@functools.lru_cache` tool is very easy to experiment with.

Re: Lisp-stick on a Python

#168
post #27

Earlier quoted context omitted.

No, Python does not have tail recursion optimization, because Guido decided that he wanted to preserve stack frames for better tracebacks. The language team may revisit that decision someday. I assume you're referring to an optimization, because one can write tail recursion in any language that supports subroutines.

Thanks, that is what I thought, but didn't trust my memory. Yes, I did mean optimization - without it you can blow through your stack quickly (and the traceback will be long and redundant :)

> will be long and redundant

They made a highly redundant traceback display much more pleasant a couple years ago, writing "the same thing 1,998 more times ..." or something like that.

Re: Lisp-stick on a Python

#169

Earlier quoted context omitted.

> I haven't used VS in a decade, but you needed to restart your program after changing the code. Well then you need to learn your tools better. VS has had Edit and Continue since 2005.

i dont think you know the full limitations of hot reload in VS

No post body was provided.

Re: Lisp-stick on a Python

#170
post #156

Earlier quoted context omitted.

> I haven't used VS in a decade, but you needed to restart your program after changing the code. Well then you need to learn your tools better. VS has had Edit and Continue since 2005.

Vouched your comment. I love how it got flagged for pointing out how that guy's been living in a cave for 17 years lol

That's fair. In this case the cave is called "embedded development."

I found my old VS CDs and the latest version I own is .NET 2003, so I only missed that feature by a single release. I couldn't truly be a smug lisp weenie without some snide remark about how nice it is that blub developers finally got something not quite as powerful almost 40 years after Lisp could do it, so just consider me to have made such a statement.

Post reply on HN