[Info-vax] Development Tooling

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Sun Dec 16 15:48:27 EST 2018


On 2018-12-16 19:03:31 +0000, Dave Froble said:

> On 12/16/2018 11:22 AM, Stephen Hoffman wrote:
>> On 2018-12-15 09:45:26 +0000, Phillip Helbig (undress to reply said:
>> 
>>> ...Many people do...✂️...namely people who write their own
>>> applications.  They need an OS and  a compiler, that's it...
>> 
>> That's true, as far as it goes.  Developers can work with an operating
>> system and just a compiler.  Though developers are a fickle lot.
> 
> Well, yes, we are.
> 
>> With the expectations of frameworks and tool chains, and around one or 
>> more IDEs and increasingly on the scale of Xcode or JetBrains or VS 
>> capabilities, and with expectations around app instrumentation and 
>> build tools and deployment tools, and around security-related 
>> frameworks and encryption, and a variety of other details well beyond 
>> the compilers, these requirements developers increasing have can make 
>> OpenVMS a difficult sale.
> 
> I'm going to propose some things that apparently escape your claims and logic.
> 
> Do you really want a serious developer to be dependent on tools that 
> remove the need of some of the skills to be a serious developer?

Ask yourself what makes a serious developer?  We can go as deep as we 
want in that discussion, down to understanding the frameworks and code 
generation, to understanding hexadecimal, to binary file formats and 
binary patches, to understanding the processor design and the errata, 
to the physics.  This stack of turtles goes all the way down.  As 
developers, we get to abstract these and other details for our 
end-users, and we abstract these and other details for ourselves, and 
we either spend the time and effort necessary for bespoke code or we 
incorporate dependencies.

As for development tools?  I prefer a tool that frees me to focus on 
and to work with the source code more directly and more efficiently.

Dealing with build files and with separate tools and with jumping 
between sessions and tools is disruptive.  Sometimes useful, certainly.

A good IDE allows me to focus on the code, and to not have to deal with 
piles of the busy work.  And with fussy details like renaming symbols 
or refactoring or reformatting source code.  Do I know how to write a 
build script?  Sure.  I'd prefer to avoid doing that, though.

> Ok, typing errors I'll give you.  Probably the largest of the problems 
> I've encountered.
> 
> Consider, if the developer must be precise enough to do without some of 
> the aids, perhaps a better job can be done.  Complacency can lead to 
> errors as much, maybe more, than the lack of aids.

Would you be interested in a tool that made it faster to see and to 
correct source code errors, and faster to find and fix and refactor the 
source code, and that had near-prescient source code completion?  If 
you're used to EDIT/EDT and compile and LINK and RUN/DEBUG, this can 
certainly seem a little fantastic.  But these capabilities are now 
available, and they work.

> Now some may just dismiss this as garbage coming from "elitist Dave", 
> and to an extent they might be correct.  Or maybe not.

I was right there with you, right up until I encountered Xcode.  My 
experience with earlier IDEs was bad.  Some current IDEs are still bad, 
too.

>> Developer expectations have moved on from what OpenVMS offers.  The 
>> classic OpenVMS edit-compile-link-debug development cycle isn't all 
>> that popular, these days.
> 
> Depends on who you ask, right?

Of course.   It'd be interesting, setting up and showing some IDE 
demos.  Because that's what these discussions probably best involve, if 
not an actual installation and some effort to learn a new tool.

Switching tools is no fun, and it's a risk.  Switching editors, for 
that matter.  Switching from EDT to LSEDIT was fairly easy.  Switching 
from LSEDIT to vim was no fun, though I'm continuing to find useful new 
features and capabilities in vim. Learning new tools is a hassle.  
Always has been.  Sometimes the effort pays off, sometimes not.

>> LSEDIT was a good IDE choice in the 1990s, but it's utterly 
>> uncompetitive in recent years.
> 
> Don't know, as I've never used it.  If it's so bad now, perhaps I 
> should try it out?
> 
> :-)

I won't suggest vim or emacs, then.   But in all seriousness, do try 
LSEDIT.  LSEDIT in its EDT keypad mode and particularly with its 
COMPILE/REVIEW command—^F and ^G to navigate the error window—is 
preferable to EDT for development.   Of what's available for software 
development on OpenVMS, LSEDIT is a good choice.


-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list