Getting double semi as sequencer harvested.

To be honest, I don't think it matters what the format is.  It could
just as well be XML.  I think if we have a really good, Smalltalk
neutral revision system all "file in" work could be done with that
tool exclusively.  At that point all dependency problems, etc. are the
job of the RCS.

On 9/14/07, Damien Pollet <[hidden email]> wrote:

>>>>> "Jason" == Jason Johnson <[hidden email]> writes:

Jason> How is publishing a private email someone sends you without warning as
Jason> use for an attack not a means of damaging their credibility in the
Jason> conversation (and therefor stifling them)?

It is also arguably a violation of copyright, and could be actionable.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

On 14/09/2007, Jason Johnson <[hidden email]> wrote:
> To be honest, I don't think it matters what the format is.  It could

The point was, it has to be a format, not a program :)



--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org

Hi,

Jason Johnson wrote:
> To be honest, I don't think it matters what the format is.  It could
> just as well be XML.  I think if we have a really good, Smalltalk
> neutral revision system all "file in" work could be done with that
> tool exclusively.  At that point all dependency problems, etc. are the
> job of the RCS.
>  

The take home point is to eliminate alternative syntaxes for new
capabilities. The alternative capability should be placed in the library.

Yes it may be fine to have a standard XML exchange format for those that
like XML as that would be in the "library" and not in the language itself.

However, it's vitally important to have a Smalltalk based format that is
expressed fully with pure message based syntax. I've shown that that is
not just possible but desirable.


Obviously the reference to "firstName" in the example above would need
to be tagged as needing resolution: what is it? a parameter? a instance
variable reference? a reference to an enclosing method? What scoping
context does it belong to? That doesn't need to be determined at compile
time! It can be determined and resolved at "construction" time when the
block is added to a class. It can be resolved at runtime. If it can't be
resolved obviously a #unresolvedVariableReference error would need to be
generated.


>> When we brainstormed on Sapphire's syntax, I proposed to add a new
>> literal for parsed-but-not-yet-compiled-syntax. You would then pass
>> those objects to reflective methods in charge of installing that code
>> in the system (and thus resolving variables and such).

Sounds interesting. Can you provide examples?


>> IMHO it's
>> better to clearly distinguish between program text and actual system
>> behavior.
>>    

Yes, but it's best to NOT have two or more different syntaxes! Both
program text and system behavior configuration can be implemented with
ONE unified message based syntax using unary, binary and keyword messages.

As a matter of programming style the two concerns can be kept separate
if needed. The IDE can even provide "code review" warnings. This code
review "suggestions" and "warnings" is a highly successful approach at a
major Smalltalk installation.

People want to put all kinds of new syntaxes into Smalltalk. Don't
forget that we have one of the most powerful development environments on
the planet (and as far as we currently know, in the universe ;--)!
Almost all of the syntax enhancements that people suggest are better in
the library and the IDE. Let's put them there!


>> BTW I was also pushing for using an executable form for fileins:
>> filing in a file would be the same making a "do it" on the file's
>> contents, installing code in the system while the doit runs.

That is essentially what I've show can easily be done while using
Smalltalk. Filein's become do its. Certainly for a standard file in
format the language syntax and messages used in the filein need to be
standardized in a library for file ins. I would suggest that that
library be under an open BSD+D license so that all the vendors can make
use of it freely.


>>  Now I'm
>> really not sure it's a good idea compared to a declarative syntax that
>> allows tools to manipulate the code as an abstract structure without
>> installing it.
>>    

It's way better to use the existing messaging syntax than a special
declarative "syntax". The "declarations" can be made within the existing
Smalltalk message passing syntax of unary, binary and keyword syntaxes.
This has the benefit of eliminating the need for other syntax forms and
enables the extensibility of the declarative system itself! All, I
repeat, ALL META DATA and META OPERATIONS can be achieved with message
syntax!

>> Damien Pollet
>> type less, do more [ | ]
>>    

Nice signature statement.

All the best,

Peter

Randal L. Schwartz wrote: Hi,

Nonsense, it's valid fair use. Learn copyright law.

Cheers,

Peter

Am Donnerstag, 13. September 2007 22:00:55 schrieb Peter William Lount:
> Hi,
Hi, first I want to say, that I'm thinking of the same ideas that you think of
and I really like the [a. b. c.] values idea.
However, you indeed change the syntax of blocks for merging block syntax with
method syntax when you say

