Getting the younger generations more involved

[Scott Robison]

It is hard to know exactly what was edited in something of that length, but assuming you labelled the new parts as new parts:

1. Please don't color code as a primary metric that you expect to share with people. Some of us are color blind and we will snip the wrong wire and all will die. I understand the 95% or so of the population with "normal" color vision find color coding useful, but always always always provide other coding of data. When I started at my current job, orientation including information about various color flags in the parking lots where we were expected to gather in an emergency situation, the color being tied to the area of the facility in which you are assigned to work. When I made the observation that putting a letter or shape on there in addition to color would be really useful to about 5% of their employees (on average) I was told it wouldn't happen. Which is fine, just using it as an example that expecting color coding to be the exclusive metric that one uses to identify something is not good to a small but statistically significant portion of the population.

I realize that you may not have been talking about literal color coding and were just using it as an example, but it was worth discussing anyway.

2. "Flight hours" is a useful metric. In my opportunities to interview candidates in the past, it has been my experience that people who code in their personal time yet do not have a degree are often better than those who have even advanced degrees but treat it solely as a job. There are exceptions, but that has been my observation.

3. Not a scrum fan myself. Agile is good, but Scrum seems to take certain parts of the Agile Manifesto and throws them in the garbage. And anything that makes work more like Star Trek has to be a good thing. ?

[voidstar]

Correct,  I didn't literally mean colors, it was just an example.   In a way, I think a "new Calculus" is needed - some uniform symbology for the common programming expressions (or whole patterns, if that makes sense).   That was one of the pioneering thing of Isaac Newton:  the development of the symbols of Calculus.   I'm past nit-picking about syntax spacing (in code) and where my braces are, and abandoned Hungarian notation long ago (with occasional exceptions, as in everything).

EDIT: To clarify, when I say "new Calculus" - not to replace existing Calculus, I meant borrowing that concept of a new symbol set that directly corresponds to typical Programming constructs (loops, branches, allocations,  streams, ports,  threads, etc.).  Perhaps something in Simulink has this already, but  I also mean a way to instrument/augment those symbols with additional meta-context-data ("applies to this platform or this build") and how those constructs map to the address-space, interact with thread-pools, etc..

 

Some set of icons (visual-floating in space, not 16x16 BMPs) could represent the very concept of "LOOP", "OPENING A PORT"(data stream), with virtual pipes show these data connections - many pipes begins to show the complexity, and also perhaps starts to show the excessive redundancies.  It's how I see the code in my head, and I wish others could SEE that this program:  it's a complex factory of manipulating bits.   And I've coded long enough to know how good SDKs just "die" as certain key programmers retire.  Code syntax is one thing, but a "worth money" programmer has invested in being proficient in key libraries to get stuff done.  But when the tribal knowledge of that in-house library evaporates, yikes.   It's daunting to inherit a 30 year old Ball-of-FORTRAN, but if the equations are still valid, what's the saying "don't throw the baby out with the bathwater"?    But if all that logic could be presented in a standard set of virtualized icons - my virtual "Software Clockwork", maybe it becomes more approachable to future generations.   Maybe.  But perhaps just like ancient Monks - translating ancient text for centuries is just the way of things have to be for awhile.   

 

I'm not saying Latin/Pure Assembler is The Way, but I'm just saying we're struggling to move beyond High-Level Languages, to (more) cleanly abstract out Intent vs Efficient Clockwork (optimized opcodes) to invoke that intent.  Speaking of optimizers, yes they are quite magical.  But my mind is more about: how to make existing source more approachable to the-next-generation of caretakers.    I can see a Programmers Keyboard, with our standard symbols - or however, to gesture up a FOR-LOOP, it's gonna manipulate 3-data cubes, and one of those cubes it going to get sent thru this pipe to a database.... Stuff like that:  a Data Cube just being a visual virtualization of a STRUCT, but in that virtualization you can immediately see how it is memory-aligned, etc.  (the corner of the Data Cube is some etched symbol indicating the platform -- immediately, not fiddling around with #define target settings).

 

 

 

[iljitsch]

I came to this topic/thread after searching for "Python".

I was one of those kids who first learned BASIC and then 6502 assembly on the C64 and then later studied computer science. That is just not a thing anymore. The X16 has the potential to remedy that, at least on some modest scale.

However, I think the BASIC / assembly combo is less than helpful. Both of those do help you learn to understand the machine, but they don't teach you good programming, or something you can use elsewhere.

So what I've been thinking about: what about coming up with a subset of Python that replicates the BASIC 2.0 functionality? Python is interpreted and thus gives you instant results just like BASIC. It doesn't use annoying syntax rules like { } ; you see in other common languages, but it does do away with BASIC's GOTO statement and all the bad habits that creates.

It would need to be a subset of the Python language to fit on an 8-bit system, but also because that way, the language is small/simple enough to understand quickly so you can read and understand other people's code. But when you reach that level, you've also made a good start learning "real" Python.

So in addition to "you can easily write your own games by banging the hardware!" there would be the argument "and you'll learn programming skills that will serve you the rest of your working life".

Thoughts?

[BruceMcF]

If it doesn't come with Pythonesque libraries, it won't REALLY teach them Python type programming, and it's the libraries that require the massive porting effort if you are working with a non standard "Python like" language. Teaching the Python language without Python libraries is like teaching people to build a brick and mortar wall, without including the bricks.

It's really the same for ANY slimmed down version of a  "modern" interpreted language. So really, tackling the challenge head on, the first step is to ask the question, which of the "modern" languages have the easiest libraries to port?

[SlithyMatt]

11 minutes ago, BruceMcF said:

which of the "modern" languages have the easiest libraries to port?

I'm going to say, not Java. ?

I don't think anything is going to fit this particular bill. The educational benefit of the X16 is not going to be that direct. It's about being able to understand a complete system and work around limitations. That kind of learning is far more valuable that training up to be a Python code monkey, which you could do with a Raspberry Pi or literally any cheap modern computer that the X16 can't really compete with on performance/price ratio, or even price alone.

[Cyber]

35 minutes ago, SlithyMatt said:

The educational benefit of the X16 is not going to be that direct. It's about being able to understand a complete system and work around limitations.

I agree. X16 is also about direct low level connection between user and hardware. Something that modern systems don't provide.

[iljitsch]

BruceMcF:

This isn't about Python for Python's sake. I fully embrace the "direct low level connection between user and hardware". But can we please do it without GOTO?

I guess having IF ... THEN ... ELSE ... ENDIF would also accomplish that. But an additional benefit of using a small Python subset (only the stuff that's also in BASIC) is that it's easier to move code from an X16 to a modern machine (as long as it doesn't use the special hardware), and for someone who learned programming on an X16 to move to a modern machine.

Of course once you can program the language doesn't matter all that much, but it's still easier if you don't have to start from scratch.

[BruceMcF]

1 hour ago, iljitsch said:

BruceMcF:



This isn't about Python for Python's sake. I fully embrace the "direct low level connection between user and hardware". But can we please do it without GOTO?



I guess having IF ... THEN ... ELSE ... ENDIF would also accomplish that. But an additional benefit of using a small Python subset (only the stuff that's also in BASIC) is that it's easier to move code from an X16 to a modern machine (as long as it doesn't use the special hardware), and for someone who learned programming on an X16 to move to a modern machine.



Of course once you can program the language doesn't matter all that much, but it's still easier if you don't have to start from scratch.

What does "can we please do it without GOTO" mean in the context of a system that has a Forth compiler available before launch (and may have a second). If you mean, "will the design team please make Basic incompatible with CBM V2 Basic," I would predict no, they won't. If you mean add to the ROM Basic features that make GOTO avoidable, sure, go ahead and program those and issue a pull request.

We can HAVE whatever language we can write, if it's within our time and skill to write it.  There's already a Forth implementation, which avoids goto, a Small C compiler running on that Forth, maybe explorations of the m-code interpreter for the Kim-1 will lead toward a Small Pascal, and of course, since a Lisp had been implemented in Forth, having a Forth means it's not far from having a Lisp.

But IMV, a "small Python subset" either isn't REALLY Python, in any important way, or else isn't REALLY small, in the sense of fitting comfortably a CX16. A "Basic but with some superficial Python syntax" seems like the likely result, giving users who haven't used real Python a hopelessly confused idea about how Python programming works.

A small-c shell program that follows small-c syntax but is interpreted would be well within the capabilities of the CX 16. And after all, the DICE top 12 programming languages by job postings has a clear top 6, between 20,000 & 80,000, where #7 is under 10,000. It puts SQL first, then Java, Python, JavaScript, Microsoft C# and C++, with the combined C's close to Python in total number of job listings, so C is far from dead yet.

 

[SlithyMatt]

8 minutes ago, BruceMcF said:

It puts SQL first, then Java, Python, JavaScript, Microsoft C# and C++, with the combined C's close to Python in total number of job listings, so C is far from dead yet.

It's also worth noting that C/C++ jobs are generally better paying, as well.

[Scott Robison]

2 hours ago, SlithyMatt said:

It's also worth noting that C/C++ jobs are generally better paying, as well.

Indeed! I attended university from 1986 through 1989 but didn't finish. I just was too immature at that point in my life to take my studies seriously. I went back in 2016 and finished a software engineering degree December 2020. Thus I'm in a "unique" position of having about 33 years experience, most of it including C++, while also being a recent college graduate. As a result, I get a lot of contacts from recruiters wanting to slot me into entry level webdev positions. They think they're offering great money for an entry level position (and they probably are) but rarely do I have anyone contact me who can even approach where I'm already at, even once they realize that I'm not simply a recent grad.