Hacker News Reader

Comment by badsectoracula | Hacker News Reader

I've only played briefly with it some years ago on a Linux installation but one thing that i found neat was that unlike something Visual Basic or Delphi (which were clear inspirations - i think this screenshot[0] with the entire UI makes it a bit more obvious than the windows in the linked site) is that it is a "live" environment (pretty much like tclsh and wish) you are working with (kinda like a Smalltalk, though probably not to the same extent).

(though FWIW classic VB is a sort of in-between because you are editing the actual forms and state you'd see running - which is most likely why you can't edit a form while the program is running and the IDE even "hides" them - but there is an intentional distinction between "running" and "editing")

[0] https://a.fsdn.com/con/app/proj/vtcl/screenshots/49571.jpg

View on HN

>kinda like a Smalltalk

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

> FWIW classic VB is a sort of in-between because you are editing the actual forms and state you'd see running

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 continued in that manner - You could have all kinds of visual controls, including FTP clients, that you'd visually add to a form etc. - but they were also possible to instantiate from code.

Though Delphi's components were always meant to be for both visual and non-visual uses (TControl, from which other visual controls descent, is just a subclass of TComponent).

I didn't use it as much, but my recollection is of Delphi being a much more coherent product than VB ever was. This probably stems naturally from the way the two products came into being.

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.

Yeah though FWIW Delphi was also a much more intimidating product to get into while VB was like a drawing program where you draw a GUI (there is even a color palette!) instead of a picture and then put some bit of logic - the IDE even tried to avoid intimidating you via your own code by only showing a single routine at a time.

This was still often done in later VB. The Internet Transfer Control was often used by VB and VBA programmers to give their applications HTTP and FTP capability.

What VB should have done was have an optional "utility band" or the like on a screen on which to place the invisible widgets.

Reply on news.ycombinator.com