[firstName: aString | firstName := aString ].

aren't you? at least as far as I know ST80... ;) . I would prefer something
like this:

Person addInstanceMethod: [ :aString | firstName := aString ] named:
#firstName:

I personally like to see a Block as a simple collection of statements. That it
is internally compiled to some bytecode sequence _not_ necessarily
representing the different statement borders is just an optimization for the
sake of speed. Howerver, instead of byte code I'm dreaming of some kind of
AST... Be aware, that you can represent any tree data structure with a
sequential array resulting in just another form of "byte code". ;)

> All the best,
>
> Peter
Regards,
Martin

>>>>> "Peter" == Peter William Lount <[hidden email]> writes:

Peter> Nonsense, it's valid fair use. Learn copyright law.

Nonsense, there's caselaw that says that letters sent from person A to B
were owned by A, because B wanted to publish them when A became famous.

I forget the specifics, but it's been decided.

That is why I said *arguable*.  I don't think anyone's argued the email case,
but the physical mail case has precedent.

Don't wave "fair use" so broadly.  It really isn't that broad.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Could you take this off-list, please? Or at least flag as off-topic?

Thanks,

- Bert -

On Sep 14, 2007, at 21:03 , Randal L. Schwartz wrote:

Am Freitag, 14. September 2007 21:01:54 schrieb Martin Beck:
> Person addInstanceMethod: [ :aString | firstName := aString ] named:
> #firstName:
Ah, I just see, you already stated the #named: variant. Those who can read are
clearly in advantage... ;)

Regards,
Martin

Damien Pollet wrote:
No, it seems that you didn't understand. It's just the same as standard
smalltalk class definitions - in fact you could simply use those
messages if you wanted (I don't like them since the variable names are
just in a string but whatever).

It's no different than what chunk format does now and has done since the
beginning of Smalltalk time anyhow.

Again it's how you evaluate the block isn't it! So, this is our fourth
block evaluator!

1) Normal Smalltalk statement evaluator returning last result.
2) Collecting results from statements evaluator that returns a
collection of the results of all statements.
3) Forking statements in parallel and rejoining them evaluator for
specifying parallelism (for N-Core processors).
4) "File In" format evaluator that supports mixed declarations and
regular smalltalk programs. (This evaluator may actually not be needed
as it likely can simply be part of (1), (2) and (3) above, but it's here
for clarity of thought).

The list grows step by step. The future is taking shape.

> To be declarative, your language for "changesets" should only accept
> messages like #addInstanceVariable: you mention. I suppose it would
> have messages for declaring packages , protocols etc.

Yes, that would all need to be standardized to ensure portability. But
that's easy since it's in the library of objects! If the library is made
open source with a true-free source license such as BSD then all the
vendors can use it without any complications. There could be an
additional clause that those that use it would need to adhere to the
Smalltalk File In Standard and process for adding new features.


> But since the
> grammar is the same, users will be tempted to insert chunks of
> imperative Smalltalk in places. What do you do then?

Execute the imperative code. The two can be mixed at will.


> ignore them and only consider the declarative messages you know about? then you're not
> using the semantics of Smalltalk.
>  
No, the semantics of Smalltalk stay the same, or essentially the same.
When you change classes at runtime in smalltalk it's no different than
what I'm suggesting. In fact Smalltalk heads towards a more pure
smalltalk than ever before in terms of it maximizing the big idea of
message passing and message passing syntax.


>> All meta operations can be done with standard Smalltalk syntax of unary,
>> binary and keyword syntax messages!
>>    
>
> Sure, they are. But those messages exist to implement tools like the
> compiler, not to declaratively describe code.
>  

Why not? It's not just elegant it's making use of the power of
messaging. The big idea in Smalltalk is messaging.

All META operations, such as declarations can be done with message
passing. It's simple. It's elegant and it's Smalltalk's way.


The same syntax can cover anything that needs to be expressed including
ALL meta data of the virtual machine. The same syntax can be extended -
in the library - to express other programming paradigms and
data-structure organizations other than objects and classes. All types
of object models are expressible. The message passing syntax of
Smalltalk in combination with an object library are a potent concept
that is highly expressive. Think about it for a while. I have.


> We do currently have a "syntax" for declaring packages and classes and
> protocols, in the form of the Browser's graphical interface, but it's
> obviously not practical to scan screenshots of the browser to file-in
> code. So we're searching for a textual, declarative alternative.
>
>  

