The Future of Programming Languages and Web browsers
JC
authors of LibertyBasic) and my immediate
thought was that this product demonstrates how programming for the web
browser environment should be handled.
Although RUNBASIC is relatively embryonic (and doesn't run on
OpenVMS), I would love to see HP develop this
concept for its own industrial strength BASIC language on OpenVMS. I
drool at the thought of developing web
applications without having to give up the benefits of synchronous
connection states and procedural constructs.
It would also be very nice having direct access to a quality data
management resource like RMS.
I would be interested to hear what seasoned OpenVMS programmers make
of this concept.
John Cookson
John Reagan
"JC" <theco...@gmail.com> wrote in message
news:6ddf589c-5296-404f...@m26g2000yqb.googlegroups.com...
Which "concept" are you talking about? Yet another programming language
with embedded builtins for screen and or web drawing? Automatic HTML
generation? Built-in XML parser? Nothing new here. Other than the scare
tactic about adding modules to Apache, etc.
Plus from a language point of view, BASIC? Really?!?!?
John
JC
(stateless) programming. I don't see much out there which fits the
synchronous bill although I hear that Microsoft Silverlight uses a
synchronous
model on the client side, whereas RUNBASIC is synchronous on the
server side.
As an ERP application developer schooled in character based
applications
(Which work very well but don't look very pretty), I am well aware
that
end customers are demanding "pretty" instead of good. This preference
even
extends to a growing customer rejection of GUI based rich client
technology
in favour of browser based applications. Such developments may not be
either
wise or sensible, however they do reflect current customer preference
trends,
particularly in the small to medium sized business marketplace.
I am intrigued by your comment ending in "BASIC? Really?!?!?"
Please explain this. I'm not looking to get into a "programming
language" war
of words because we all have our reasons for preferring "A" over "B",
but I would be interested in understanding your apparent disdain for
BASIC.
I can see from some of your previous postings on this forum that you
are a
very accomplished current or ex- DEC/COMPAQ/HP software engineer. For
that
reason I would really be interested in your views.
I have been using what is currently referred to as HP Basic for the
last
fifteen years and have found it to be superb for ERP system
development
and maintenance. In a similar vein, I long ago became enamoured with
the
reliability of OpenVMS and its brilliantly fast and robust RMS data
management
facilities. It also doesn't hurt being able to avoid Malware
infestations
which plague the ever popular Windows environment.
John, thank you for your comments.
John Cookson
On Nov 18, 2:48 pm, "John Reagan" <johnrrea...@earthlink.net> wrote:
> "JC" <thecook...@gmail.com> wrote in message
Arne Vajhøj
It looks like a toy to me.
The fat client model for web app is not unique.
Frameworks like Wicket and GWT do that.
Even ASP.NET Web Forms and JSF partly does that.
Combined with an absolutely horrible way of styling with CSS,
then I can not see much future for a product like this.
Arne
Jeffrey H. Coffield
JC wrote:
>
> I would be interested to hear what seasoned OpenVMS programmers make
> of this concept.
>
> John Cookson
Take a look at www.KeepMeUpToDate.net for a web site that is JQuery on
the client side and OpenVMS Basic on the server side (including the
actual server). After actually programming web applications in JSF, VWP,
IceFaces, etc., and getting paid to slog thru Hibernate and JPA, this is
my preference.
Jeff Coffield
www.digitalsynergyinc.com
www.keepmeuptodate.net
Richard Maher
"JC" <theco...@gmail.com> wrote in message
news:6ddf589c-5296-404f...@m26g2000yqb.googlegroups.com...
Personally, and as someone who's been coding on VMS for over 25 years, I
love Javascript! (No, not any of the the bullshit JQuery, Scriptaculous,
Dojo, Prototype,YUI, Floundering etc libraries, just "Javascript") Then, I
also have no problem with MXML for all the good stuff that Flex-Charting
brings, and XAML didn't look that difficult. (In combo with FABridge and
HTML Bridge respectively.)
In addition to that: -
If you'd like a single, authorized, stateful, and context-rich network
connection (TCP/IP and/or DECnet) to your VMS hosted 3GLs, databases, and
business logic then you're in luck!
If Single-Sign-On across any number of concurrently active tabs and pages in
a browser instance also tickles your fancy, then it's all good!
If you hanker to control server-affinity with message-level granularity, and
be able to achieve parallelism by returning result sets to the client, *as
they are produced*, on a binary row-by-row basis (rather than mamoth
bollocks all-or-nothing XML) then it's all gravy!
If you long for the complexities of User Authentication, Network
Communication, and Server Threading & Load-Balancing to be handled
transparently so that you can concentrate soley on the business
requirements, then you've come to the right place!
If you think Application Server development should be no more difficult than
creating a Shareable Image containing the 6 User Action Routines that Tier3
will execute on your behalf during a server process' lifecyle then prepare
to be amazed!
If you're happy with your existing, tried & tested, VMS development
environment and want all of the above Web functionality without *ANY* of the
following (Apache[2], WASD, OSU, JAVA, WSIT, Bridgeworks, gSOAP, DCE/RPC,
ONC/RPC, ODBC, OCI, CGI, Perl, Python, Ruby, NetBeans, ACMS[xp])and if you
and blind-freddy can see the obvious architectural, functional, and
performance limitations of HTTP and also scoff at the joke that is HTML5's
WebSockets then you're in heaven!
And this is all you have to do to get there: -
t3Client = new Tier3Client("Demo",
"http://192.168.1.159/Applets/",
2048, 1022, "ISO-8859-1", "N",
Tier3Client.GUIAWT,
null,Tier3Client.ALL);
if (t3Client == null || t3Client == undefined)
throw new Error("Could not activate Tier3 Client");
empSuggest = new Tier3Suggest(lastName, 600, "myLOV", 5,
empFetch, empSelect);
deptSuggest = new Tier3Suggest(selectRef, null, "deptLOV", 4,
deptFetch, empSelect);
t3Client.appendConsoleMsg("Employee_Lookup successfully loaded");
Anyway much, much, more when I can find a net-facing server to host our
examples. (And I've pollished the examples, written a little Java logger
class 'cos both log4j and java.util.logging.logger are bloated and crap for
Applets, and finally built new kits.) Christmas is looking good!
>
> John Cookson
Cheers Richard Maher
Richard Maher
"JC" <theco...@gmail.com> wrote in message
news:9fb84ef0-8f6c-474d...@m33g2000vbi.googlegroups.com...
> The major concept here is synchronous programming versus Asynchronous
Then why not just set the Async flag in Ajax to "false"?
Actually, I've spent quite a bit of time coming up with an Asynchronous i/o
client example for Tier3. Some of you may recall that I'd previously used
the Socket.setSoTimeout() method to trap tardy reads and provide
quasi-aynchronous functionality. While I believe this can still be a valid
strategy, the new client provides the following SEND method: -
t3Client.send(msg, callback, async, [args...]);
If you have specified "false" for the "asynch" parameter the the Tier3Client
Applet will *not* return (and your Javascript EDT will hang/stall) until
your "callback" routine has called "this.rendezvous();". Here's a snippet
from the upcoming Tier3Client Employee_lookup.html example (empDetails is
the callback): -
function empDetails(employeeHTML)
{
recType = employeeHTML.substr(0,2);
this.rendezvous(); //*** the SEND call can now return
switch (recType)
{
case "00" :
alert(inRow.substr(2));
break;
case "11":
empDiv.innerHTML = employeeHTML.substr(2);
break;
case "99":
empDiv.innerHTML = empEOF;
break;
default:
throw new Error("Unknown record returned from Employee Lookup");
}
}
Note that on the callbacks for the Tier3Suggest functionality, the SENDs are
completely asynchronous and the List-of-Values (or result-set) pops up or
hides as needed. (You'ss see the closure on the "vintage" variable allows
the callback to discover if it's been superseded by subsequent keystrokes.
As I said "I love Javascript".)
It's all awfully clever.
> I hear that Microsoft Silverlight uses a synchronous
> model on the client side,
The first version of SilverLight MS only support Ajax and then only MS-Ajax.
Thankfully Silverlight, Like Flex, and Java before them now also support
Sockets.
> John Cookson
Regards Richard Maher
Neil Rieck
Back in the day, all VMS application developers did one of several
things.
1) call OpenVMS terminal driver software (which only supported DEC
devices by default)
2) write their own terminal driver software
3) write software with embedded escape sequences
Today, browsers are replacing terminals and interfacing traditional
languages with web servers is all custom (I have done it with OpenVMS-
BASIC and OpenVMS-C). I'm not sure whether RunBASIC implements CGI
natively or from a callable library, but I have always wished there
were HP-provided callable libraries from available for so-called DEC
languages. Anyway, languages like these are a step in the right
direction because they don't tie you to something like Visual
Studio .NET (a horrible toolset)
NSR
John Reagan
>I am intrigued by your comment ending in "BASIC? Really?!?!?"
>Please explain this. I'm not looking to get into a "programming
>language" war
>of words because we all have our reasons for preferring "A" over "B",
>but I would be interested in understanding your apparent disdain for
>BASIC.
>I can see from some of your previous postings on this forum that you
>are a
>very accomplished current or ex- DEC/COMPAQ/HP software engineer. For
>that reason I would really be interested in your views.
I've never been a BASIC fan. Not enough typing for me, no pointers, not
enough control over data structure layout, etc. With all the better
languages around, I just amazed folks are still trying to bolt stuff onto
the side of BASIC. Whatever floats your boat.
John
JC
Some of this dialogue took me by surprise, in
particular the comments made by Jeffrey H. Coffield
and Richard Maher who both raise angles worthy of
further investigation even though I will need to gain
substantially in comprehension to follow up on these
technologies. These routes may (or may not) be more
complex to implement than I would imagine.
I can relate closely to Neil Rieck's views and I think
he makes some good points coming from a background
similar to my own.
I remain unconvinced that any of today's myriad of
modern "moving target" application development frameworks
do it right, nor do they appear to have sufficient prospective
longevity. This makes it difficult to commit any significant time
investment on them.
Thanks
John Cookson
Jeffrey H. Coffield
JC wrote:
> Thanks to everyone for the insights and comments.
>
> Some of this dialogue took me by surprise, in
> particular the comments made by Jeffrey H. Coffield
> and Richard Maher who both raise angles worthy of
> further investigation even though I will need to gain
> substantially in comprehension to follow up on these
> technologies. These routes may (or may not) be more
> complex to implement than I would imagine.
>
> I can relate closely to Neil Rieck's views and I think
> he makes some good points coming from a background
> similar to my own.
>
> I remain unconvinced that any of today's myriad of
> modern "moving target" application development frameworks
> do it right, nor do they appear to have sufficient prospective
> longevity. This makes it difficult to commit any significant time
> investment on them.
>
> Thanks
>
> John Cookson
>
I totally agree with your "moving target" comment. If you would like to
look at code samples of how we implemented our latest web site please
contact me at (949) 650-0526 or send me an e-mail. (I added your e-mail
address to my spam filters to let yours through.
Jeff Coffield
www.digitalsynergyinc.com
www.keepmeuptodate.net
Tore Sinding Bekkedal
> >I am intrigued by your comment ending in "BASIC? Really?!?!?"
>
I have to disagree with you there. To the contrary, I've found that
writing even the most trivial of programs in BASIC involve far too
_much_ typing.
-Tore :)
Neil Rieck
More than 25 years ago, someone at my employer's company made a
decision that programs written by technical people would be written in
VAX-BASIC. I thought this was a big mistake and wanted to use COBOL or
Pascal. Since then, we've progressed to Alpha-BASIC and HP-C but I
still find myself working in an oppressive environment (but can't
complain too much because I'm still working)
Okay so I've had to roll my own CGI routines in order to allow Apache
to call my Alpha-BASIC programs directly. No big deal but a finished
callable library from HP might allow me to sleep a little deeper.
:-)
NSR
JC
PRINT "Hello World"
JohnC
Paul Sture
<7c6911ac-bae1-4a65...@b2g2000yqi.googlegroups.com>,
JC <theco...@gmail.com> wrote:
> On Nov 19, 7:51�pm, Tore Sinding Bekkedal <tore...@gmail.com> wrote:
> > On Nov 19, 3:52�pm, "John Reagan" <johnrrea...@earthlink.net> wrote:
> >
> > > >I am intrigued by your comment ending in "BASIC? �Really?!?!?"
> >
> > > I've never been a BASIC fan. �Not enough typing for me, (...)
> >
> > I have to disagree with you there. To the contrary, I've found that
> > writing even the most trivial of programs in BASIC involve far too
> > _much_ typing.
> >
> > -Tore :)
>
> You mean like the following :-
>
> PRINT "Hello World"
>
I read John Reagan's comment as "Not enough data typing".
--
Paul Sture
JC
My response was related to Tore's cheap shot, not John Reagan's
JohnC
Simon Clubley
Of course, if you want a language with plenty of both kinds of typing
involved, you could try Ada. :-)
Simon.
PS: Just to be clear: I happen to like Ada; it's a nice language.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
Tom Wade
> I've never been a BASIC fan. Not enough typing for me, no pointers, not
> enough control over data structure layout, etc. With all the better
> languages around, I just amazed folks are still trying to bolt stuff onto
> the side of BASIC. Whatever floats your boat.
Wouldn't be my first choice either, but at least it uses standard VMS string descriptors, is
reasonably readable and doesn't suffer from the fetish of case sensitivity, unlike a certain other
popular spawn-of-unix language that must be one of the ugliest things ever unleashed upon the
programming world.
There are far worse things than Basic out there.
Richard B. Gilbert
Of course there are. Don't forget that "BASIC" is an acronym for
Beginners Allpurpose Symbolic Instruction Code. It's the right tool for
some jobs!
BASIC has introduced a good many people to programming. Some stopped
there and some moved on.
Arne Vajhøj
> I remain unconvinced that any of today's myriad of
> modern "moving target" application development frameworks
> do it right, nor do they appear to have sufficient prospective
> longevity. This makes it difficult to commit any significant time
> investment on them.
If you are looking for something for the web that will last for
many many years, then I think you will disappointed. Such a thing
does not exist. And I don't think such a thing will exist for a
foreseeable future. The only thing that is not changing is the
fact that everything is changing all the time.
Arne
Arne Vajhøj
> More than 25 years ago, someone at my employer's company made a
> decision that programs written by technical people would be written in
> VAX-BASIC. I thought this was a big mistake and wanted to use COBOL or
> Pascal. Since then, we've progressed to Alpha-BASIC and HP-C but I
> still find myself working in an oppressive environment (but can't
> complain too much because I'm still working)
>
> Okay so I've had to roll my own CGI routines in order to allow Apache
> to call my Alpha-BASIC programs directly. No big deal but a finished
> callable library from HP might allow me to sleep a little deeper.
CGI is a bit old/inefficient.
You could write an Apache module.
Arne
Arne Vajhøj
Basic's problem is not so much the language but more the
"Mort" label.
Arne
Neil Rieck
wrote:
> Tom Wade wrote:
>
> Of course there are. Don't forget that "BASIC" is an acronym for
> Beginners Allpurpose Symbolic Instruction Code. It's the right tool for
> some jobs!
>
> BASIC has introduced a good many people to programming. Some stopped
> there and some moved on.
I, too, am not a big fan of BASIC but DEC-BASIC (or whatever they call
it today) contains features way beyond what a beginner would ever use.
First off, there is no interpreter on any platform higher than VAX.
Built-in support for RMS (sequential, relative and index) was an
unexpected surprise. There is no requirement for line numbers and an
option statement will require you declare all your variables (aka no
kid stuff). MAT (matrix) statements are borrowed from FORTRAN and
fixed size (mapped) strings aid in laying out records. I have become
fond of doing file-io routines in block statement like this:
WHEN ERROR IN
get #15, regardless
yada = 0
USE
yada = err
END WHEN
select yada
case 0 ! no error
case 11 ! EOF
something
case 155 ! RNF
something
case else
something
end select
One really cool thing with DEC-BASIC is something you see in every
other so-called DEC language. The ability to include, then call,
system functions.
%include "starlet" %from %library "sys$library:basic$starlet"
%include "$ssdef" %from %library "sys$library:basic$starlet"
%include "$uaidef" %from %library "sys$library:basic$starlet"
Which means you can call sys$qio from within this language.
NSR
Bob Eager
> I, too, am not a big fan of BASIC but DEC-BASIC (or whatever they call
> it today) contains features way beyond what a beginner would ever use.
> First off, there is no interpreter on any platform higher than VAX.
> Built-in support for RMS (sequential, relative and index) was an
> unexpected surprise. There is no requirement for line numbers and an
> option statement will require you declare all your variables (aka no kid
> stuff). MAT (matrix) statements are borrowed from FORTRAN
MAT statements were in the Kemeny and Kurtz BASIC back in 1970....!
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Richard B. Gilbert
> On Sun, 22 Nov 2009 05:45:23 -0800, Neil Rieck wrote:
>
>> I, too, am not a big fan of BASIC but DEC-BASIC (or whatever they call
>> it today) contains features way beyond what a beginner would ever use.
>> First off, there is no interpreter on any platform higher than VAX.
>> Built-in support for RMS (sequential, relative and index) was an
>> unexpected surprise. There is no requirement for line numbers and an
>> option statement will require you declare all your variables (aka no kid
>> stuff). MAT (matrix) statements are borrowed from FORTRAN
>
> MAT statements were in the Kemeny and Kurtz BASIC back in 1970....!
>
Not to mention that standard Fortran did not have, or use, "MAT/MATRIX
statements". It was DIMENSION all the way back to Fortran II.
When I first encountered BASIC some years later, it was DIM IIRC; e.g.
you wrote DIM X(125).
Bob Eager
Same here. K&K BASIC used DIM to declare arrays, and MAT statements to
manipulate them.
A loooong time ago!
glen herrmannsfeldt
(snip)
> I, too, am not a big fan of BASIC but DEC-BASIC (or whatever they call
> it today) contains features way beyond what a beginner would ever use.
> First off, there is no interpreter on any platform higher than VAX.
> Built-in support for RMS (sequential, relative and index) was an
> unexpected surprise. There is no requirement for line numbers and an
> option statement will require you declare all your variables (aka no
> kid stuff). MAT (matrix) statements are borrowed from FORTRAN and
> fixed size (mapped) strings aid in laying out records. I have become
> fond of doing file-io routines in block statement like this:
What do you mean "borrowed from Fortran?"
MAT goes pretty far back, maybe to the beginning of BASIC.
I first used in the HP 2000 BASIC in 1972. Fortran didn't have
matrix operations until Fortran 90. Maybe Fortran borrowed them
from BASIC.
PL/I had array operations from the beginning, but, like many other
language, array operations are element by element. Matrix multiply
and inverse were common library routines, but not part of the
language or standard library until at least Fortran 90. (Maybe later.)
-- glen