This may be of interest if you find the idea of a live Tcl environment interesting: https://news.ycombinator.com/item?id=22852484

VB could be a little weird in that respect. This screenshot of 1.0 has a clue about why:

https://winworldpc.com/screenshot/40c3942c-c281-2230-11c3-a4...

The timer control in the toolbar (left column, second from the bottom) is an example of a control you could drag over into the 'form editor', give a location, but was totally invisible at runtime. All it did was provide a hook for timer events.

This pattern turned into something common, at least in early VB. The extension mechanism for the language was defined in terms of VBX custom controls - which were intended to be visual controls that showed up on screen. The model worked well as long as that assumption held true, but VBX was also turned into an ad hoc mechanism for everything else.

The net of this was that you often had a form editor showing a bunch of totally-non-graphical VBX controls that would do things like send mail, interact with a PBX, whatever else.

Rolling back from this mess was a bit part of the impetus for the way OLE/COM 2.0 was designed, specifically OCX controls and IDispatch.

Delphi evolved from a compiler with full access to the underlying Windows API, with a GUI builder and framework layered on top. Drag a control into a form, and it was fairly easy to see the code behind it down to the layer of the Win32 API itself.

In contract, VB started out as a point and click builder for custom Program Manager like tools, and then had MS Basic attached. You could drag a control into a form, but then there was a very clear delineation between the code you could write as a VB developer and the hidden, opaque code provided by VB itself.