The textual declarative alternative is here. I've described it. It can
handle any kind of declaration that you need. It is extensible, once
implemented, via a standard object library. It's based upon message
passing syntax, so it exists as first class objects in Smalltalk's world.

I can answer all questions about it. If I can't answer a question this
is a very smart group and solutions are within reach.

The point is that the declaration is expressed in existing message
passing syntax. The "declarations" are objects that assist the compiler
in it's job. They are new objects that would be added when and if needed.


All the best,

Peter

Hi Martin,

Martin Beck wrote:
> Am Donnerstag, 13. September 2007 22:00:55 schrieb Peter William Lount:
>  
>> Hi,
>>    
> Hi, first I want to say, that I'm thinking of the same ideas that you think of
> and I really like the [a. b. c.] values idea.
>  

Excellent. Birds of a feather flock together!


Yes, the syntax adjusts towards a unification of Blocks and Methods.
This sort of minor syntax change is acceptable since it moves Smalltalk
towards a more powerful future with capabilities that are essential in
competing with other languages and in expressing new programs
eloquently. This sort of change has happened with blocks when variables
were added to them and other minor changes by different vendors to
blocks over the years. Syntax that adds new characters such as "{" and
"}" needs to be very seriously considered especially when it's adding
capabilities in fixed ways that aren't extensible and that violate the
message passing paradigm.


> at least as far as I know ST80... ;) . I would prefer something
> like this:
>
> Person addInstanceMethod: [ :aString | firstName := aString ] named:
> #firstName:
>  

Yes, that is valid and possible in a unified block and method syntax.


> I personally like to see a Block as a simple collection of statements.

Yes, that's a very powerful perspective. It's a hierarchical collection
of statements in the more general form.


> That it is internally compiled to some bytecode sequence _not_ necessarily
> representing the different statement borders is just an optimization for the
> sake of speed. Howerver, instead of byte code I'm dreaming of some kind of
> AST... Be aware, that you can represent any tree data structure with a
> sequential array resulting in just another form of "byte code". ;)
>  

Yes, the whole issue regarding statement boundaries not being present in
existing Smalltalk byte codes or natively compiled code is strictly a
code optimization. If statements boundaries are needed then they need to
be compiled in for code that needs it even if that code needs to be
compiled and optimized on the fly. The Self Language has done this very
effectively having five or six different versions for a method (or just
as easily a block).

It's nice to move the discussion forward with someone who gets it for a
change.

All the best,

Peter

Randal L. Schwartz wrote: Note: the subject heading was "Re: Fear and loathing of the
"perification" of Smalltalk".

Hi,

Fair use applies in this situation.

There are also other laws other than copyright to consider. In British
Columbia, where I am located, a party to a conversation may make it
public if it's in defense of their person as my posting clearly was. End
of story.

Also I didn't retaliate with any personal attack. I simply stated the
facts of what was said and asked the person to stop their attacks, which
seems to have occurred as the subsequent email-posting exchange shows.
Furthermore, out of a desire to have positive conversions subsequently
follow, I provided suggestions of how to ask appropriate questions
rather than initiate ad hominem attacks.

I suppose that you support ad hominem attacks upon the person even if
they are sent privately to attempt to influence, "bully" or "inflame"
someone's behavior in a negative way with false accusations?

How would you have handled it in a way that would positively influence
the person's initiating the ad hominem person attack?

All the best,

Peter William Lount
[hidden email]

Martin Beck wrote:
> Am Freitag, 14. September 2007 21:01:54 schrieb Martin Beck:
>  
>> Person addInstanceMethod: [ :aString | firstName := aString ] named:
>> #firstName:
>>    
> Ah, I just see, you already stated the #named: variant. Those who can read are
> clearly in advantage... ;)
>  
Hi,

;--) I like your sense of humour too!

Cheers,

Peter

Am Freitag, 14. September 2007 21:44:48 schrieb Peter William Lount:

Hi Peter,

> > However, you indeed change the syntax of blocks for merging block syntax
> > with method syntax when you say
> >
> > [firstName: aString | firstName := aString ].
> >
> > aren't you?
>
> Yes, the syntax adjusts towards a unification of Blocks and Methods.
Ok, but in my opinion, it is not necessary to adjust the syntax to achieve
this unification. I'd rather interprete a Method as a named Block. Your
syntax change does early binding of a name to an implementing Block, which we
don't want in Smalltalk... :) The current block syntax does - as you stated,
too - already incorporate the features needed in a method, like temps and
arguments. So all you need, is to bind a Block to a class und a special
method name (which has to have the same arg count).
While running the VM/compiled code, the context decides, whether the block is
evaluated in a normal way, e.g. a home context and correctly interpreting the
return etc., or whether it is evaluated in a method context. So we are at
your differant evaluators again. ;)

> > I personally like to see a Block as a simple collection of statements.
>
> Yes, that's a very powerful perspective. It's a hierarchical collection
> of statements in the more general form.
A hierarchical collection which could be called Abstract Syntax Tree, hehe.
Not to convince you (which is not needed ;) ), but just to add my 2 cents: We
all know, that in a standard Smalltalk VM a Block is simple compiled code,
which can evaluated resulting in a single value. However, if you try to
explain such lambdas, closures (or any other name you might think of) to
Smalltalk newbies, especially those from C/C++/Java backgrounds, you end up
in saying to them: "A Block is source code you can save in a variable and
execute it later". I don't want to discuss, whether that is right or wrong,
but I think it helps them to understand a little bit of what is really meant.
That differs from the former statement, that it says "source code". And
source code is a (hierarchical) collection of statements, even in Smalltalk -
at least to some extent.
I think the newbie way of thinking of blocks is indeed the more natural one,
than viewing it from the VM implementation side.

> It's nice to move the discussion forward with someone who gets it for a
> change.
Thanks. If I remember correctly Ian Piumarta does (somehow) similiar things
with his Id Smalltalk variant. I believe, he adds blocks to classes as named
methods, too. So I've got these ideas from him... *g*

> All the best,
>
> Peter
Best regards,
Martin

Since this is an off topic thread, I'd like to know something Mr. Lount
about your assembly programming and Gemstone Warrior. I played that game in
the 80's on an Apple here in Southern Ontario (Oakville). I now own a
Commodore 64 and a copy of Jim Butterfield's book on machine language. (He
just past away in June.)

I want to know if the chip you wrote assembler for was a 6502, as Apple's
had used that chip in the Apple 2 line. And whether you learned from
Butterfield's book. If not, with what books and for what chip did you learn
assembler?

Chris Cunnington
Toronto

Note: the subject heading was "Re: Fear and loathing of the
"perification" of Smalltalk".

Hi,

General thoughts.

Maybe those making ad hominem personal attacks need to consider the
wider ramifications of their accusations before making them. That is
being responsible. There are consequences to the person(s) initiating an
ad hominem attacks that some of you might not realize.

The new standard of conduct - just don't accuse people of being a
"troll" or X in the first place for it's an ad hominem personal attack;
furthermore it is designed to stifle opinion and suppress free speech.
Do you want your free speech abridged? No, then don't try to suppress
others.

People have the right to defend their person and this right even allows
them to make private communications public! The best option is to simply
ask appropriate on topic questions without attacking people. If unsure
of their intent, simply ask them what their intent is.

I'm done with this if you are.

All the best,

Peter


 

hi Chris,

Hi Chris,

Chris Cunnington wrote:
> Since this is an off topic thread, I'd like to know something Mr. Lount
> about your assembly programming and Gemstone Warrior. I played that game in
> the 80's on an Apple here in Southern Ontario (Oakville).

Very cool.

> I now own a
> Commodore 64 and a copy of Jim Butterfield's book on machine language. (He
> just past away in June.)
>
> I want to know if the chip you wrote assembler for was a 6502, as Apple's
> had used that chip in the Apple 2 line.

Yes, the chip was a 6502. The one that shipped in the Apple. Later on -
as in much later on - I installed a zip chip that took the processor
speed up from 1mhz (yes, one megahertz) to a wopping 10mhz! Wow, ten
times faster and Gemstone wasn't even playable!

> And whether you learned from Butterfield's book. If not, with what books and for what chip did you learn
> assembler


