Exodus mv basic/database clone
Steve Bush
Exodus allows application level programmers to mentally program in
pick basic while using an industry standard compiler and database thus
providing a final escape from proprietary tools. It is implemented as
a C++ library and utilises postgres as a datastore. An important part
of Exodus is the provision of simple development tools that eliminate
the need for application programmers to have any sophisticated
understanding of C++. Dictionaries and sort/select/list are supported.
Exodus currently runs on Linux and Windows and should be portable
almost anywhere.
Tony Gravagno
business case to use ... yet. Looks great Steve - congrats.
I think this has already earned a place in the MV tree.
T
ri...@designbais.com
> I release an MIT licenced clone of MV basic/database athttp://devwiki.neosys.com.
Wow, This sounds like jBASE.
Steve Bush
Only that there is a C/C++ compiler involved. Exodus ditches JBase's
PICK BASIC -> C conversion and you write your code directly in C++ so
we are much closer to the metal than Jbase. This opens up a LOT of
directions for both application and systems programmers.
Unlike JBase, all Exodus data is implicitly visible via SQL.
It took people a while to realise that Pick wasnt an operating system.
It took me a while to realise that it isnt even a language and it isnt
even a database. It is just a library that encapsulates a way of
thinking and can be reimplemented in a chameleon-like language like C+
+ and an extensible database like Postgres.
C++ is on a roll these days. eg QT being licenced LGPL including it's
cross platform IDE. C++0X and Boost libraries coming along nicely.
Postgres is also on a roll since MYSQL got bought first by Sun then
Sun by Oracle.
Chandru Murthi
news:c4b75c59-a9c0-4b5d...@o18g2000yqi.googlegroups.com...
On Jun 6, 11:57 pm, r...@designbais.com wrote:
> On Jun 6, 12:12 pm, Steve Bush <neosys....@gmail.com> wrote:
>
>It took people a while to realise that Pick wasnt an operating system.
>It took me a while to realise that it isnt even a language and it isnt
>even a database. It is just a library that encapsulates a way of
>thinking and can be reimplemented in a chameleon-like language like C+
>+ and an extensible database like Postgres.
That sounds quite computer-science-ese to me. In the original
implementation, Pick was indeed an operating system at least in the normal
usage of the term which implies it is controlling the machine. Whether it
was an *adequate* operating system can be subject to debate.
Your comment about "C++ [being] much closer to the metal than Jbase" is
illuminating. I would argue that the application programmer (as opposed to
the *systems* programmer (like me ;) ) ) *should* be isolated from the
underlying structures, so programming in C++ as opposed to Pick BASIC is a
giant step in the wrong direction. If there is functionality unavailable in
PB, then a shortlist of libraries which provide lower-level functionality
should be provided by the systems people, not created ad hoc by the
applications people (you can see why I believe in big government.)
In my current work, I am in charge of the RAD web system. I rarely get
people telling me what is missing in the tool; since they are
well-enough-versed in javascript (or other languages) they go ahead and find
a way around the roadblock. Understandable, maybe but it would be better if
the mods were incorporated at the tool level. Give 'em C++ and I'd be out of
a job (and, maybe, the application would eventually fall apart as a result
of all those low-level code snippets, or so I'd like to think.)
Chandru
Steve Bush
wrote:
> "Steve Bush" <neosys....@gmail.com> wrote in message
"Closer to the metal" doesnt mean what you think. Exodus is
specifically designed to RETAIN the ability to program in high level
Pick concepts. Pick programmers will feel right at home after they
learn things like THEN and END are now { and } respectively. Most
people are generally comfortable with C style syntax now due to the
ubiquity of javascript.
Exodus works at two levels. One is the traditional high-level pick
application programmer level and the second is that it also allows
systems programming since Exodus programs can be natively LINKED to
operating system and other libraries.
What people frequently dont understand about C++ is that it is a multi-
level language allowing both application programmers and systems
programmers to work together seamlessly with a controlled division in
the way you like it. No Pick system before Exodus has ever offered
this so we just dont know where Exodus will take us. It is a game
changing development.
Actually systems programming wasnt the primary objective of Exodus. In
my own business we will be using Exodus at the application programming
level and we are not particularly interested in the systems
programming side that it opens up. Personally I used to despise C++
until I finally understood how you can make it into almost whatever
you want it to be.
If you wish to lock application level programmers (away from the metal
so to speak) then you can simply disallow any #includes (except
#include "exodus.h") then the application programmers will be unable
to program in C++ as you are possibly thinking about it.
Steve Bush
<address.is.in.po...@removethis.com.invalid> wrote:
> Wow, this is another fine tool that I don't have time to learn or a
> business case to use ... yet. Looks great Steve - congrats.
>
> I think this has already earned a place in the MV tree.
>
> T
>
> Steve Bush wrote:
> >Exodus allows application level programmers to mentally program in
> >pick basic while using an industry standard compiler and database thus
> >providing a final escape from proprietary tools. It is implemented as
> >a C++ library and utilises postgres as a datastore. An important part
> >of Exodus is the provision of simple development tools that eliminate
> >the need for application programmers to have any sophisticated
> >understanding of C++. Dictionaries and sort/select/list are supported.
> >Exodus currently runs on Linux and Windows and should be portable
> >almost anywhere.
Thanks :)
ri...@designbais.com
Well this statement is concerning:
"Pick programmers will feel right at home after they
learn things like THEN and END are now { and } respectively."
Many of us now need to develop applications that are cross MV
Platforms. If I had to change all of my THEN/END statements (and you
seem to imply that there are others), it would be prohibitive to even
consider this platform.
Chandru Murthi
about the efficacy of Exodus as a mv tool, and am fully willing to accept
that it works and may be great. Also, pardon f*(INg Outlook as it's in its
mode of refusing to put the > markers on reply,making it hard to read.
Chandru
"Steve Bush" <neosy...@gmail.com> wrote in message
news:e4728caa-5d2e-487f...@k8g2000yqn.googlegroups.com...
Agreed.
>Exodus works at two levels. One is the traditional high-level pick
application programmer level and the second is that it also allows
systems programming since Exodus programs can be natively LINKED to
operating system and other libraries.
>What people frequently dont understand about C++ is that it is a multi-
level language allowing both application programmers and systems
programmers to work together seamlessly with a controlled division in
the way you like it. No Pick system before Exodus has ever offered
this so we just dont know where Exodus will take us. It is a game
changing development.
Here's where I have a problem. C (which I am most familiar with) is a bear
of a language to program applications in, and yet of course there are
probably millions of applcations coded in C. Same goes for C++. But a
language cannot be both a good/easy/natural SYSTEMS language as well as an
APPLICATIONS language; (that's the problem with javascript also, neat as it
is). The requirements are different, the skill levels of the programmers are
different (and I mean skill as related to result, mind-set maybe, not actual
programming ability) and the need of isolation/exposure to low-level
functionality is different.
So imo C/C++ is never a good applications language.
Steve Bush
Point taken. Exodus is about escaping MV platforms into a more
mainstream platform and moving to a mainstream syntax is part and
parcel of that. It is of no use to people who wish to remain where
they are.
Steve Bush
wrote:
<snipe>
> >Exodus works at two levels. One is the traditional high-level pick
<snipe>
> Here's where I have a problem. C (which I am most familiar with) is a bear
> of a language to program applications in, and yet of course there are
> probably millions of applcations coded in C. Same goes for C++. But a
> language cannot be both a good/easy/natural SYSTEMS language as well as an
> APPLICATIONS language; (that's the problem with javascript also, neat as it
> is). The requirements are different, the skill levels of the programmers are
> different (and I mean skill as related to result, mind-set maybe, not actual
> programming ability) and the need of isolation/exposure to low-level
> functionality is different.
>
> So imo C/C++ is never a good applications language.
>
Attitudes have changed about C++ over time and it is now not generally
looked on as just a freak language little different from C. Classes
(and operator override) mean that C++ is an utterly different language
from C. The old saw that "C++ is just syntactic sugar" is the same
type of fruitless comment as "you can do anything in assembly that you
can do in high level language X". Likewise the fact that you CAN write
C in C++ doesnt mean that you SHOULD or need to .. it is just there to
be backward compatible. C programmers are a pain in C++ because they
think they know what it is all about but in fact you have to detrain
them first.
A systems programmer can write a complex object in C++ that is used by
an application level programmer in a totally simple way. A lot of C++
design principles is about how to construct objects which are easy for
the object user (programmers) to use.
C _is_ a nightmare to write business applications in. If you use C++
as it is mean to be used ie encapsulating functionality inside objects
then you CAN use it for application development VERY effectively. Also
C/C++ compilers and debuggers have come a long way in the past 10
years.
Mike Preece
Just back from the pub. I think the real reason I so much love the UK
is the community slash local pub. Anyway... we're jamming!
Mike Preece
I've been reading and downloading loads of stuff re: C++ development
over the past few days. It's interesting to think of the Pick
applications I've worked on over the years that could be converted -
particularly in light of the fact that the mini computers they ran on
were less powerful than a smartphone is these days. It seems I've been
a bit slow on the uptake and am only now getting immersed in web-
sites, downloads, PDFs and tutorials about QT and Symbian S60. I'll
report back if I emerge from my investigations with any clear ideas. I
feel sure there's gold in them thar hills.
Kevin Powick
> I've been reading and downloading loads of stuff re: C++ development
> over the past few days. It's interesting to think of the Pick
> applications I've worked on over the years that could be converted
Why? C++ is great for a lot of things, but developing business
information systems with it would not exactly be my first choice.
Much of what you like about Pick BASIC does not apply to C++.
It might be nice for those that know both Pick and C++ to use a "Pick
style" as Steve suggests, but how many C++ people that know nothing of
Pick are going to bother to learn about? By the same token, how many
Pick developers with little to no C++ background are going to go out
an learn C++? It sounds like you might be planning too, but I would
guess you are one of the few.
I think Steve probably has quite an achievement here from a technology
aspect, but what is the business case and who are the adopters really
going to be? It's an open source, hybrid system that does not appear
to be backed by any significant company nor support.
It has a techno "wow" factor to it, but even if I fell in love with
it, I could never sell it, nor would I risk putting any clients on
it. Honestly, I would have given the Java implementation of Pick,
MaVerick, a better chance at capturing the imagination of developers
not yet familiar with Pick type databases.
I suppose this comes off as "dumping" on Steve's announcement. I hope
not because I honestly wish him well. He has certainly done something
way beyond my capabilities. Maybe his vision is just that much
greater than mine as well. I thought YouTube and Twitter were both
stupid (Twitter still is, IMO), but the guys that created YouTube have
certainly done well, and the Twitter squad is probably next.
--
Kevin Powick
Tony Gravagno
Steve Bush
Thanks for your assessment Kevin and I dont take it as dumping.
From the point of view of someone who can stick with existing pick
clones for their applications I agree that the case for using Exodus
may be marginal since, for them, the case to move must be compelling.
However, I humbly submit that you, like many pick people, really need
to totally refresh your knowledge about C++ today. Most people have a
very dated view of C++ ... as did I. In my case I was determined to
move out of the pick clone environment for a whole swath of reasons so
I took a serious look at C++. Naturally like everybody else I wanted
to port all my code base AND keep all of the pick mentality for the
future generation of application level programmers in my company.
Exodus defines and implements a C++ class which makes a variable that
behaved EXACTLY like pick variables. This means that you dont need to
know any traditional C++ to use Exodus. In fact I expect to BAN any
include except #include <exodus.h> in my company.
In the end I discovered that C++ is a stunning environment to program
in especially compared to what most pick people think. Nokia's LGPL
release earlier this year of the cross platform QT library and the QT
Creator cross platform IDE has changed the game forever. Actually I
initially programmed Exodus with the famous boost libraries however I
just converted it all to QT over the last two weeks. Initially I was
nervous about being dependent on QT library but there are just too
many serious applications dependent on QT for it to disappear and
orphan us all. There is a HUGE community of C++ QT programmers of all
types. All these guys love to program in C++ and will be perfectly
happy use some slightly strange library called "Exodus" as long as it
produces the results in database apps ... and the Pick way of thinking
about data will see to that.
Cheers, Steve.
Steve Bush
Yes indeed!
I decided to join the QT bandwagon a couple of weeks ago. Exodus' sole
dependency will be QTCore.lib within a few days.
Of course it still needs a tcp/ip connection to a postgres database so
I dont know how useful it would be on today's smartphones.
Kevin Powick
While your argument is somewhat compelling, just talk to Jim I.
(jBASE) or Martin P. (QM) about how receptive existing Pick people are
to Pick-like products that don't include all the features to which
they have become accustomed.
When jBASE first came out, it was only a compiler and, IIRC, Jim had
no intension of supporting things like Proc or even the query language
(Access, English, jQL, etc). He quickly discovered that without these
things the adoption rate was pretty low. Also, Martin has spent a
lot of time, and continues to do so, making QM compatible with
different flavours of Pick.
Of course both Jim and Martin were/are trying to make money from their
product, so there was motivation to make such concessions. Exodus
being a free product likely means that you will not be required to
deviate from your vision for it.
I agree that it will be much more attractive to those wishing to break
from from Pick-like clones and instead use what most consider industry
standard technologies, but I think you understate just how much
different, and I believe more difficult, it will be for people to
design information systems in Exodus/C++/PostgreSQL vs a Pick/BASIC.
Even if I'm completely wrong (is that even possible?), the community
support of a small (today) open source project would not be enough to
convince many businesses depend upon it.
Having said all of that, I like learning and playing with new things,
so I'll likely give it a test drive some time. I've been a PostgreSQL
fan for a long time and know enough C++ to be dangerous.
--
Kevin Powick
Steve Bush
> Hi Steve,
>
> While your argument is somewhat compelling, just talk to Jim I.
> (jBASE) or Martin P. (QM) about how receptive existing Pick people are
> to Pick-like products that don't include all the features to which
> they have become accustomed.
>
> When jBASE first came out, it was only a compiler and, IIRC, Jim had
> no intension of supporting things like Proc or even the query language
> (Access, English, jQL, etc). He quickly discovered that without these
I have done a complete LIST/SORT replacement in Exodus already. This
is a port of my html SORT/LIST replacement that has been in production
for nearly 10 years. Actually this has been the one of the best tests
of the general capability of Exodus. Sort/Select/Read/Dictionaries/
oconv/iconv/multivalues etc etc. I am missing one very important thing
at this stage which is sortselect/index on multivalues but I am
confident my implementation strategy for that is solid and just a
matter of time.
> things the adoption rate was pretty low. Also, Martin has spent a
> lot of time, and continues to do so, making QM compatible with
> different flavours of Pick.
>
> Of course both Jim and Martin were/are trying to make money from their
> product, so there was motivation to make such concessions. Exodus
> being a free product likely means that you will not be required to
> deviate from your vision for it.
>
Yes, I am not actually counting on pulling Pick people. I have done
this for that classic open source reason ... to scratch an itch.
> I agree that it will be much more attractive to those wishing to break
> from from Pick-like clones and instead use what most consider industry
> standard technologies, but I think you understate just how much
> different, and I believe more difficult, it will be for people to
> design information systems in Exodus/C++/PostgreSQL vs a Pick/BASIC.
>
You dont interact with postgres directly so the general process seems
fundamentally the same to me. Differences exist but are mostly are for
the best IMO.
createfile clients
createfile dict_clients
edit dict_clients client_code ... and enter dictionaries (for non data
fields except simple T joins you must write exodus subroutines)
edit update_clients .... and type in an exodus program
compile update_clients
update_clients
createindex clients country_code
list clients client code client_name by xyz with country_code = "x"
"y"
I think one of the brilliant things about Exodus is that you can
simultaneously read (but not update) all of your pick data via SQL as
a side effect of entering the ordinary pick dictionary records with no
extra work from the programmer. This facility opens up an avenue for
alternative non-pick reporting tools to get at the data. This isnt
actually implemented right now but is just a matter of time since the
"pick select -> sql select" is already implemented in the SORT/LIST
command.
> Even if I'm completely wrong (is that even possible?), the community
> support of a small (today) open source project would not be enough to
> convince many businesses depend upon it.
>
I have done a coldhearted assessment of this issue from the point of
view of my own business interests and come to the conclusion that we
are merely writing applications in ISO C++ and storing our data in
Postgres so there is nothing to be worried about. We have several
large clients who are very relieved to hear that they will soon be
able to tick off "C++" and "PostgreSQL" instead "Other Godforsaken"
on their IT audits.
Sure we are going to be using this "poorly supported" library but by
then it will have been tested sufficiently and is free and open source
and is dependent only on QT and postgres both of which must surely
have a minimum horizon of 10 years. In the event the library needs
rebuilding sometime, finding people who can build a c++ library from
source on Linux and Windows isnt exactly hard nowadays.
The deciding factor in the end will be how bullet proof I can make
Exodus over the coming few months and I am confident that I can. I
have done a massive series of regression tests on the core math/string/
extract/insert/delete/replace/remove already. I could do with other
people providing alternative perspective though.
> Having said all of that, I like learning and playing with new things,
> so I'll likely give it a test drive some time. I've been a PostgreSQL
> fan for a long time and know enough C++ to be dangerous.
>
I look forward to it!
> --
> Kevin Powick
