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).

Ten years ago, VS already had the "Edit and Continue" feature. But it's not very good compared to what you get in a Lisp environment. It's slow, there are restrictions on where/when it can be used, and it's possible for the edit operation to fail.

No you don’t. Edit and continue in Visual Studio even works with C++ and it worked 20 years ago. It’s improved a lot recently.

He's talking about production systems ... why everyone in this thread thought he was developing locally is beyond me because as you pointed out that has been around for a while.

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

whats your etc.? in common lisp i can pretty much redefine the WHOLE compiled program at runtime. as far as interactivity and debugging is concerned, its not nearly as good as it is in common lisp

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

Your C++ debugger let's you redefine an arbitrary C++ class in a running program and the existing program and data is changed. /s

I don't think you know just how modular a Common Lisp environment is. Sure there is some hot reloading that sometimes works and you can change the value of variables, maybe even jump back and forth in your stack trace. Rarely does it do any of them as well as Common Lisp though, where the only thing that doesn't dynamically update when you change something is struct-instances and macros. Functions, variables/values, classes (including instances) can all change as you want it without restarting anything. When something goes wrong, like errors or exceptions, you can modify some code, restart some where on the stack, ignore it and continue execution, insert dummy value or insert a placeholder function.

Some form of interactivity with the debugger is common in my experience. The level of interactivity you get with Common Lisp is not.

I really think you're missing the point, maybe this is why Lisp eludes so many.

it's not :)

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.

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.

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

> Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?

common lisp can actually be really good performance-wise. its one of the things that made me switch from using python+c/cpp for my numerical work

Yeah, those are nice features for development, but for actual running code those are anti features usually.

> Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?

Why not? CL is very performant. You'd probably be surprised. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

SBCL can get much faster results than what i can see there via use of SIMD procedures. i think in some tests it beat rust on spectral norm calculations

One can read the paper 'Closing the Performance Gap Between Lisp and C' written by one of the authors of the sb-simd package

https://zenodo.org/record/6335627