I don't recall which book the "Butterfield" book is. I have a whole box
of Apple ][ books in storage. I'd have to look at them. The book was a
green instruction set manual possibly published by MOS themselves or
someone like Osborne (who was the O'Reily books of that era). I have a
lot of Apple two magazines. I also worked full time selling Apple ][
systems for up to $14,000 a pop (with printers and VisiCalc to be sure).
(Ah, those days are long gone though!) The game was also ported to the
C64 and Atari 800 by my team. Those were slightly different 6502 chips
and obviously different graphics hardware too.

In the following years I've studied many instruction sets. After a while
they are essentially the except in the pesky details of getting it right
with whatever processor you happen to be working on at the time. The
biggest differences are in the number of registers, the control
registers, the processor bit width (8, 16, 32, 64, etc...), and their
different syntaxes. Nowadays there are many more instructions especially
on the X86 lines. Recently I'm looking at MIPS again since I'm
interested in the Tile64 processors.

Are you planning on working with 6502? Or other assembly langauges? What
are you working on if I may ask?

Cheers,

peter

Thank you very much for replying. Well, I'm newish to computers and
programming. I'm surrounded at the computer clubs I attend here in Toronto
such as Unix Unanimous, The Toronto Linux Users Group, The Beach Outings
Club (my Smalltalk club) by people who have been programming forever.

I'm also a member of the Toronto PET Users Group, which has been going since
1979. That's PET as in Personal Electronic Transactor from 1977 and
Commodore. Next week I'll be going to TPUG to attend a discussion about Demo
programming. That's in the Demoscene, which is mainly Europeans writing
video demonstrations and SID chip music on their Commodore 64's and Amigas.
Wild, really, that they do that.

I mentioned Jim Butterfield, because I wasn't programming in the early
1980s, and I know he's famous amongst people here in Toronto and, obviously,
at TPUG, so I assumed you'd heard of him. A bit of a stretch, I guess.

So, I'm interested in 6502 assembler, and I just bought Randal Hyde's "The
Art of Assembly Language" for the 80x86 set. The point of this is that I've
gotten into a large topic -- computer programming -- and I keep trying to
see it from different points of view. Assembly seems to me another great,
bottom up way to learn about this stuff. Being surrounded by people who know
so much more can be anxiety producing, so I'm climbing the learning curve,
and I favour the historical approach, thus the interest in old computers,
Commodore, and such.

I liked playing Gemstone Warrior. Actually all my brothers and sister did.

Commodore 64. Still Ready.

Cheers,

Chris Cunnington

Hi,

Martin Beck wrote:
With the change that I suggest it can use either format. It's the most
general approach.

> Your syntax change does early binding of a name to an implementing Block, which we
> don't want in Smalltalk... :)

Please explain further, I didn't get your meaning.

> The current block syntax does - as you stated,
> too - already incorporate the features needed in a method, like temps and
> arguments. So all you need, is to bind a Block to a class und a special
> method name (which has to have the same arg count).
>  

Yes, and resolve any "variable names" that need to be tied down to a
scoping context. Either at the point the block is attached to a class
(or traits node) or at the point when a block is evaluated as a block.


> While running the VM/compiled code, the context decides, whether the block is
> evaluated in a normal way, e.g. a home context and correctly interpreting the
> return etc., or whether it is evaluated in a method context. So we are at
> your differant evaluators again. ;)
>  

Well I'm not sure that we'd need a new evaluator for that, but that's an
interesting idea. Let me think on that some more.

>  
>>> I personally like to see a Block as a simple collection of statements.
>>>      
>> Yes, that's a very powerful perspective. It's a hierarchical collection
>> of statements in the more general form.
>>    
> A hierarchical collection which could be called Abstract Syntax Tree, hehe.
>  

;-) Yes.

> Not to convince you (which is not needed ;) ), but just to add my 2 cents: We
> all know, that in a standard Smalltalk VM a Block is simple compiled code,
> which can [be] evaluated resulting in a single value. However, if you try to
> explain such lambdas, closures (or any other name you might think of) to
> Smalltalk newbies, especially those from C/C++/Java backgrounds, you end up
> in saying to them: "A Block is source code you can save in a variable and
> execute it later". I don't want to discuss, whether that is right or wrong,
> but I think it helps them to understand a little bit of what is really meant.
>  

I find that it's a very effective approach of explaining it to people.
At least it's a great place to get start explaining Smalltalk blocks to
them.


> That differs from the former statement, that it says "source code". And
> source code is a (hierarchical) collection of statements, even in Smalltalk -
> at least to some extent.
>  

Yes.

> I think the newbie way of thinking of blocks is indeed the more natural one,
> than viewing it from the VM implementation side.
>  

Yes. It's also the way to think about them at the language level. The VM
is the implementation level and often it's job is to hide much of the
details of the inner workings from the user and the language itself.
That is why I prefer giving the language priority in driving the design
over the concerns of the virtual machine implementation issues (if at
all possible).


