41–50 of 89 posts
Maybe someone who knows things can tell me this: Can I use it to develop and debug larger existing programs? That is, can I take 10k lines (say) of Python, that are spread across some modules, load them into Jupyter, not get a horrifying mess, and work on my program?
Earlier quoted context omitted.
It seems more embarrassing than entertaining.
I find this comment frustrating, just like many of the Lisp comments. Asserting a condescending statement with zero explanation. These Lisp comments aren't taking the form "oh, Lisp has something like this too, we can learn from it," instead it's, "something like this feature exists in Lisp, therefore these ideas clearly aren't new." For example on the thread about gradual typing, Common Lisp has definitely not had g…
> Common LISP [23] and Dylan [12, 37] include optional type annotations, but the annotations are not used for type checking, they are used to improve performance.
Actually, type annotations in Common Lisp have been mostly used for three different purposes:
* improving performance
(by choosing specialized operations
and/or removing runtime type checks/dispatching)
* improving runtime safety, plus better error messages
(by adding more and more specific runtime type checks)
* improving compile-time safety
(by compile-time warnings of type errors)
https://common-lisp.net/project/cmucl/doc/cmu-user/compiler....
There are at least two forks of CMUCL (SBCL and Scieneer CL), which use this,too.
Thus CMU Common Lisp has optional static typing + a limited form of compile-time type inference/propagation/checks.
Not sure when CMUCL added this, probably in the late 80s/early 90s. It was for example published in 1992 in the paper: 'The Python compiler for CMU Common Lisp', https://www.researchgate.net/publication/221252239_Python_co...
In VB the feature requested here was called Edit and Continue. VB users loved it. The original release of VB.net did not have it, and was the highest priority feature to add back. When we added it back into Visual Studio, C# got it as well because it’s users demanded it. Anders was trying to ensure genetics made it into .net 2.0 and did not want the feature. I know he wrote some critiques that it encourages producing…
Edit and Continue also works in VS C++ and has been a godsend for me when tweaking DSP code. This particular feature has remained unmatched by other IDEs/toolchains for what, 15 years? That's pretty impressive stuff you've worked on. It's certainly not adapted to all domains, but in DSP applications where you're looking at immediate audio/video feedback (in my case, audio synths and effects) it makes a lot of sense t…
Edit and continue has worked in C++ toolchains and editors before VS, and continues to work now :)
Fix and continue support, for example, existed in GDB way back in 2003 (see, e.g., http://www.sourceware.org/ml/gdb/2003-06/msg00500.html) and in forks of gdb well before, which others used for C++ (hence the "implemented again" headline).
The message covers some of the other places this was implemented.
IIRC (it's been a while), HP WDB support for this goes back to the very late 90's.
Now, i'm certainly not going to claim these IDE's were as good as VS, but they definitely had edit and continue for C++. It's definitely a technical accomplishment, but it's not unique.
Earlier quoted context omitted.
It’s useful to realize Edit and Continue is not for professional programmers, and the qualities we’d most want are not appropriate to every problem. The horrible code you inherited as the programmer brought on is because some non-professional domain expert made a ‘hairball of extreme utility’ that unlocked product-market fit on back of a mess of experiments. VB’s persona was ‘Mort’, literally a scientist trying to ge…
> Edit and Continue is not for professional programmers Then I prefer to be called an amateur, as I really like using that feature, instead of loosing my debugging context and starting everything from scratch, some times spending several minutes trying to replicate the issue that landed me there.
Earlier quoted context omitted.
> Edit and Continue is not for professional programmers Then I prefer to be called an amateur, as I really like using that feature, instead of loosing my debugging context and starting everything from scratch, some times spending several minutes trying to replicate the issue that landed me there.
Not sure if I'm reading incorrectly into the tone of your response, but, for context, 'SteveJS was a developer on that feature, as he says elsewhere in the comment tree.
I don't have to "enjoy" doing everything the hard way, just for the sake of being professional.
UI/UX and language features designed for productivity, help everyone, not only newbies.
What I understood from SteveJS's remark, is that although he took part designing that feature, he doesn't share this opinion.
If not, I would be gladly corrected.
After that I may pause execution and examine some variables and work out what is wrong. From there I need to work out what has caused this to go wrong, perhaps a hardware breakpoint and reloading part of the scene will help.
From doing that may be I see what triggers the hardware breakpoint, a for loop not ending correctly or taking too long to end.
With edit and continue it maybe possible to make the fix, trigger the function again and close the bug. Without it may require a compile, link and the 15 minutes of repro steps.
So edit and continue can massively cut down the amount of time required to fix a bug.
It seems really weird it would be described as amateur or not professional. As usual I suspect it is part of the trend of making everything black and white rather than looking at things on a case by case basis.
Sure if some maths needs to be solved to fix a collision bug when the use is drawing a line on the screen, I would work out the maths and make sure the function is right. But if the maths is right or I don't know what is causing the issue, edit and continue is just another tool for fast and efficient debugging.
In my opinion...
Sometimes I look at the bug database, pick up the next highest priority bug, have zero idea what the problem may be, sometimes there isn't any screenshots and the description is worded so poorly it is hard to make sense of. So I follow the repro steps, which perhaps take 15 minutes and trigger the issue. After that I may pause execution and examine some variables and work out what is wrong. From there I need to work…
I think it's useful for fleshing out a bug and could save time if there's another issue downstream, but I wouldn't count it as solved until it has been tested on a fresh run.
Earlier quoted context omitted.
I find this comment frustrating, just like many of the Lisp comments. Asserting a condescending statement with zero explanation. These Lisp comments aren't taking the form "oh, Lisp has something like this too, we can learn from it," instead it's, "something like this feature exists in Lisp, therefore these ideas clearly aren't new." For example on the thread about gradual typing, Common Lisp has definitely not had g…
Siek/Taha in http://scheme2006.cs.uchicago.edu/13-siek.pdf say > Common LISP [23] and Dylan [12, 37] include optional type annotations, but the annotations are not used for type checking, they are used to improve performance. Actually, type annotations in Common Lisp have been mostly used for three different purposes: * improving performance (by choosing specialized operations and/or removing runtime type checks/disp…
I've seen others do similar things (including beginners I was trying to teach), although in languages like C/C++, and I do not think it is a good idea at all. It leads to "tunnel vision" and concentrating on small pieces at a time while ignoring the "big picture" as well as mindless fiddling with code in an attempt to "get it to work", which pretty much leads to worse code quality overall and a decrease in productivi…
It’s useful to realize Edit and Continue is not for professional programmers, and the qualities we’d most want are not appropriate to every problem. The horrible code you inherited as the programmer brought on is because some non-professional domain expert made a ‘hairball of extreme utility’ that unlocked product-market fit on back of a mess of experiments. VB’s persona was ‘Mort’, literally a scientist trying to ge…
I find edit and continue really useful for making something worm with these.
Are these out of the reach of "professional programmers"? Can they only work on systems with fully specified models, with exacting requirements?
Earlier quoted context omitted.
It seems more embarrassing than entertaining.
I find this comment frustrating, just like many of the Lisp comments. Asserting a condescending statement with zero explanation. These Lisp comments aren't taking the form "oh, Lisp has something like this too, we can learn from it," instead it's, "something like this feature exists in Lisp, therefore these ideas clearly aren't new." For example on the thread about gradual typing, Common Lisp has definitely not had g…