Live data from Hacker News

Lisp-stick on a Python

docs.hylang.org

151–160 of 170 posts

Re: Lisp-stick on a Python

#151
post #87
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).

> you needed to restart your program after changing the code Wow. No. This is a really basic debugging feature that's been around for over a decade. You can also drag-and-drop the instruction pointer to another line, watch and change variables in real time, etc. I swear, every LISP-related thread has someone touting ancient features as if they are somehow new or unique.

[deleted]

Re: Lisp-stick on a Python

#152
post #123

Earlier quoted context omitted.

whats your etc.? in common lisp i can pretty much redefine the WHOLE compiled program at runtime. boasting about redifining variables to someone using lisp is a big LOL moment. as far as interactivity and debugging is concerned, besides smalltalk, its not nearly as good in any other language as it is in common lisp

Very cool, that's definitely not a common feature in every other debugger /s

[deleted]

Re: Lisp-stick on a Python

#153
post #66

Earlier quoted context omitted.

Doesn’t VS do that too though? Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?

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.

Re: Lisp-stick on a Python

#155

Earlier quoted context omitted.

this uses a C++ rendering engine

Here's a browser written in pure Common Lisp: https://closure.common-lisp.dev/ These questions are so silly. Nobody's written a web-browser in Rust, Python, Ruby, Java, Clojure, Haskell, Erlang, Typescript, Javascript, etc. but that hasn't stopped anybody from using them. Just admit you don't want to learn Lisp.

Doesn't support HTML5, CSS3, JS. Non-starter.

Re: Lisp-stick on a Python

#156
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.

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

Re: Lisp-stick on a Python

#157

Earlier quoted context omitted.

this uses a C++ rendering engine

Here's a browser written in pure Common Lisp: https://closure.common-lisp.dev/ These questions are so silly. Nobody's written a web-browser in Rust, Python, Ruby, Java, Clojure, Haskell, Erlang, Typescript, Javascript, etc. but that hasn't stopped anybody from using them. Just admit you don't want to learn Lisp.

I learnt Lisp sometime around 1986 (from library books and later, on the Sinclair QL LOL), I do love it in some ways, but found distribution of final code to be an issue. I don't think it's suitable for all tasks.

Re: Lisp-stick on a Python

#158

Earlier quoted context omitted.

Here's a browser written in pure Common Lisp: https://closure.common-lisp.dev/ These questions are so silly. Nobody's written a web-browser in Rust, Python, Ruby, Java, Clojure, Haskell, Erlang, Typescript, Javascript, etc. but that hasn't stopped anybody from using them. Just admit you don't want to learn Lisp.

I learnt Lisp sometime around 1986 (from library books and later, on the Sinclair QL LOL), I do love it in some ways, but found distribution of final code to be an issue. I don't think it's suitable for all tasks.

> but found distribution of final code to be an issue

in 1986 ?

> don't think it's suitable for all tasks

to this day im yet to see an example of a software engineering problem that lisp is not suitable to solve. if you have such an example ready i would be genuinely curious. otherwise its just a thought from a very common and lazy misunderstanding of what lisp actually is

im talking about computational problems. things that are non-examples include such things as business sense/requirements, availability of programers, availability of ready made libraries/frameworks, or claims of apparent unsuitabilty in large teams

Re: Lisp-stick on a Python

#159
post #123

Earlier quoted context omitted.

whats your etc.? in common lisp i can pretty much redefine the WHOLE compiled program at runtime. boasting about redifining variables to someone using lisp is a big LOL moment. as far as interactivity and debugging is concerned, besides smalltalk, its not nearly as good in any other language as it is in common lisp

Very cool, that's definitely not a common feature in every other debugger /s

it's not :)

Re: Lisp-stick on a Python

#160
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

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