Hacker News new | past | comments | ask | show | jobs | submit | limmeau's comments login

In page 44 onwards, this describes how to do class-based OOP with assembly language extensions to generate vtable calls. I wonder who ever used that…


This helped to understand how OOP was working under the hood (I was a teen at that time)

This post brings me many memories from Turbo Vision, Borland Graphics Interface, a simple assembly language, the flat memory hack, Turbo Pascal with its super fast compile time...


When I was a teen, I used TA precisely because of oop support :) it was a bit cumberstone compared to higher level languages, but worked quite well for the kind of stuff I needed (mostly display-related and IO libraries)


We used it for the kicks at the Uni. Never got to try that in prod because frankly the next time it came to using assembler it was 15 years later (and on another arch).


OOP hype was peaking in the mid-90's when TASM 5 came out. Probably some manager's idea to capitalise on that.


You can watch Leslie Lamport himself explaining it at https://lamport.azurewebsites.net/video/videos.html . It doesn't cover Pluscal, but goes deep into TLA+.

(BTW count the different shirts).


I can really recommend debugging with command-line gdb (inside a text editor, of course; we're not barbarians). The transcript that lets you look back at the past of your debug session really adds a new dimension to the debug experience that a plain IDE integration just does not offer.

(Time-travelling debuggers are OK, too, I guess)


What do you mean by transcript? I used gdb a while ago and it's mostly similar to a regular terminal application with readline.


By transcript, I mean every command and every response in the debug session. Usually, in the beginning, I do not know yet what I'm looking for, and set breakpoints at points that may be interesting, and when I reach the breakpoints, I look at variables. Later, when I reach the point where things have gone wrong, I can look at variable values now, but also at the result of every previous query. This helps me answer questions like: was this object here already in that queue over there when the previous request came in?

I can also attach the debug session to an issue in order for others or future me to understand what was happening then. In a purely GUI-driven debugger, I can copy&paste a stack trace of the final point, but the history is lost.


I've used scripts + logging in the past:

https://sourceware.org/gdb/onlinedocs/gdb/Logging-Output.htm...

Maybe that is what OP means by a transcript.


Just like I was doing with XEmacs in 1995...

There is so much a modern IDE debugging session is capable of.


What do you mean “inside a text editor”? What’s the workflow that you describe like?


I think it just means inside your editor's terminal, where there's usually some modest integrations like it detecting a source/line reference and either jumping you there or at least making it clickable.

VSCode for sure does this.


I cannot for the life of me get gdb to debug a remote in VS Code. The debugger runs, and breakpoints work and integrate, but the console is dead. '-exec print foo' does nothing.


GUD in Emacs (M-x gdb) is another example of this. You are still interacting with the gdb cli but also get some source code buffer integration.


gud-gdb in Emacs, yes.


Time travel to the UNIX world of early X Windows days.

Now picture XEmacs and Emacs, running gdb as subprocess, with a little pointed finger showing the current line and a stop sign for breakpoints.

The lower buffer shows the usual gdb repl and output.


Time travel to the late 70s and use the lisp machine debugger.

I always felt the drive towards mouse-driven tools in the PARC world (InterLisp/SmallTalk/CedarMesa) was actually a regression because of the loss of history ("how the hell did I get here?")


They also had a proper REPL, and the reason I stay with Java and .NET ecosystems, is because they are the closest we can get back to the Xerox experience, after the UNIX divergence.


Still available with DDD and various plugins to vim/emacs/vscode


Just learn a tool at a time. Ftrace, for example, is a nice tool to trace kernel events. It is not the coolest kid on the block, but simple enough for basic things.


Mermaid has explicit support for diagrams that look UML-ish (never mind the filled triangle arrowheads for inheritance): class, state and sequence diagrams. Graphviz doesn't do that easily.


PlantUML[0], which is built on top of Graphviz, does have support for UML and other services such as Gitlab do support direct embedding of PlantUML (which also means you can embed Graphviz, since PlantUML is an extension of Graphviz).

[0] - https://plantuml.com/object-diagram


Remember when Blackberry succeeded in the market by calling their text-messaging device a "two-way pager" even though, technically, it was a mobile computer with modem and not at all a pager?

Chances are you'll fare best by hiding your earth-shattering new paradigm behind a veneer of familiarity. Then nobody has to know you have deep insights no one else has.


Please elaborate. How did this happen?


If you're at least a bit into home-lab tinkering, you could run NextCloud from a Docker container on your NAS or home server or RPi. For external access limited to your family's devices, you could use Tailscale.

But yes, you could just have Hetzner host it for you for a handful of Euros a month.


There are occasionally projects on hackaday where people replace the firmware of cheap fitness trackers, like https://github.com/curtpw/nRF5x-device-reverse-engineering -- you could start from there.


So what about the other improv principles...

"Is my partner having a good time": Make your partners look good. That is usually a good idea in any team.

"Find the earliest end". That would mean don't ever maintain an old product because there's nothing interesting in it...

"Yes and" principle: you accept the ideas that your fellow players introduced and build on top of them. For example, "Backend moved their data store to a novel distributed document store they read about on Twitter -- Yes, And we'll let the frontend run in a JS-emulated Browser-in-a-Browser!". I see that being applied, but I'm not sure it's good advice.


Analogies work until they don't. They're a tool break down concepts or to help re-frame a way of thinking. When analogies stop being useful, stop using them. With that being said, I feel like there's some nuance being missed.

"Find the earliest end" is about keeping ideas flowing for creativity's sake. There is only so much mileage out of an idea before it becomes stale (exceptions withstanding [skip to about the 1 minute mark])[0]. The earliest end isn't permanent either. Troupes and groups revisit ideas all of the time.

"Yes and..." doesn't mean that every idea needs to run its course at the detriment of the group. It means to explore the idea to see if it leads anywhere fruitful. If it doesn't, bail. The Office[1] showcases this where Michael pretends to have a gun during an improv group. It ruins the flow of everyone else's idea, because his idea has a clear, expected ending. It's OK to see where a fresh-faced dev's idea might take the project. That doesn't mean they have creative control.

[0]: https://www.wnycstudios.org/podcasts/radiolab/segments/16175...

[1]: https://www.youtube.com/watch?v=C6wY9OwqJ2A


I see the "yes and" principle being about customer interaction. You never tell your customer they're wrong, you always agree with them and build on what they told you they wanted.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: