APL in 2020 - Workspace vs Script
Phil Last
of Basic. The first two weeks of my first job were taken up by a self
teaching course in APL after which I was given the choice to stay in
the "Personal Computing" department doing APL or to move to data
processing and do COBOL/PL1. At that early stage a very great
incentive to stay was the brevity of APL and the granularity of its
programs.
Dyalog's object framework requires a class to be defined in a script.
No matter how good your code management tools and their ability to
merge different developers' changes the entire script, rather than a
(typically fairly small) function, has to be saved every time a change
is made. And the necessity to merge is of course far more likely in a
unit of code several hundred lines long rather that a dozen or so when
more than one developer is working on the code.
I would not advocate a return to the use of a workspace as the
repository of code. I assume most developers use some kind of code
database or function file. But the workspace as development
environment, with its separate, manageable functions (in separate
namespaces where they exist), is surely one of the beauties of APL and
one of the joys of developing code in it.
kai
Worse, we loose more than that: No timestaps on a per-function basis,
and no persistent stop vectors either.
I do embrace OO, it has prooved to be very useful, but it comes at a
price...
Bjorn
the program is running.
How you create the workspace and how/if you save the state of the
workspace is another issue.
The same is true of progam development or even in writing a book.
If you start on a book or a script and make it bigger and bigger even
after you start making changing to earlier written lines and pages and
you always have to print out the whole book after changing a line or a
few.
The best option is to collect a reasonably sizable set of tools of
well defined functions in a script.
Keep track of changes in a script and function.
If a function is not changing it can go into a pool with other
functions that are not changing.
Keeping all functions together in a pool where new fresh functions are
put without tracking what is going on is a complete madness.
I have managed many people working together on the same APL product
and it works fine as long as all new input is managed and statistics
kept.
I have had the misfortune too to have to manage APL people who refuse
to work in a normal manner.
They can be highly productive and very intelligent but what comes from
them is highly unpredictable and more or less worthless.
I have managed people writing in other languages as well and the
situation there is exactly the same.
Uncontrollable code is a nuisance at best but more or less harmful or
worthless.
Unfortunately developing using saved APL workspaces without controls
is pretty much worthless and one of APLs worst mistakes.
Jane Sullivan
> I agree wholeheartedly.
>
> Worse, we loose more than that: No timestaps on a per-function basis,
> and no persistent stop vectors either.
You can put a persistent stop into a function like this:
S?<function-name>?1+1??LC
>
> I do embrace OO, it has prooved to be very useful, but it comes at a
> price...
--
Jane
kai
> S?<function-name>?1+1??LC
Are you referring to APL2's special syntax? We talked about Dyalog....
Dick Bowman
Everything has its place, what's key is for people to make rational choices
based on their situation and how they see it developing in future.
0⊃ There can be good reasons for someone choosing to develop "a workspace"
and keep all of their stuff there.
1⊃ Function files also have their place, but we've never had a
globally-accepted solution - every development shop seems to have their
own.
2⊃ Scripts bring one good thing to the party - they make it easier to share
code across different vendor versions (coupled with Unicode - I've been
able to use the same script with APLX and Dyalog). But they're awkward to
maintain (a linear representation of what's really granular), and I can't
see any sense in using NotePad (or a tarted-up equivalent) to tamper with
my code outside of the APL environment.
My experience/opinion is that Dyalog has retreated a little from the
scripts hardline that I see (or saw the last time I looked) in J - 12.1
gives me back some edit-navigation tools that were missing earlier.
So, the question is - what do we want APL code editing/storage to look like
in 2020? An elephant near the room is how important it is for us to be
able to play the corporate "we can manage code versioning" racket?
Because I think there's another larger question lurking behind this.
I don't care for the "if we look like them, they'll like us" argument - is
it really important to be able to use the same code management tools as
other parts of the IT world or is that just the most recent obstacle thrown
because IT-corporates don't like us? I'm a Millwall fan in this regard...
WildHeart
In Dyalog you can do
(1+[]LC)[]STOP'Fnname'
--
Stefano
WildHeart
We pay the price because we seriously lack tools to manage scripts for
us. People have had timestamps for functions in C source files for
more than 30 years now...
In the company I work for, we abolished the workspace more 20 years
ago. All code is in component files. But we're having our grieves with
scripts: the granularity is not fine enough and our tools haven't
really been updated to take care of this issue. What we should do is
write a little parser to cut scripts into atomic chunks (functions,
declarations, code that runs at fix time, comments) and save the bits
as separate entities. This is not a lot of work, but due to the
relative lack of interest to OO extensions in the shop, we haven't
found the resources to do this, yet. Therefore we save scripts as
blobs. A few, small scripts, so far, and we don't have more than one
person messing with the same script at the same time, so no big deal.
So far.
I mean: it's not like we really solved our issues with non-scripted
namespaces either, so...
--
Stefano
kai
No you can't. Not with functions in a class script.
And even if you could, saving the script on file and restoring it
later makes the stop vector disappear - it's not part of the script.
Morten Kromberg
> My experience/opinion is that Dyalog has retreated a little from the
> scripts hardline that I see (or saw the last time I looked) in J - 12.1
> gives me back some edit-navigation tools that were missing earlier.
There is no "script hardline", only a lack of clear requirements /
ideas and (in the past) resources. As a result, the "tool support" is
lagging a bit behind. We're catching up.
> So, the question is - what do we want APL code editing/storage to look like
> in 2020? An elephant near the room is how important it is for us to be
> able to play the corporate "we can manage code versioning" racket?
We *definitely* need a system which allows us to play this game. Apart
from the fact that nobody (with significant quantities of money
invested in applications) will want to play with us if we don't,
relying on in-workspace timestamps has never really worked anyway.
Writing your own source code management system is ... well ... I envy
people who still think they have enough time to spend on that kind of
work, and that they have better ideas about source code management
than the rest of the universe.
> I don't care for the "if we look like them, they'll like us" argument - is
> it really important to be able to use the same code management tools as
> other parts of the IT world or is that just the most recent obstacle thrown
> because IT-corporates don't like us? I'm a Millwall fan in this regard...
IT *REALLY* IS IMPORTANT if we want to attract a new generation of APL
users.
In my opinion, we simply cannot afford to continue to maintain our own
source code management systems. It costs us a lot of work, it makes us
unattractive to new users and to customers with money, and it makes it
hard for us to share tools even within our own community.
I think it is true that we need to do some work on the APL side to
allow us to work with smaller pieces of script than "an entire class".
"The other languages" tend to allow this too (one text file only
defines part of a class). Our tool support is simply incomplete. There
is no reason why we cannot build an interface to external source code
management systems that we all can share, and that maintain "our way
of life".
We are happy to take input on how our users think the script support
should be enhanced. But the general concept "is here to stay".
Morten Kromberg
> I would not advocate a return to the use of a workspace as the
> repository of code. I assume most developers use some kind of code
> database or function file. But the workspace as development
> environment, with its separate, manageable functions (in separate
> namespaces where they exist), is surely one of the beauties of APL and
> one of the joys of developing code in it.
The INTENTION is to allow this mode of operation to continue, only
that the source code is kept in text files which can be managed by
external source code management systems. The "SALT" tool is intended
to allow you to work in the workspace "as usual", taking care to put
the source for modified functions back into the external scripts each
time you edit a function.
There are still some rough edges, which we are keen to find solutions
for. Can you describe the scenarios where SALT does not work for you
(assuming you have tried using it)?
Phil Last
As a matter of fact I haven't tried because I'm using what you
disparage above: our own code management system. Rather than using two
tools: one (SALT) to monitor workspace changes and to maintain a
private codebase of large text files while a separate CMS
(Subversion?) manages the repository and code sharing; we use a single
CMS (acre) that does both tasks and the granularity is at whatever
level we choose to work: individual functions and operators in
namespaces or classes or scripted namespaces. The choice is usually at
the individual function & operator level with skeletal class scripts
including ordinary namespaces. This gives us an average line count of
20 for all name classes making changes of the same item by multiple
developers and the consequent need for merging very infrequent.
Dick Bowman
> On Sep 22, 9:27 am, Dick Bowman <d...@dickbowman.org.uk> wrote:
>>[... deleted ...] An elephant near the room is how important it is for us to be
>> able to play the corporate "we can manage code versioning" racket?
>
> We *definitely* need a system which allows us to play this game. [... deleted ...]
I'm curious - how do corporates manage things like Excel workbooks?
Phil Last
I envy people who still think they have enough time to spend on that
kind of work, and that they have better ideas about source code
management than the rest of the universe.
Not at all. There is controversy between the way different CMSs treat
aspects of change conflict but most of them agree on most things.
As do we.
The difference is that APL source code is not the same as in the rest
of the universe. Most readers of this list would probably agree that
the unit of granularity for change history should be the function
rather than the group, package, module, namespace, class, what you
will.
If we want to store APL objects as separate entities rather than
trying to squeeze them together into multifarious conglomerates then
either we must reflect the entire workspace structure in possibly tens
of thousands of external files in folders and use an external CMS on
those files or use the direct route of putting the code into an RDB
and controlling the latter using the same concepts as would any other
CMS.
WildHeart
I get the feeling we're not talking abou the same thing.
Take class C thus defined:
:Class C
∇ foo
:Access public
(1+⎕LC)⎕STOP'foo'
'stop here'
∇
:EndClass
Now execute
(⎕new C).foo
foo[3]⍝ stop here
∧
Execution will stop on line 'stop here' no matter how many times you
re-fix the script.
It's true that you cannot stop the fixing of the script. In other
words there's no (easy and non tricky) way to stop:
⎕FIX ':class D' '⎕←''I would like to stop here but there is no way'''
'bla←{}' ':endclass'
WildHeart
> Writing your own source code management system is ... well ... I envy
> people who still think they have enough time to spend on that kind of
> work, and that they have better ideas about source code management
> than the rest of the universe.
I don't envy them much. As I said, the company I work for, built one
over the years. And it never really embraced namespaces (old-style or
scripted) or classes. If I could switch to a better one, I would.
Immediately. But there's simply too much work that would need to be
done to achieve that. We have a sync mechanism to control the
migration of code from one trunk to another. We have a patch mechanism
to send small updates to the customers. We have a bug tracking system
also built in house, very tightly tied to the sync mechanism I just
mentioned. We simply do not have the resources to throw that all away
and start again from scratch. No matter how much I, to begin with,
would love to.
--
Stefano
Phil Last
What Kai means is that if you change your class to be:
:Class C
∇ foo
:Access public shared
'stop here'
∇
:EndClass
put a stop (red dot) on line [2] of foo, fix the script and run:
C.foo
It won't stop at all. If you edit C again the red dot has gone.
crishog
I envy people who still think they have enough time to spend on that
kind of work, and that they have better ideas about source code
management than the rest of the universe.
----
Well I know Phil's written two code management systems (at least) &
I've written one or two myself.
But that's just part of the problem: you have not just to file the
code away, you have to have function checkout, conflict resolution,
release control, etc. Not just "change control" (which we called one
of Phil's systems), but "software configuration management", which I
think Acre does & Maya (another of Phil's CMS) / Inca (my
configuration management built on top of Maya) do as well. Granularity
has to be at the function level & namespace management built in too,
again true of Inca/Maya and I think of Acre.
I've seen Acre, but not used it. Inca lets us manage multiple levels
(developer, test, various live environments) & promote/demote between
them. Enough it's not meant to be an advert.
To answer Dick's question about Excel, I think VB can be treated as an
add-on & managed through "projects", but direct formulae? Forget it,
I've never seen anything at that level - mind you I didn't look too
hard.
And for those not of the English persuasion, Dick's reference is to
the supporters of Millwall football club, who have a chant which runs
along the lines of "everybody hates us, we don't care". More of a
Rugby man myself.
Chris
Bjorn
> 0⊃ There can be good reasons for someone choosing to develop "a workspace"
> and keep all of their stuff there.
The only reason can be for a single developer.
As soon as you have more than one person involved it does not work.
Then the quality of the project/workspace depends on how well
organized that person is.
This situation does not give any confidence in the project/workspace
and noone can take over responsibility of it later.
cjl
What have I done? How do I un-do it?
Phil Last
> SAWS, CONGA, SALT, ACRE, MAYA, INCA, CMS (I am sure I have missed a
> few): routine words in the APL vocabulary but devoid of any meaning
> outside the small APL circle. Any wonder why APL is seen as being out
> of this word in both senses but mostly in the literal sense?
>
> APL LOADS files not OPEN as the rest of the world; unlike the rest of
> the world, APL never CLOSEs a file but sometimes it might CLEAR them
> and risk losing content (no warning given!). APL COPYies - the rest of
> the world PASTEs.
>
> There seems to be a self erected/erecting barrier here which is
> incosistent with the desire to grow. To those inside, this barrier
> denies access to wider exposure (and worked examples & technology
> developed at someone else's cost and debugged and tried industry-wide,
> by thousands). To those outside, the barrier creates a no-go area: the
> benefit of their accrued knowledge has no meaning inside. There are
> more of them outside than inside!
>
> The workspace is a memory dump that preserves a runtime state i.e it
> preserves the execution stack, even a corrupt one, and scope e.g.
> namespaces, local variables, and other clutter (of necessity) created
> during a debugging process etc; hardly the ideal way to manage code.
> But the interpreter does not offer any other option EXCEPT at the user
> descretion. That means that if the user forgets to 'do', all other
> facilities/functionality fall apart without any prospect of any
> recovery.
>
> The workspace is also a binary file format. There is no clear cut
> distinction between source and executable.
>
> That's why any version control software is unsuitable for APL: version
> control needs to be part of the APL IDE (integrated in it) to be of
> any use and when it is, the repository needs to be a network/server
> location. Usually, version control software do not bother with binary
> file formats (because executables can be readily recreated from the
> the source). However, version control software must cope with binary
> files: every version is tracked in its entirety (so things like
> difference comparison or merging etc are not available/valid options).
> Excel workbooks are binary files (even when they are saved as complex
> XML documents).
>
> When in IT, do as IT do (i.e. avoid self harm); then, perhaps, future
> gazing might just provide a clearer picture.
AJ, do you never read the thread you are joining before adding your
diatribe?
No-one in this thread has attempted to defend the workspace as code
repository. It is not a memory dump. It is memory. It's where we
develop. Although we are also talking about how to store code: mostly
either in text files or in RDBs, another abbreviation for you and
hardly an obscure backwater, btw. CMS=Code Management System, heard of
it?,
We are mostly talking about the granularity of what should be stored,
whether a typical APL function of 20 lines (say) or a class script of
200 (or 2000).
And you may not have noticed but this is comp.lang.apl - APL - that's
for people who know or want to know about APL. So if we use
abbreviations that are meaningful only to APLers I don't think we're
going to be putting anyone off do you? Any more than we're going to
attract outsiders if we don't. Your comments might.
So, we've heard it before. You want us all to give up APL and go and
do some serious programming so that we will attract other people to do
APL? No that wasn't it was it? Anyway this has nothing to do with the
topic so I've said enough.
Phil Last
> OK: Lets read your own diatribe ...
>
> "> No-one in this thread has attempted to defend the workspace as code
> repository."
>
>
> "CMS=Code Management System, heard of it?"
>
>
> "You want us all to give up APL and go and do some serious
> programming so that we will attract other people to do APL?"
>
>
> PS: If you have to quote names, please have the courtesy to spell it
> 'correctly' or was that another attempt to defend an acronym?
My mistake Ajay and herewith my apology. Phil.
PLJ
> I'm curious - how do corporates manage things like Excel workbooks?
I can only speak for one corporation; Dialog (not associated with
APL). In ten years, we shipped two applications which used Excel
workbooks.
The first included macros, and we exported the macros as source files
and kept them in source control. Since there was only the one file,
we never created an automated build process.
The second was an Excel file written by the application as a means of
output. The source for that application was saved in source control.
Paul
Dick Bowman
> [... stuff ...]
Thinking a little more, and hoping to get back onto a forward-looking
track.
I feel uncomfortable with the "linearisation" that's embodied in scripts; I
don't like the idea that my "editing unit" might be hundreds of lines long.
That's one of the reasons I think the "you can edit your APL code with an
external editor" is a non-starter for me (that said I do sometimes do a bit
of quick-and-dirty with a text editor to get a class/namespace off the
ground).
So, what does make me feel comfortable?
Firstly, I think the partitioning of workspaces into namespaces which
Dyalog introduced so many years ago is invaluable - all APLs should have
this forthwith (leave aside "forms are namespaces", herein code is all I
care about). APLX does, I know - but last time I looked it was restricted
to a single level, which doesn't work for me.
Given that, I want to operate at three levels.
0⊃ The whole application, so that I can restructure wholesale
1⊃ Individual namespaces/classes in their entirety (again, restructuring)
2⊃ Individual variables/functions/operators
Is editing inextricably intertwined with content management?
I'd like to store my code in a way that I can at least read it if my
favourite APL interpreter becomes unavailable to me (put an end to those "I
just found an old grottoAPL workspace and can't read it" wails). Lots of
files, or bits in a database - don't care, done both (but I do want APL to
be "lightweight").
For classes there are obvious needs for scene-setting (declaring public
fields and so forth) - maybe there's an "APL way" that can be more
appealing than what we see in scripts now (when I think of it I'll let you
know).
Do we do some designing, or are we saying that APL has to fit into whatever
CMS the IT department has previously installed?
WildHeart
> The workspace is a memory dump that preserves a runtime state i.e it
> preserves the execution stack, even a corrupt one, and scope e.g.
> namespaces, local variables, and other clutter (of necessity) created
> during a debugging process etc; hardly the ideal way to manage code.
Smalltalker's have been doing that for about 30 years and seem to be
really really really happy with it. True, Smalltalk is a niche
language for a nice group of people. But the tools available to them
seem to be quite advanced, compared to what's available in a typical
2010 APL interpreter.
I reommend anybody who's interested in computer languages, spending a
rainy weekend playing with Squeak (http://www.squeak.org/). It's
fascinating.
To begin with, the VM that runs under Squeak is fast. Very. Despite
the fact that, for instance, in Smalltalk one can change the
definition of a class with live instances which get all updated
instantly...
Squeak is multiplatform (Windows, Mac, Linux).
And it's a closed environment. Everything, starting from the Windows
manager, is written in Squeak. And people say that APLer like to do
everything by themselves...
--
Stefano
Phil Last
> Firstly, I think the partitioning of workspaces into namespaces which
> Dyalog introduced so many years ago is invaluable - all APLs should have
[...]
> For classes there are obvious needs for scene-setting (declaring public
> fields and so forth) - maybe there's an "APL way" that can be more
> appealing than what we see in scripts now (when I think of it I'll let you
> know).
All namespaces in Dyalog have a readOnly property (ns.⎕WG'Type') with
a value of 'Namespace'.
If we could set it to one of a restricted set of alternatives
including 'Class' then setting it to 'Class' could automatically give
it default fields such as PublicProperties, SharedFields,
PublicMethods &c. all with empty values.
Setting these to lists of names of existing members of the namespace/
class could "promote" those named members to the specified type. All
done with dotted.assignment; little or no need for internal
declarations.
That'd be one way ...
Richard Nabavi
Traditional spreadsheets:
- Mix up data and program logic
- Are saved as a single workspace
- Do not support version control
- Do not support multi-user access
- Have their own proprietary language (a very poorly-conceived one at
that, and near-impossible to debug or check for logical errors)
Despite this, somehow they've managed to exceed the market share of
APL by some large factor - I don't know exactly how large, but I'm
sure it's got lots of zeroes on the end.
Admittedly there are various add-ons and later developments which
address these shortcomings, but those were implemented after
spreadsheets took over the world.
Richard Nabavi
MicroAPL Ltd
Kerry Liles
news:b1acb541-8b81-4f4b...@g18g2000vbn.googlegroups.com...
In other words, spreadsheets are perfect for seat-of-the-pants wanna-be
"programmers" who hack together a 'solution' without any concern for well
established data processing principles like data integrity, security,
backup, error detection etc. Reminds me of Access - wait, that is the same
vendor...
PLJ
environment (read workspace) was clearly superior to Fortran and PL/I,
which I was teaching at the time. Today, the comparison should be with
languages like C#, Visual Basic, or Java and development environments
like Visual Studio or Eclipse . In my opinion, APL doesn’t come out
nearly so well today.
1) APL’s idea of values having type is widespread. No one expects to
debug whether a float was stored in an integer value, or whether you
subscripted past the end of an array.
2) When in the development environment, I can incrementally develop
code, run it and debug it as source, not a hex dump.
3) Running programs can stop on the line where they failed, and I can
examine and change values before restarting.
4) In addition, I can type expressions and discover what I should have
written.
5) I can put stops on individual lines. What is more, I can turn them
off without removing them, and turn them back on when I learn my
latest fix didn’t do everything I’d hoped.
6) When I save the source in the development environment, stops are
preserved, and so are still there when I next load the program to work
on it.
7) Stops are on a line, not a line number. Therefore, if I add more
lines before the one I want to examine, the stops don’t need to be
reestablished or corrected.
8) Instead of filling logs with output, I can just establish watch
lists of values or expressions which display in a grid as I step
through the code.
9) I can ask to step over, or even out of out of a method I don’t want
to debug.
10) Not only do I know of no one who doesn’t make mistakes, I don’t
know of anyone who doesn’t make mistakes during repairs. Being able
to roll back changes makes source control a really valuable tool. It
is really attractive when you don’t need to do anything special to
have preserved the functions you’ve written where they can be checked
in.
11) Objects do a great job of qualifying names and thus avoiding name
collisions.
12) Objects removed my worries with globals, as they become instance
values instead.
13) Objects really come into their own when you need to manage
multiple instances of the same thing. Years ago, I saw this as
valuable for doing graphics. Today, I use them to provide the
functionally of APL values. Each instance carries information about
its type, shape and values.
I realize several of the items above were first introduce by APL. But
several have moved well beyond the APL versions I have access to.
Asking any APL development group to keep pace with what other
languages can assume seems unreasonable. The above list is why I
think APL needs to be integrated into modern development environments,
rather than continue to try to insist "we can do that in a workspace."
Paul
Ibeam2000
As for the Smalltalk image, at least at the time, it took the idea of
the APL workspace somewhat further. This is possibly different now
with Squeak and the like. At the time, Smalltalk was called "the New
APL".
Imagine starting APL, but instead of being able to load individual
workspaces, there is only one active "workspace" which was strongly
bound to the executable and was the very system itself. Most of
Smalltalk was written in Smalltalk.
And in that "workspace", not only your work is stored, but also the
contents of several public libraries, various editors, plus nearly all
of the system, parser, incremental compiler, garbage collector, etc.
No separation of "user", "utility", or "system" code. Nearly all code
is "unlocked", and you are free to change just about anything you
like. Needless to say, it is also quite easy to change and save
misteaks such that the system will never start again.
Smalltalk code would not save into the image unless it was
syntactically correct. Imagine []FX failing if there was an
unbalanced parenthesis. (However, some APL systems are or were not
tolerant of nonexistent []functions, open quotes, etc.)
For any serious development, even with a group of one, a code
management system of some sort was essential. It was imperative to
get the code out of that environment, at the very least for the reason
that if the system was rendered unusable the code would still be
available. Something called "Envy" or "Envy/Developer" comes to
mind. By comparison, APL workspaces were never quite as fragile as
the Smalltalk image.
Smalltalk's disappearance from the market was incredibly rapid, it was
over shortly after Java appeared as a mainstream technology in the mid
1990s. Some Smalltalk people went off to the Ruby world as for many
(including myself) Java was hate at first sight.
Ibeam2000
As for the need for a source control tool, in some cases the workspace
as a source control tool is "good enough". I would be happy to be
Free to Choose whether to use the workspace as a source control system
or a proper source control system.
Not that long ago, I wrote a lightweight source control tool where
user programmers (individuals of a technical calibre not that
different from Excel macro (not VBA) writers) could store their
collection of APL program scripts and data in one ordinary files, then
page it into a central workspace for development and execution. The
alternative would be that every user would save multiple copies of the
(very large and aggressively maintained) central workspace with their
little changes in it. Here the workspace as a source control tool is
definitely not "good enough". Back then, I effectively duplicated the
Sharp APL Package data type and stored it in a file. Today I would
use Subversion & Tortoise. As laziness pays off today, I would never
write anything to duplicate something publicly available unless it was
significantly worse than what I would expect to need or could write
myself. Got to be pragmatic.
It's been my experience that as soon as the APL development group
exceeds one, the workspace source control tool is no longer "good
enough". Although the bickering and infighting amongst developers
will continue, with a source control tool, at least the code with all
the interim versions and an audit trail of who changed what, is safe.
As a practical matter, as soon as the work exceeds casual personal
development, the workspace may no longer be "good enough". The same
would be true for say Excel VBA work, where by default one saves code
and data in a single file.
As far as granularity, to me the problem is that with APL, you have
the workspace, the function, but nothing in between. Other than
something like a namespace which may or may not be appropriate, there
is no arbitrary grouping (like a VBA "module") in APL to help organize
and group different items together. Be that as it may, it is after
all the 21st century, and a hard disk in the small number of terabytes
can be easily bought, maybe even in a drug store, for well under the
price of a fancy restaurant meal. If space was ever a concern, it was
no longer a problem. One can store lots of metadata, and even
individual function lines. Sharp's LOGOS did a good job of this, back
in the 20th century.
The workspace is a place where you would run your programs. A source
management tool is a place you could park programs and data and get
some peace of mind in knowing that the history of the development was
save. Sure, there is some overlap here where you can save a
workspace, but so what?