>  
>> It's nice to move the discussion forward with someone who gets it for a
>> change.
>>    
> Thanks.

Your welcome.

> If I remember correctly Ian Piumarta does (somehow) similiar things
> with his Id Smalltalk variant.

Yes, Ian's work is really amazing.


> I believe, he adds blocks to classes as named methods, too. So I've got these ideas from him... *g*

I did share my thoughts on the unification of Blocks and Methods with
Alan Kay and Dan Ingalls a few years back; as well I've mentioned it at
OOPSLA and in private conversations with various people. Alan or Dan may
have mentioned it to Ian or I might have mentioned it to Ian at OOPSLA
(I don't recall if I spoke with him there). Or maybe others thought of
it before. We have to ask Alan, Dan and Ian about their coming to the
idea. After telling Allen Wirfs-Brock about it a few years back he said
he'd come across that idea before but that it seemed that no one did
anything with it. So I don't claim ownership of the idea (other than
co-originating it) but I do promote it vigorously since I see it's
value. It's also not a big leap to make as Block and Method syntax is
almost the same - the big leap is seeing it's value.

Part of it's elegance is that it's such a minor change to make the
unification happen and that it has such a powerful new dimension opening
impact!

If a change is required in syntax and it doesn't open a whole new
dimension of extensibility as a result then chop it out. It's like
Tilera's "kill design rule" for their N-Core chips (Tile64 or TileN)
where a N% increase in surface area of the chip must increase
performance by an equal N%!  I apply a similar set of "design kill
rules" for syntax changes to Smalltalk and ZokuScript. If it's not
message based using existing syntax then I ask "how can it be made to
work with messages?" - this was the line of thinking that lead me to see
that all meta data and meta operations can be accomplished with the
existing unary, binary and keyword messaging syntax. That was a
breakthrough! It also means that almost all changes in syntax are not
needed as most changes are attempts to add meta data or operations. The
problem with new syntaxes is that they break the notion of one uniform
messaging syntax and make the world much harder. This makes advanced
topics such as code analysis and code rewriting much more difficult and
cumbersome since multiple syntax forms are involved and they may not
have bidirectional transformations available when being converted this
way and back that way.

I see the elegance and beauty of a unified block and method syntax for
Smalltalk and ZokuScript such that I'm promoting it in the Smalltalk
community. Certainly it will end up in ZokuScript as it's an essential
building block for the future that I see for Smalltalk like or Smalltalk
inspired systems.

If we as designers of a computer language (or other software programs)
fail to bring the principles of elegance, beauty and simplicity to the
language (or program) design and the design process then how can we
expect our products to be powerful or users to be elegant, use beauty
and simplicity in their expressions with our languages and tools we make?

All the best,

peter

Chris Cunnington wrote:
> Hi,
>  

Thanks, I'll let Trouba know that you liked the game and that we talked
about it. He and I designed the game together. I did the programming and
he did the graphics.

Assembly language is a great way to learn computing. Once you learn that
then you know it's much harder for people to pass off nonsense by you.
You comprehend the details much better.

If you can program 6502 then you can program any processor out there.
You may wish to start learning with the latest version of the X86
processor family though. Learning that could be better for your career -
assuming that's a direction in your life.

I learned assembly before pretty much any other language. I learned 32
bit Interdata assembly before I learned Basic! My favorite languages are
Assembly Language, Smalltalk and ZokuScript. That green 6502 book I
mentioned is very well worn indeed.

To me Smalltalk has become the new assembly language.

That's why I'm building ZokuScript - it's the a higher level language
that builds upon the concepts of languages like Smalltalk, Lisp, Erlang,
Assembly, Forth, Io, Self, Slang, etc....

While performing an exhaustive search through the possible spaces in the
universe of language syntaxes I've come across some enhancements that
work naturally for Smalltalk while keeping true to the first principles
of messaging passing syntax, everything is an object including ALL meta
data and meta operations.

I'm contributing those discoveries to the Smalltalk community in the
hopes that some of them will be adopted. All of the discoveries and
ideas that I've presented, plus many more, are going into the ZokuScript
language since the applications and systems that I'm building require
certain linguistic capabilities not easily expressible in existing
languages without a lot of work.

I encourage you to continue your efforts with assembly language.

Cheers,

Peter