[Info-vax] BASIC compiler in the hobbyist distribution

[seasoned_geek]

On Sunday, May 24, 2015 at 10:56:15 PM UTC-5, IanD wrote:
> 
> What, no love for Python? ;-(

No.

> 
> What's wrong with Python as a language?

It quite simply isn't.

> 
> Is it because it's interpreted? Too slow perhaps?  If the later, there's always Julia (once we get unix -> VMS porting more streamlined, then Julia may appear on VMS sometime?)
> 

The more OpenSource is ported to OpenVMS the fewer customers VMS (open or otherwise) will have. This is a historical fact most people seem to choose to ignore. Before OpenSource was ported to OpenVMS it was banned from Black Hat conferences. After OpenSource got ported to OpenVMS, providing the same 8-lane wide security breaches fake operating systems have it was welcomed back with open arms.


> The argument from the Python camp, and I think it's a completely valid one, is that if you functions are spreading over more than a page, then it's perhaps time to look at breaking those functions down further - or so their argument goes. I even heard a hardened C programmer concede to this point!
> 

I used to hear the same conversation during my Poly Forth days. Today when you do a Web search for Poly Forth with DuckDuckGo you find one link which actually relates to the Forth language.

http://www.forth.com/

I went to Dice and did a search for forth. The results claimed some 343 job openings. Most of them had titles of receptionist, some kind of manager which didn't sound like it had anything to do with IT. Then there was this post.

https://www.dice.com/jobs/detail/UX-Designer-CVS-Health-Boston-MA-02108/CVS/272557BR?icid=sr29-1p&q=forth&l=

It lists Forth in the skills requirements but the posting must have been filled in by someone with English as their 3rd or 4th language. Search the post for Forth and you will find
===
Furthermore, we comply with the laws and regulations set forth in the following EEO is the Law Poster: EEO IS THE LAW 
===

Forth is relevant to this conversation because it was actually a real language. There was an interpreted environment where you could prototype lots, then build binary for target. It also subscribed to the "dictionary" development model, which is exactly what you described above. Python isn't a real language, but that doesn't matter. The "dictionary" development model will shove it into oblivion just as happened with Forth. I mean one company I worked at paid hideous amounts of money per development seat (like $10-25K in 1980s dollars) and it was the same at most other companies. There was even a big forth.org group which put out newsletters and followed the standards.

http://www.forth.org/fd/FD-V04N3.pdf

Well, here is the most "current" history

http://www.forth.com/resources/evolution/evolve_3.html

Anyway, the "dictionary" model completely dooms a language, both real languages and fake ones. It leads to a language standard with a tiny subset of "words", something that can fit on a card in a pocket, and shops with customized dictionaries that make 'War & Peace' look like a weekend sales flyer. What you end up with is that situation language evolution geeks speak of, where hundreds of languages on different continents which seemingly have absolutely nothing in common all descended from Latin. All of the languages are based on Latin, but nobody can communicate.

Both C and C++ were in danger of this fate when they got wide scale use. The standards bodies, recognizing the fate of forth and other languages, moved aggressively fleshing out string.h creating STL, etc. These additions lessoned the chances of a C/C++ programmer being trapped in a single shop which had morphed its own language.

Even though COBOL is not a "dictionary" language, it suffered some of the problem. One of COBOL's greatest strengths was and still is the copylib. This feature allows COBOL shops to churn out new programs with blinding speed. It is also the language's strongest poison. Shops which have 20+ years of copylib development have refactored most of their code base to the point a COBOL programmer cannot just step in and get up to speed. It takes a long time to learn the hundreds of core and thousands of specialty copylibs.



> As an interpreted language I think it's great for what most folk use it for, as a glue language to be flexible interface between various disparate applications and/or systems
> 
> As a language to build enterprise wide applications, then yes, it's not the best hammer to hit that problem with but who writes these things now days? It's the likes of Oracle and the big end of town that has sown up that domain
> 

In truth you have these two things backwards. Oracle, from the client sites I've heard from, has bought a lot of disparate products and attempted to slap them together with things like Python. I know of one company throwing them out lock stock and two smoking barrels not because they "got a better deal" but because all of this supposedly integrated stuff didn't work. After years of lost orders and outages they are taking the thing to the woods and putting two behind the ear.

Put your feelers out. You will find most of "the big dogs" which purchased and supposedly integrated a bunch of products into a single package, didn't quite do it. Things like Python were used to try and glue ill-fitting pieces together and the resulting hodge-podge is worse than the 30+ year old COBOL or BASIC system they are trying to replace.



> It's a very productive language in that with a small amount of code you can perform a lot of work and have a lot of functionality and be easily understandable for maintenance when compared to the likes or Perl which allows you as a language to be terse to the point of painfulness, Pythons design steers you away from this

See above.

> 
> I'd love to see DCL eventually replaced with Python, but I'm sure there would be some folk who would burn me at the stake for such a comment. DCL's beauty is it's ease of understanding / readability but it is too crippled as a 'real language' IMO to take VMS forward on it's future journey and Python fits the bill as a possible replacement partly because of it's ease of reading, enormous libraries and the fact that it has a lot of love beyond VMS (i.e makes it slightly easier to get people outside of VMS interested or at least looking)

I volunteer to bring the zip ties, pile of hedge posts, 30 gallon of used oil and 2 lighters in case one lighter has issues. That fire will be hot.

OpenVMS needs to be purged, yes, purged of every piece of OpenSource. These are where the massive security breaches happen. ShellShock was just one of a never ending string.

The BASIC interpreter was useful for several reasons. It allowed one to prototype things quite nicely then run it through an actual compiler for a real production speed solution. At least that was how I used it on the VAX.

During my PDP days, the interpreter was all there was (for a while). It allowed quite a bit of security though since we could have menu programs which chained to various line numbers in other programs. Anyone who tried to run such programs from the command line or whatever, without chaining to one of the line numbers which actually did something just saw a program which exited without actually doing anything.

I don't remember "how" we did it. Perhaps it was during the BASIC/PLUS-II era, but, somehow we could distribute applications clients could load and run from the command line without them being able to see the source code. All of the chaining still worked. I don't remember if it was fully compiled or p-compiled or what. Those brain cells were sacrificed years ago.

Yes, I would like to see the BASIC interpreter added back into the product. It was nice. Whenever you had a tricky piece of code to work on which was part of a much larger application, you could open up the interpreter and kick around 50 to a few hundred lines of code until the thing worked. THEN you put it in your real module.

DCL needs to remain DCL.

If they, whoever 'they' are, wish to add another shell language, they need to roll from scratch based on the current ANSI standard a REXX interpreter + compiler. VMS needs to once again target the mainframe customers instead of trying to swim in the bottom of the sewer with the x86 crowd.