On Sat, 10 Feb 2024 08:10:13 -0800 (PST), Fred Bloggs
<bloggs.fredbloggs.fred@gmail.com> wrote:

>Another failure of 'let the market decide.'
>
>https://spectrum.ieee.org/lean-software-development

Complexity is a game that some people enjoy.

And some people like simplicity. Their stuff works better.

On Sunday, February 11, 2024 at 4:07:37 AM UTC+11, John Larkin wrote:
> On Sat, 10 Feb 2024 08:10:13 -0800 (PST), Fred Bloggs
> <bloggs.fred...@gmail.com> wrote:
>
> >Another failure of 'let the market decide.'
> >
> >https://spectrum.ieee.org/lean-software-development
> Complexity is a game that some people enjoy.
>
> And some people like simplicity. Their stuff works better.

In the limited number of cases where it is complex enough to work at all. The simplest mechanism that actually works is always intellectually satisfying, but there's no guarantee that it works all that well.
Breaking up a complex problem into simpler sub-problems and solving each one of them separately tends to be as safer approach, and leads to more easily comprehensible circuits.

John Larkin prefers to avoid the complexities of transformer design. This isn't a virtue.

--
Bill Sloman, Sydney

On a sunny day (Sat, 10 Feb 2024 09:06:03 -0800) it happened John Larkin
<jl@997PotHill.com> wrote in <g4bfsidsbmg316togaaff19e63vv1pnqbo@4ax.com>:

>On Sat, 10 Feb 2024 08:10:13 -0800 (PST), Fred Bloggs
><bloggs.fredbloggs.fred@gmail.com> wrote:
>
>>Another failure of 'let the market decide.'
>>
>>https://spectrum.ieee.org/lean-software-development
>
>Complexity is a game that some people enjoy.
>
>And some people like simplicity. Their stuff works better.

It is cool coding in asm without using external libraries.
I can do anything I like in KILOBYTES:
https://panteltje.nl/panteltje/pic/scope_pic/index.html
nice to do Fourier transform in a few bytes... sine lookup table
has a Usenet compatible output, use fixed size font:
https://panteltje.nl/panteltje/pic/scope_pic/screen_dump2.txt

Most web things I have coded in a few lines of C,
started on a browser too, but that is a moving target.. takes too much time.
Also wrote this Newsreader I am posting this with, it runs on a Raspberry Pi4
raspberrypi: ~ # whereis NewsFleX
NewsFleX: /usr/local/bin/NewsFleX
raspberrypi: ~ # lb /usr/local/bin/NewsFleX
-rwxr-xr-x 1 root root 383796 Mar 13 2023 /usr/local/bin/NewsFleX*

lb is short for ls -rtl --color=none
383796 Mar 13 2023 /usr/local/bin/NewsFleX*

'lb' is short for ls -rtl --color=none
383,796 bytes
So < 400 kB
Linked in is libforms for the GUI.
Old verion for x86 here:
https://panteltje.nl/panteltje/newsflex/index.html
libforms however changed, so unless you use a very old verion of that it won't work.

I have dropped that xforms lib too and still have a GUI...
https://panteltje.nl/pub/boats_and_planes.gif
runs 24/7
-rwxr-xr-x 1 root root 329604 Feb 7 2021 xgpspc
329,604 bytes
monitors planes and boat traffic, does navighation, auto-pilot what not.
latest version even has a fire solution.. for defence of course
Only uses these libs, from the Makefile:
$(COMPILER) -o xgpspc $(XGPSPC) -lm -lpthread -lXaw -ljpeg
libmath, libjpeg and libXaw (for the display).

Simplicity, or simple city or whatever it was
of course gcc as compiler.
Or gpasm for the PIC asm code.

I think the ever more bloat comes from trying to sell ever more,
a capitalist trick to suck you for money.
More bloat causes need for ever more powerfull hardware.
So bloat writers get shares in hardware manufacurers and get rich.
Microsore or whatever is a big example.

On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje <alien@comet.invalid>
wrote:

>On a sunny day (Sat, 10 Feb 2024 09:06:03 -0800) it happened John Larkin
><jl@997PotHill.com> wrote in <g4bfsidsbmg316togaaff19e63vv1pnqbo@4ax.com>:
>
>>On Sat, 10 Feb 2024 08:10:13 -0800 (PST), Fred Bloggs
>><bloggs.fredbloggs.fred@gmail.com> wrote:
>>
>>>Another failure of 'let the market decide.'
>>>
>>>https://spectrum.ieee.org/lean-software-development
>>
>>Complexity is a game that some people enjoy.
>>
>>And some people like simplicity. Their stuff works better.
>
>It is cool coding in asm without using external libraries.
>I can do anything I like in KILOBYTES:
> https://panteltje.nl/panteltje/pic/scope_pic/index.html
>nice to do Fourier transform in a few bytes... sine lookup table
>has a Usenet compatible output, use fixed size font:
> https://panteltje.nl/panteltje/pic/scope_pic/screen_dump2.txt
>
>Most web things I have coded in a few lines of C,
>started on a browser too, but that is a moving target.. takes too much time.
>Also wrote this Newsreader I am posting this with, it runs on a Raspberry Pi4
>raspberrypi: ~ # whereis NewsFleX
>NewsFleX: /usr/local/bin/NewsFleX
>raspberrypi: ~ # lb /usr/local/bin/NewsFleX
>-rwxr-xr-x 1 root root 383796 Mar 13 2023 /usr/local/bin/NewsFleX*
>
>lb is short for ls -rtl --color=none
>383796 Mar 13 2023 /usr/local/bin/NewsFleX*
>
>'lb' is short for ls -rtl --color=none
>383,796 bytes
>So < 400 kB
>Linked in is libforms for the GUI.
>Old verion for x86 here:
> https://panteltje.nl/panteltje/newsflex/index.html
>libforms however changed, so unless you use a very old verion of that it won't work.
>
>I have dropped that xforms lib too and still have a GUI...
> https://panteltje.nl/pub/boats_and_planes.gif
>runs 24/7
> -rwxr-xr-x 1 root root 329604 Feb 7 2021 xgpspc
>329,604 bytes
>monitors planes and boat traffic, does navighation, auto-pilot what not.
>latest version even has a fire solution.. for defence of course
>Only uses these libs, from the Makefile:
> $(COMPILER) -o xgpspc $(XGPSPC) -lm -lpthread -lXaw -ljpeg
>libmath, libjpeg and libXaw (for the display).
>
>Simplicity, or simple city or whatever it was
>of course gcc as compiler.
>Or gpasm for the PIC asm code.
>
>I think the ever more bloat comes from trying to sell ever more,
>a capitalist trick to suck you for money.
>More bloat causes need for ever more powerfull hardware.
>So bloat writers get shares in hardware manufacurers and get rich.
>Microsore or whatever is a big example.

That's all very impressive, Jan, but if you were *truly* a hardcore
programmer, you'd be using machine code. ;-)
More seriously, bloat enables coders to hide back doors much more
effectively. They'd never get away with that kind of subterfuge with
ASM.

On 11/02/2024 8:44 pm, Cursitor Doom wrote:
> On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje <alien@comet.invalid> wrote:
>> On a sunny day (Sat, 10 Feb 2024 09:06:03 -0800) it happened John Larki <jl@997PotHill.com> wrote in <g4bfsidsbmg316togaaff19e63vv1pnqbo@4ax.com>:
>>> On Sat, 10 Feb 2024 08:10:13 -0800 (PST), Fred Bloggs <bloggs.fredbloggs.fred@gmail.com> wrote:

<snip>

> That's all very impressive, Jan, but if you were *truly* a hardcore
> programmer, you'd be using machine code. ;-)

Nobody writes machine code. Assembler has a one-to-one relationship with
machine code, but tit is easier to write and read.

> More seriously, bloat enables coders to hide back doors much more
> effectively. They'd never get away with that kind of subterfuge with
> ASM.

Of course they would. Have your ever tried to make sense of poorly
documented and commented assembly code?

And it is possible to make machine code self-modifying - at least on
some machines - which offers even more opportunity, to put in back doors
(and take then away again after you've exploited them).

--
Bill Sloman, Sydney

On a sunny day (Sun, 11 Feb 2024 09:44:22 +0000) it happened Cursitor Doom
<cd@notformail.com> wrote in <nh5hsit657809ebhciaseg2vgprofkhfv1@4ax.com>:

>On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje <alien@comet.invalid>
>wrote:
>
>>On a sunny day (Sat, 10 Feb 2024 09:06:03 -0800) it happened John Larkin
>><jl@997PotHill.com> wrote in <g4bfsidsbmg316togaaff19e63vv1pnqbo@4ax.com>:
>>
>>>On Sat, 10 Feb 2024 08:10:13 -0800 (PST), Fred Bloggs
>>><bloggs.fredbloggs.fred@gmail.com> wrote:
>>>
>>>>Another failure of 'let the market decide.'
>>>>
>>>>https://spectrum.ieee.org/lean-software-development
>>>
>>>Complexity is a game that some people enjoy.
>>>
>>>And some people like simplicity. Their stuff works better.
>>
>>It is cool coding in asm without using external libraries.
>>I can do anything I like in KILOBYTES:
>> https://panteltje.nl/panteltje/pic/scope_pic/index.html
>>nice to do Fourier transform in a few bytes... sine lookup table
>>has a Usenet compatible output, use fixed size font:
>> https://panteltje.nl/panteltje/pic/scope_pic/screen_dump2.txt
>>
>>Most web things I have coded in a few lines of C,
>>started on a browser too, but that is a moving target.. takes too much time.
>>Also wrote this Newsreader I am posting this with, it runs on a Raspberry Pi4
>>raspberrypi: ~ # whereis NewsFleX
>>NewsFleX: /usr/local/bin/NewsFleX
>>raspberrypi: ~ # lb /usr/local/bin/NewsFleX
>>-rwxr-xr-x 1 root root 383796 Mar 13 2023 /usr/local/bin/NewsFleX*
>>
>>lb is short for ls -rtl --color=none
>>383796 Mar 13 2023 /usr/local/bin/NewsFleX*
>>
>>'lb' is short for ls -rtl --color=none
>>383,796 bytes
>>So < 400 kB
>>Linked in is libforms for the GUI.
>>Old verion for x86 here:
>> https://panteltje.nl/panteltje/newsflex/index.html
>>libforms however changed, so unless you use a very old verion of that it won't work.
>>
>>I have dropped that xforms lib too and still have a GUI...
>> https://panteltje.nl/pub/boats_and_planes.gif
>>runs 24/7
>> -rwxr-xr-x 1 root root 329604 Feb 7 2021 xgpspc
>>329,604 bytes
>>monitors planes and boat traffic, does navighation, auto-pilot what not.
>>latest version even has a fire solution.. for defence of course
>>Only uses these libs, from the Makefile:
>> $(COMPILER) -o xgpspc $(XGPSPC) -lm -lpthread -lXaw -ljpeg
>>libmath, libjpeg and libXaw (for the display).
>>
>>Simplicity, or simple city or whatever it was
>>of course gcc as compiler.
>>Or gpasm for the PIC asm code.
>>
>>I think the ever more bloat comes from trying to sell ever more,
>>a capitalist trick to suck you for money.
>>More bloat causes need for ever more powerfull hardware.
>>So bloat writers get shares in hardware manufacurers and get rich.
>>Microsore or whatever is a big example.
>
>That's all very impressive, Jan, but if you were *truly* a hardcore
>programmer, you'd be using machine code. ;-)

I have used machine code in the long ago past.
Here is a nice Z80 disassembler I wrote:
https://panteltje.nl/panteltje/z80/index.html
from emails I know people still use it.

>More seriously, bloat enables coders to hide back doors much more
>effectively. They'd never get away with that kind of subterfuge with
>ASM.

Yes, all those libraries.. I follow the news and sometimes things are loaded
that have backdoors.

But asm, long ago I was involved with card hacking,
things are read only, and how to list the code of a PIC micro
(in those days in the TV smart cards for encrypted TV channels).
That is how I got interested and came to use Microchip PICs..
It is not always easy to list those codes to get the secret algo they use to
encrypt TV transmissions.
I stopped when some EU politician got upset.. some persisted and got sentenced....
But that is how I learned about PICs and got interested in crypto.

On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje wrote:

>It is cool coding in asm without using external libraries.
>I can do anything I like in KILOBYTES:

Back in the 20th century, I knew how to program in C. I
knew what the assembly code would like after I compiled it.

This is C++.

https://en.cppreference.com/w/cpp/links/libs

Now I program in Python. I really don't know how to program
in Python. I'm googlesmart. I google what I want to do,
download the appropriate library and follow the documentation.
I don't know if there is something malicious in there. That's
why I really hate every little stupid program and app that
thinks it needs to auto-update and needs admin approval to
install and screw with the operating system. If there is
a portable option, I get that and I keep old versions until
they break.

On a sunny day (Sun, 11 Feb 2024 10:47:05) it happened
Wanderer<dont@emailme.com> wrote in <980294@dontemail.com>:

>On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje wrote:
>
>>It is cool coding in asm without using external libraries.
>>I can do anything I like in KILOBYTES:
>
>
>Back in the 20th century, I knew how to program in C. I
>knew what the assembly code would like after I compiled it.
>
>This is C++.
>
>
>https://en.cppreference.com/w/cpp/links/libs
>
>
>Now I program in Python. I really don't know how to program
>in Python. I'm googlesmart. I google what I want to do,
>download the appropriate library and follow the documentation.
>I don't know if there is something malicious in there. That's
>why I really hate every little stupid program and app that
>thinks it needs to auto-update and needs admin approval to
>install and screw with the operating system. If there is
>a portable option, I get that and I keep old versions until
>they break.

I do not speak phyton...
No need...
Cplushplush is a crime against humanity, operator overloading etc.
If I see some open source C++ code I like, then I usually recode it in C,
makes it simpler much of the time, did that with some Arduino code.

Sometimes you really need libraries,
I just came across this voice to text program for the Raspberry Pi last week:
https://www.tomshardware.com/raspberry-pi/raspberry-pi-project-lets-you-generate-ai-art-for-your-tv-using-voice-commands
leads to
https://www.hackster.io/petewarden/recognizing-speech-with-a-raspberry-pi-50b0e6
seems to be 1 GB size, for voice recognition you need a lot..
Have not tried or downloaded it yet.

tomshardware.com has often Raspberry projects (all the way down on their main page).

All that said, I run Firefox browser on a Raspberry Pi4 8 GB..
I think it forwards everything I do to anybody ;-) ;-)

I have disabled WiFi and Bluetooth now in the startup file.
But still use a wireless keyboard....
So there is room for improvement as far as security goes.
Am using a Huawei USB stick for 4G internet access that works everywhere in the country or even Europe here.
But of course one could log / decode the RF...

see-eye-aaa must know everything about me by now...
May sent them in a loop!
If they were not there yet....

On Sun, 11 Feb 2024 11:26:15 GMT, Jan Panteltje <alien@comet.invalid>
wrote:

>On a sunny day (Sun, 11 Feb 2024 09:44:22 +0000) it happened Cursitor Doom
><cd@notformail.com> wrote in <nh5hsit657809ebhciaseg2vgprofkhfv1@4ax.com>:
>
>>On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje <alien@comet.invalid>
>>wrote:
>>
>>>On a sunny day (Sat, 10 Feb 2024 09:06:03 -0800) it happened John Larkin
>>><jl@997PotHill.com> wrote in <g4bfsidsbmg316togaaff19e63vv1pnqbo@4ax.com>:
>>>
>>>>On Sat, 10 Feb 2024 08:10:13 -0800 (PST), Fred Bloggs
>>>><bloggs.fredbloggs.fred@gmail.com> wrote:
>>>>
>>>>>Another failure of 'let the market decide.'
>>>>>
>>>>>https://spectrum.ieee.org/lean-software-development
>>>>
>>>>Complexity is a game that some people enjoy.
>>>>
>>>>And some people like simplicity. Their stuff works better.
>>>
>>>It is cool coding in asm without using external libraries.
>>>I can do anything I like in KILOBYTES:
>>> https://panteltje.nl/panteltje/pic/scope_pic/index.html
>>>nice to do Fourier transform in a few bytes... sine lookup table
>>>has a Usenet compatible output, use fixed size font:
>>> https://panteltje.nl/panteltje/pic/scope_pic/screen_dump2.txt
>>>
>>>Most web things I have coded in a few lines of C,
>>>started on a browser too, but that is a moving target.. takes too much time.
>>>Also wrote this Newsreader I am posting this with, it runs on a Raspberry Pi4
>>>raspberrypi: ~ # whereis NewsFleX
>>>NewsFleX: /usr/local/bin/NewsFleX
>>>raspberrypi: ~ # lb /usr/local/bin/NewsFleX
>>>-rwxr-xr-x 1 root root 383796 Mar 13 2023 /usr/local/bin/NewsFleX*
>>>
>>>lb is short for ls -rtl --color=none
>>>383796 Mar 13 2023 /usr/local/bin/NewsFleX*
>>>
>>>'lb' is short for ls -rtl --color=none
>>>383,796 bytes
>>>So < 400 kB
>>>Linked in is libforms for the GUI.
>>>Old verion for x86 here:
>>> https://panteltje.nl/panteltje/newsflex/index.html
>>>libforms however changed, so unless you use a very old verion of that it won't work.
>>>
>>>I have dropped that xforms lib too and still have a GUI...
>>> https://panteltje.nl/pub/boats_and_planes.gif
>>>runs 24/7
>>> -rwxr-xr-x 1 root root 329604 Feb 7 2021 xgpspc
>>>329,604 bytes
>>>monitors planes and boat traffic, does navighation, auto-pilot what not.
>>>latest version even has a fire solution.. for defence of course
>>>Only uses these libs, from the Makefile:
>>> $(COMPILER) -o xgpspc $(XGPSPC) -lm -lpthread -lXaw -ljpeg
>>>libmath, libjpeg and libXaw (for the display).
>>>
>>>Simplicity, or simple city or whatever it was
>>>of course gcc as compiler.
>>>Or gpasm for the PIC asm code.
>>>
>>>I think the ever more bloat comes from trying to sell ever more,
>>>a capitalist trick to suck you for money.
>>>More bloat causes need for ever more powerfull hardware.
>>>So bloat writers get shares in hardware manufacurers and get rich.
>>>Microsore or whatever is a big example.
>>
>>That's all very impressive, Jan, but if you were *truly* a hardcore
>>programmer, you'd be using machine code. ;-)
>
>I have used machine code in the long ago past.
>Here is a nice Z80 disassembler I wrote:
> https://panteltje.nl/panteltje/z80/index.html
>from emails I know people still use it.
>
>
>>More seriously, bloat enables coders to hide back doors much more
>>effectively. They'd never get away with that kind of subterfuge with
>>ASM.
>
>Yes, all those libraries.. I follow the news and sometimes things are loaded
>that have backdoors.
>
>But asm, long ago I was involved with card hacking,
>things are read only, and how to list the code of a PIC micro
>(in those days in the TV smart cards for encrypted TV channels).
>That is how I got interested and came to use Microchip PICs..
>It is not always easy to list those codes to get the secret algo they use to
>encrypt TV transmissions.
>I stopped when some EU politician got upset.. some persisted and got sentenced....
>But that is how I learned about PICs and got interested in crypto.

Many thanks for that well thought-out and well-reasoned response, Jan.
Nice to hear from someone who knows what they're talking about instead
of some half-baked garbage from a moron like Bill Sloman who wouldn't
even be able to set up something as elementary as an Antikythera
orrery. ;-)

On Sun, 11 Feb 2024 10:47:05, Wanderer<dont@emailme.com> wrote:

>On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje wrote:
>
>>It is cool coding in asm without using external libraries.
>>I can do anything I like in KILOBYTES:
>
>
>Back in the 20th century, I knew how to program in C. I
>knew what the assembly code would like after I compiled it.
>
>This is C++.
>
>
>https://en.cppreference.com/w/cpp/links/libs

I never got on with C++. C has a certain elegance to it that I very
much like and I've never moved on from it. In fact I'm such a purist,
I stay faithful to the K&R variant. They tell me it's limiting to do
that, but it does *everything* I need to do so why go further? I find
the simplicity and lack of unnecesary bloat very appealing. I'd
probably still be coding in ASM if C hadn't come along. For me at
least, K&R C is perfection.

>Now I program in Python. I really don't know how to program
>in Python. I'm googlesmart. I google what I want to do,
>download the appropriate library and follow the documentation.
>I don't know if there is something malicious in there. That's
>why I really hate every little stupid program and app that
>thinks it needs to auto-update and needs admin approval to
>install and screw with the operating system. If there is
>a portable option, I get that and I keep old versions until
>they break.

Very wise. I like your style, Wanderer!

On 2/11/24 18:56, Cursitor Doom wrote:
> On Sun, 11 Feb 2024 11:26:15 GMT, Jan Panteltje <alien@comet.invalid>
> wrote:
>
>> On a sunny day (Sun, 11 Feb 2024 09:44:22 +0000) it happened Cursitor Doom
>> <cd@notformail.com> wrote in <nh5hsit657809ebhciaseg2vgprofkhfv1@4ax.com>:
>>
>>> On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje <alien@comet.invalid>
>>> wrote:
>>>
>>>> On a sunny day (Sat, 10 Feb 2024 09:06:03 -0800) it happened John Larkin
>>>> <jl@997PotHill.com> wrote in <g4bfsidsbmg316togaaff19e63vv1pnqbo@4ax.com>:
>>>>
>>>>> On Sat, 10 Feb 2024 08:10:13 -0800 (PST), Fred Bloggs
>>>>> <bloggs.fredbloggs.fred@gmail.com> wrote:
>>>>>
>>>>>> Another failure of 'let the market decide.'
>>>>>>
>>>>>> https://spectrum.ieee.org/lean-software-development
>>>>>
>>>>> Complexity is a game that some people enjoy.
>>>>>
>>>>> And some people like simplicity. Their stuff works better.
>>>>
>>>> It is cool coding in asm without using external libraries.
>>>> I can do anything I like in KILOBYTES:
>>>> https://panteltje.nl/panteltje/pic/scope_pic/index.html
>>>> nice to do Fourier transform in a few bytes... sine lookup table
>>>> has a Usenet compatible output, use fixed size font:
>>>> https://panteltje.nl/panteltje/pic/scope_pic/screen_dump2.txt
>>>>
>>>> Most web things I have coded in a few lines of C,
>>>> started on a browser too, but that is a moving target.. takes too much time.
>>>> Also wrote this Newsreader I am posting this with, it runs on a Raspberry Pi4
>>>> raspberrypi: ~ # whereis NewsFleX
>>>> NewsFleX: /usr/local/bin/NewsFleX
>>>> raspberrypi: ~ # lb /usr/local/bin/NewsFleX
>>>> -rwxr-xr-x 1 root root 383796 Mar 13 2023 /usr/local/bin/NewsFleX*
>>>>
>>>> lb is short for ls -rtl --color=none
>>>> 383796 Mar 13 2023 /usr/local/bin/NewsFleX*
>>>>
>>>> 'lb' is short for ls -rtl --color=none
>>>> 383,796 bytes
>>>> So < 400 kB
>>>> Linked in is libforms for the GUI.
>>>> Old verion for x86 here:
>>>> https://panteltje.nl/panteltje/newsflex/index.html
>>>> libforms however changed, so unless you use a very old verion of that it won't work.
>>>>
>>>> I have dropped that xforms lib too and still have a GUI...
>>>> https://panteltje.nl/pub/boats_and_planes.gif
>>>> runs 24/7
>>>> -rwxr-xr-x 1 root root 329604 Feb 7 2021 xgpspc
>>>> 329,604 bytes
>>>> monitors planes and boat traffic, does navighation, auto-pilot what not.
>>>> latest version even has a fire solution.. for defence of course
>>>> Only uses these libs, from the Makefile:
>>>> $(COMPILER) -o xgpspc $(XGPSPC) -lm -lpthread -lXaw -ljpeg
>>>> libmath, libjpeg and libXaw (for the display).
>>>>
>>>> Simplicity, or simple city or whatever it was
>>>> of course gcc as compiler.
>>>> Or gpasm for the PIC asm code.
>>>>
>>>> I think the ever more bloat comes from trying to sell ever more,
>>>> a capitalist trick to suck you for money.
>>>> More bloat causes need for ever more powerfull hardware.
>>>> So bloat writers get shares in hardware manufacurers and get rich.
>>>> Microsore or whatever is a big example.
>>>
>>> That's all very impressive, Jan, but if you were *truly* a hardcore
>>> programmer, you'd be using machine code. ;-)
>>
>> I have used machine code in the long ago past.
>> Here is a nice Z80 disassembler I wrote:
>> https://panteltje.nl/panteltje/z80/index.html
>>from emails I know people still use it.
>>
>>
>>> More seriously, bloat enables coders to hide back doors much more
>>> effectively. They'd never get away with that kind of subterfuge with
>>> ASM.
>>
>> Yes, all those libraries.. I follow the news and sometimes things are loaded
>> that have backdoors.
>>
>> But asm, long ago I was involved with card hacking,
>> things are read only, and how to list the code of a PIC micro
>> (in those days in the TV smart cards for encrypted TV channels).
>> That is how I got interested and came to use Microchip PICs..
>> It is not always easy to list those codes to get the secret algo they use to
>> encrypt TV transmissions.
>> I stopped when some EU politician got upset.. some persisted and got sentenced....
>> But that is how I learned about PICs and got interested in crypto.
>
> Many thanks for that well thought-out and well-reasoned response, Jan.
> Nice to hear from someone who knows what they're talking about instead
> of some half-baked garbage from a moron like Bill Sloman who wouldn't
> even be able to set up something as elementary as an Antikythera
> orrery. ;-)

Now that you mention it: That piece of hardware was actually pretty
sophisticated, and I think that even today, only few people would
have been able to use it to good effect.

There is a series of videos of someone who built a replica and he
explains its workings to some length. Search for "clickspring
antikythera" on youtube. I found it fascinating, and also somewhat
humbling to realize that my knowledge of our solar system is nothing
compared to what was encoded in this mechanism.

Of course, these days software does it better.

Jeroen Belleman

On 2/11/2024 10:47 AM, Wanderer wrote:
> On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje wrote:
>
>> It is cool coding in asm without using external libraries.
>> I can do anything I like in KILOBYTES:
>
> Back in the 20th century, I knew how to program in C. I
> knew what the assembly code would like after I compiled it.

A minor point; you THOUGHT you knew what the ASM would look like...
you knew what the processor should be *doing*.

Newer compilers are often considerably smarter than the
programmers using them. They will rearrange code (where
dependencies allow it) to avoid pipeline stalls. Or,
realign structures to avoid misaligned memory accesses.
Or even eliminate calls to functions that it can inline
more efficiently. Or, avoid generating code that will
tickle a "bug" in the targeted processor's HARDWARE!

But, the point of knowing what the processor is expected
to be doing is important.

> This is C++.
>
> https://en.cppreference.com/w/cpp/links/libs

C++ (and other OOPS) adds complexity to help the programmer
manage the complexity in his program/solution.

A big (huge!) part of software development is modeling
the application and its domain. A good model makes the
implementation intuitive... it just *fits*. This is
important because code is meant to be READ, not WRITTEN;
if the next guy (that you likely have never met and with
unknown capabilities) can't understand what you've written,
expecting him to make fixes or enhancements is a fool's hope.

E.g., my system is entirely object *based* despite not
being written in an OO language (think about the difference).
It makes sense for a developer (or user) to think of verbs
and nouns -- OPEN the GARAGE DOOR.

In a procedural language, you would have a plethora of
"routines" cluttering up the namespace: open_garage_door(),
close_garage_door(), open_front_door(), open_side_door(),
open_car_door(), open_access_panel_to_furnace(), etc.

They would all share some common characteristics -- yet,
each would have to REMEMBER to include those in its
implementation. (e.g., do you have to UNLOCK the door
before you can open it? Even if this only applies to
SOME doors, having it present in a base class reminds
you that you have to address that -- instead of waiting
for the issue to manifest as a bug!)

In my world, I can "move" an object to a different
"backing server" (the active piece of code that handles
requests to operate on objects of a particular type).
Or, even to a different backing server on another
processor elsewhere in the network (and, moving the
server -- which, of course, is also an object! -- there
to be waiting for the object to arrive!)

I.e., there are verbs (methods) that apply to all objects.
Defining the system as object based reminds me that I have to
address each of these verbs for EVERY object type.

It also makes it easier for me to address OPENing *any*
door, regardless of the actual "type" of door -- because
anything that derives from "Door" has an "open" method.
I don't have to say:

case (door_type) {
GARAGE => open_garage_door();
HOUSE => open_front_door();
FURNACE => open_access_panel_to_furnace();
...
}

[What happens when there's a new door type that THIS code
doesn't explicitly recognize?? DOGGIE => open_doggie_door()]

> Now I program in Python. I really don't know how to program
> in Python. I'm googlesmart. I google what I want to do,
> download the appropriate library and follow the documentation.

Thats part of the bloat problem (and the decline of software
quality, in general). It's *programming* not software engineering.
ANYONE can program... all you have to do is throw keystrokes at
it until it APPEARS to work! You don't need to understand
the hardware, the operating system, the libraries, etc.

Another part of the problem is fat interfaces; too many BUILT ways
to solve the same problem. And, nothing that enforces your choice
of solutions. The fact that these "mechanisms" are so poorly
characterized means you are free to IMAGINE how it will work IN
YOUR CASE instead of having a contract that you can both rely on
("you will use me in this way and I will provide this result").

Imagine semiconductors being as loosely characterized: a diode
allows for current to flow one way (how MUCH current? what is the
drop across the junction? how much power can the packaged device
dissipate? at what reverse voltage will it breakdown?).

How is this code supposed to work:
memcpy(LAST_LOGICAL_MEMORY_ADDRESS-VALUE, some_address, VALUE+7)
Or this?
memcpy(some_address, LAST_LOGICAL_MEMORY_ADDRESS-VALUE, VALUE+7)

How *will* it work on a 68K? 80386? ARMv8?

On bare metal? Under a toy OS? Under a "real" OS?

Operator overloading is a HUGE win, esp for arithmetic operators.
I can say:
temp = A.x * (B.y - C.y)
+ B.x * (C.y - A.y)
+ C.x * (A.y - B.y);
area = temp/2;
and:
- have a greater chance of getting it right
- have a greater chance of The Next Guy recognizing what I've done!
when all of those operators have been properly overloaded for:
Point A,B,C;
data -- which, today, I may have decided have components that are
Q24.8 but, tomorrow, I may decide should be Q40.24!

And, instead of just delaring A, B and C as simple structs made of
integers, a constructor for each must be (silently) invoked... in
case there are any niggling details involved.

[did you miss the implied casts to "temp" and "area"'s respective
data types? What if I want to change those types? how much of
THIS code will change???]

Imagine coding that in a procedural language and The Poor Bloke
who has to read what you've written!

coord_size_t t1 = coordinate_sub(B.y, C.y);
coord_size_t t2 = coordinate_mul(A.x, t1);
...

But, there are costs to this, imposed by the language. I run
similar operations MILLIONS of times each second in my gesture
recognizer... overhead has a cost! :<

> I don't know if there is something malicious in there. That's
> why I really hate every little stupid program and app that
> thinks it needs to auto-update and needs admin approval to
> install and screw with the operating system. If there is
> a portable option, I get that and I keep old versions until
> they break.

Portable just bundles the dependencies into the executable.
So, you end up with larger binaries -- that *can't* be
upgraded (someone has to build you a new portable version
with whichever dependencies -- or application -- updated).

Much of the reason for "bloat" can be attributed to (imagined?)
user demands. The Microsoft Mentality has users looking for
something to click on when they are performing a task.
E.g., spell check a document (no, it must do this WHILE they
are typing cuz they LOVE being distracted by decorated text
alerting them to the POSSIBILITY of a misspelling!).

The UNIX Mentality had smarter users who knew how to plumb
applications together to get a desired result.

E.g., to look for duplicate files on a machine, you
could recursively parse the hierarchy (or the portion of
interest) with "find <hierarchy> -name * -print" -- to
ignore all of the ".<whatever>" files. And, while
doing so, compute the MD5 hash of the file. Storing
these as (pathname, hash) in a "flat database" (i.e., FILE!),
you could then sort | uniq and get a list of duplicates.

In the Microsoft world, you need an app -- with its own
GUI! -- to do this.

Much, also, is a result of programmers being unable to
grasp (grok) all of an application's detail. So, they
may implement the same functionality many different
times (ways?) to address the same problem in different
places. Why do Windows apps all report the sizes of
files differently? Why is a "0 byte" file shown as "1K"?
Is that MB or MiB? (and why do you have to keep explaining
it to people?)

Try unpacking a deep file hierarchy from an archive
to a point deep in the windows filesystem. Why can't
it create:
/some/deep/point/in/the/windows/file/system/archive/with/a/long/path?
Yet, I can unpack the archive to C:\ and then *move* it to that
point in the filesystem!

If a program surprises the user with its behavior, is that
a bug?

In embedded devices, much bloat is due to folks overprovisioning
their solutions: "Let's use Linux!" Really? That's like
taking a drive to the beach in the "semi" tractor trailer (lorry)!

[Any idea how many lines of code -- i.e., latent bugs -- that
"component" brings into your design? Do you ANNUALLY send a
salary-scale contribution to the community that you are hoping
will fix problems that your customers uncover?? Or, are you
just a leach?]

Then, to justify the bloat that they've just built into their
product, they create reasons to use the extra features that
it makes available!

On 2/11/2024 10:47 AM, Wanderer wrote:
> Back in the 20th century, I knew how to program in C. I
> knew what the assembly code would like after I compiled it.
>
> This is C++.
>
> https://en.cppreference.com/w/cpp/links/libs

You can also look at different "strains" of C++
(e.g., EC++) to avoid some of the cruft/overhead

[And, there are other OO languages that have
friendlier characteristics]

On Sun, 11 Feb 2024 13:56:36 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 2/11/2024 10:47 AM, Wanderer wrote:
>> Back in the 20th century, I knew how to program in C. I
>> knew what the assembly code would like after I compiled it.
>>
>> This is C++.
>>
>> https://en.cppreference.com/w/cpp/links/libs
>
>You can also look at different "strains" of C++
>(e.g., EC++) to avoid some of the cruft/overhead
>
>[And, there are other OO languages that have
>friendlier characteristics]

https://en.wikipedia.org/wiki/List_of_programming_languages

Applications are boring. It's much more fun to invent programming
languages.

What's telling is that new programming languages are popular and older
ones aren't.

https://stackoverflow.blog/2017/10/31/disliked-programming-languages/

In other words, programming languages are fads.

On 2/11/2024 1:43 PM, Don Y wrote:
> How is this code supposed to work:
>     memcpy(LAST_LOGICAL_MEMORY_ADDRESS-VALUE, some_address, VALUE+7)
> Or this?
>     memcpy(some_address, LAST_LOGICAL_MEMORY_ADDRESS-VALUE, VALUE+7)
>
> How *will* it work on a 68K?  80386?  ARMv8?
>
> On bare metal?  Under a toy OS?  Under a "real" OS?

This is actually a delightful example of how poorly characterized
software components are (and why you should have your own sources
for everything that you use in a design!).

Taking just the first memcpy(3c) example...

*ASSUME*[1] that data is copied at "from" to "to" in ascending
sequential order, starting at "from". Eventually, "to" will
hit the LAST_LOGICAL_MEMORY_ADDRESS. Then, *pass* it. Will
this wrap around to "0x0"?

What if the LAST_LOGICAL_MEMORY_ADDRESS isn't the largest
representable as an integer? E.g., a device that has a limit
on "code space" that is smaller than the total address space?

What if "to" is "from+1"? E.g., will ABCDEFGHIJ end up
as AABCDEFGHIJ? Or, AAAAAAAAAA? Or, ABCDABCDAB? Or...

What if "to" is "from"? Will *any* reads (or writes) be
performed?

What if you naively use this to initialize a (memory-mapped)
I/O device? Will the "registers" in the device be accessed
in ascending, sequential order? Or, could they be
accessed in the order B A D C E F H J I? Is there anything
that ensures a location is only updated *exactly* once?
Is A A A A A A A A A A A A B C D E F G H I J possible?

What if the OS SIGSEGV's (as expected)? How much of this
"work" will have been done? Can you just abort the balance
of the operation on the assumption that "the first part"
did what you wanted it to do??

Defend each answer! :> Now, pick a different library
implementation or a different processor and make the same
claims... (and that's a trivial STANDARD LIBRARY function!)

-----------
[1] there are no guarantees that this assumption is correct
or any BETTER than any of the others that follow!

On Monday, February 12, 2024 at 4:56:36 AM UTC+11, Cursitor Doom wrote:
> On Sun, 11 Feb 2024 11:26:15 GMT, Jan Panteltje <al...@comet.invalid>
> wrote:
>
> >On a sunny day (Sun, 11 Feb 2024 09:44:22 +0000) it happened Cursitor Doom
> ><c...@notformail.com> wrote in <nh5hsit657809ebhc...@4ax.com>:
> >
> >>On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje <al...@comet.invalid>
> >>wrote:
> >>
> >>>On a sunny day (Sat, 10 Feb 2024 09:06:03 -0800) it happened John Larkin
> >>><j...@997PotHill.com> wrote in <g4bfsidsbmg316tog...@4ax.com>:
> >>>
> >>>>On Sat, 10 Feb 2024 08:10:13 -0800 (PST), Fred Bloggs
> >>>><bloggs.fred...@gmail.com> wrote:
> >>>>
> >>>>>Another failure of 'let the market decide.'
> >>>>>
> >>>>>https://spectrum.ieee.org/lean-software-development
> >>>>
> >>>>Complexity is a game that some people enjoy.
> >>>>
> >>>>And some people like simplicity. Their stuff works better.
> >>>
> >>>It is cool coding in asm without using external libraries.
> >>>I can do anything I like in KILOBYTES:
> >>> https://panteltje.nl/panteltje/pic/scope_pic/index.html
> >>>nice to do Fourier transform in a few bytes... sine lookup table
> >>>has a Usenet compatible output, use fixed size font:
> >>> https://panteltje.nl/panteltje/pic/scope_pic/screen_dump2.txt
> >>>
> >>>Most web things I have coded in a few lines of C,
> >>>started on a browser too, but that is a moving target.. takes too much time.
> >>>Also wrote this Newsreader I am posting this with, it runs on a Raspberry Pi4
> >>>raspberrypi: ~ # whereis NewsFleX
> >>>NewsFleX: /usr/local/bin/NewsFleX
> >>>raspberrypi: ~ # lb /usr/local/bin/NewsFleX
> >>>-rwxr-xr-x 1 root root 383796 Mar 13 2023 /usr/local/bin/NewsFleX*
> >>>
> >>>lb is short for ls -rtl --color=none
> >>>383796 Mar 13 2023 /usr/local/bin/NewsFleX*
> >>>
> >>>'lb' is short for ls -rtl --color=none
> >>>383,796 bytes
> >>>So < 400 kB
> >>>Linked in is libforms for the GUI.
> >>>Old verion for x86 here:
> >>> https://panteltje.nl/panteltje/newsflex/index.html
> >>>libforms however changed, so unless you use a very old verion of that it won't work.
> >>>
> >>>I have dropped that xforms lib too and still have a GUI...
> >>> https://panteltje.nl/pub/boats_and_planes.gif
> >>>runs 24/7
> >>> -rwxr-xr-x 1 root root 329604 Feb 7 2021 xgpspc
> >>>329,604 bytes
> >>>monitors planes and boat traffic, does navighation, auto-pilot what not.
> >>>latest version even has a fire solution.. for defence of course
> >>>Only uses these libs, from the Makefile:
> >>> $(COMPILER) -o xgpspc $(XGPSPC) -lm -lpthread -lXaw -ljpeg
> >>>libmath, libjpeg and libXaw (for the display).
> >>>
> >>>Simplicity, or simple city or whatever it was
> >>>of course gcc as compiler.
> >>>Or gpasm for the PIC asm code.
> >>>
> >>>I think the ever more bloat comes from trying to sell ever more,
> >>>a capitalist trick to suck you for money.
> >>>More bloat causes need for ever more powerfull hardware.
> >>>So bloat writers get shares in hardware manufacurers and get rich.
> >>>Microsore or whatever is a big example.
> >>
> >>That's all very impressive, Jan, but if you were *truly* a hardcore
> >>programmer, you'd be using machine code. ;-)
> >
> >I have used machine code in the long ago past.
> >Here is a nice Z80 disassembler I wrote:
> > https://panteltje.nl/panteltje/z80/index.html
> >from emails I know people still use it.
> >
> >
> >>More seriously, bloat enables coders to hide back doors much more
> >>effectively. They'd never get away with that kind of subterfuge with
> >>ASM.
> >
> >Yes, all those libraries.. I follow the news and sometimes things are loaded
> >that have backdoors.
> >
> >But asm, long ago I was involved with card hacking,
> >things are read only, and how to list the code of a PIC micro
> >(in those days in the TV smart cards for encrypted TV channels).
> >That is how I got interested and came to use Microchip PICs..
> >It is not always easy to list those codes to get the secret algo they use to
> >encrypt TV transmissions.
> >I stopped when some EU politician got upset.. some persisted and got sentenced....
> >But that is how I learned about PICs and got interested in crypto.
>
> Many thanks for that well thought-out and well-reasoned response, Jan.

It' s not all that well-thought-out. That isn't Jan's strong point - or Cursitor Doom's either.

> Nice to hear from someone who knows what they're talking about instead
> of some half-baked garbage from a moron like Bill Sloman who wouldn't
> even be able to set up something as elementary as an Antikythera
> orrery. ;-)

There's nothing elementary about the Antikythera orrery - which is more a calculating engine than an orrery anyway.

https://en.wikipedia.org/wiki/Orrery

https://en.wikipedia.org/wiki/Antikythera_mechanism

The mechanism seems to encode the arc along which the user would have to stand to observe exactly the predicted planetary movements, which is a point that doesn't seem to have made it into the wikipedia write-up.

--
Bill Sloman, Sydney

On 2024-02-11, Don Y wrote:
> [...]
> E.g., my system is entirely object *based* despite not
> being written in an OO language (think about the difference).
> It makes sense for a developer (or user) to think of verbs
> and nouns -- OPEN the GARAGE DOOR.

You open the garage door. It's dark inside.

( sorry, had to :) )

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 2/13/2024 5:00 AM, Dan Purgert wrote:
> On 2024-02-11, Don Y wrote:
>> [...]
>> E.g., my system is entirely object *based* despite not
>> being written in an OO language (think about the difference).
>> It makes sense for a developer (or user) to think of verbs
>> and nouns -- OPEN the GARAGE DOOR.
>
> You open the garage door. It's dark inside.

You cast a spell of continual light -- then, extinguish it
lest your companions ALSO notice the giant spider (Mclaren
765LT) hiding therein!

Slipping inside, you drive off, crushing the Sorceror's foot
in the process. Incensed, he throws a fireball in
your direction but, alas, too slow to catch up with the 750
horses under the hood...
>
> ( sorry, had to :) )
>

In article <uqa8qg$ui04$1@dont-email.me>,
Bill Sloman <bill.sloman@ieee.org> wrote:
>On 11/02/2024 8:44 pm, Cursitor Doom wrote:
>> On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje <alien@comet.invalid> wrote:
>>> On a sunny day (Sat, 10 Feb 2024 09:06:03 -0800) it happened John Larki <jl@997PotHill.com> wrote in
><g4bfsidsbmg316togaaff19e63vv1pnqbo@4ax.com>:
>>>> On Sat, 10 Feb 2024 08:10:13 -0800 (PST), Fred Bloggs <bloggs.fredbloggs.fred@gmail.com> wrote:
>
><snip>
>
>> That's all very impressive, Jan, but if you were *truly* a hardcore
>> programmer, you'd be using machine code. ;-)
>
>Nobody writes machine code. Assembler has a one-to-one relationship with
>machine code, but tit is easier to write and read.

Nobody hu? Smith does. Written a compiler in hex code using only
a hex to bin converter.
https://dacvs.neocities.org/SF/
The take away is, it is easier than you expect.

>
>> More seriously, bloat enables coders to hide back doors much more
>> effectively. They'd never get away with that kind of subterfuge with
>> ASM.
>
>Of course they would. Have your ever tried to make sense of poorly
>documented and commented assembly code?
>
>And it is possible to make machine code self-modifying - at least on
>some machines - which offers even more opportunity, to put in back doors
>(and take then away again after you've exploited them).
You must silence hysteric virus detectors before you could do that.
>
>--
>Bill Sloman, Sydney
>

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

In article <980294@dontemail.com>, Wanderer <dont@emailme.com> wrote:
>On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje wrote:
>
>>It is cool coding in asm without using external libraries.
>>I can do anything I like in KILOBYTES:
>
>
>Back in the 20th century, I knew how to program in C. I
>knew what the assembly code would like after I compiled it.
>
>This is C++.
>
>
>https://en.cppreference.com/w/cpp/links/libs
>
>
>Now I program in Python. I really don't know how to program
>in Python. I'm googlesmart. I google what I want to do,
>download the appropriate library and follow the documentation.
>I don't know if there is something malicious in there. That's
>why I really hate every little stupid program and app that
>thinks it needs to auto-update and needs admin approval to
>install and screw with the operating system. If there is
>a portable option, I get that and I keep old versions until
>they break.

Totally agree. I'm waiting till one managed to subvert one
of the mainstream browsers with a backdoor via the obligatory
daily updates.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

On Thursday, February 15, 2024 at 12:05:41 AM UTC+11, alb...@spenarnc.xs4all.nl wrote:
> In article <uqa8qg$ui04$1...@dont-email.me>,
> Bill Sloman <bill....@ieee.org> wrote:
> >On 11/02/2024 8:44 pm, Cursitor Doom wrote:
> >> On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje <al...@comet.invalid> wrote:
> >>> On a sunny day (Sat, 10 Feb 2024 09:06:03 -0800) it happened John Larki <j...@997PotHill.com> wrote in
> ><g4bfsidsbmg316tog...@4ax.com>:
> >>>> On Sat, 10 Feb 2024 08:10:13 -0800 (PST), Fred Bloggs <bloggs.fred....@gmail.com> wrote:
> >
> ><snip>
> >
> >> That's all very impressive, Jan, but if you were *truly* a hardcore
> >> programmer, you'd be using machine code. ;-)
> >
> >Nobody writes machine code. Assembler has a one-to-one relationship with
> >machine code, but it is easier to write and read.
>
> Nobody hu? Smith does. Written a compiler in hex code using only
> a hex to bin converter.
> https://dacvs.neocities.org/SF/
> The take away is, it is easier than you expect.

Nobody sane. If you go to the trouble of memorising the hex codes it is obviously possible, but why bother?

> >> More seriously, bloat enables coders to hide back doors much more
> >> effectively. They'd never get away with that kind of subterfuge with
> >> ASM.
> >
> >Of course they would. Have your ever tried to make sense of poorly
> >documented and commented assembly code?
> >
> >And it is possible to make machine code self-modifying - at least on
> >some machines - which offers even more opportunity, to put in back doors
> >(and take then away again after you've exploited them).
> You must silence hysteric virus detectors before you could do that.

Or get around them some other way. When I wrote self-modifying code it was for a PDP-8, and long before the days of virus detectors.

--
Bill Sloman, Sydney

On 2/14/2024 6:05 AM, albert@spenarnc.xs4all.nl wrote:
> Nobody hu? Smith does. Written a compiler in hex code using only
> a hex to bin converter.
> https://dacvs.neocities.org/SF/
> The take away is, it is easier than you expect.

One writes code to be *read*. Just because you CAN do something
doesn't mean you SHOULD do that something. People spend inane
amounts of time arranging dominos... just to knock them over
(what's the point in that?)

A kid I attended school with built his own little computer (pre-CP/M),
wrote a monitor in machine code that he then burned into ROM.
Used that to write an assembler. Then an OS, etc. Interesting
"hobby" and worthwhile only if your time has no value.

I had a job where we had a cheap, *live* system monitor that would
let us watch variables and patch code while the system was running.
But, the UI was limited to a six digit *numeric* display -- which
means "split octal" (0xFFFF is 377377) instead of hexadecimal -- and
keypad. So, you had to memorize opcodes in octal and convert
all arguments to that prior to use/recognition.

"Walking" (ADDRESS++) through the code required you to recognize
opcodes and recall how many bytes followed before the next opcode
would be encountered. Or *if* it would be encountered (as absolute
and relative jumps/calls could interrupt the sequential flow).

Having that *live* ability to interact with the system was a huge
asset (at a time when ICE was uncommon -- and expensive!) and was
present in every product that we released (so, you could carry a
tiny piece of hardware to a site and interact with the system).
You could twiddle data and code and watch how the system reacted
without having to go back to the development environment and
turn the crank for a "what if".

But, the requirement to "hand disassemble/assemble" was just ridiculous!
(why not the same hardware interface augmented with some code to make
the UX less risky? Why not tied into the symbol table of the
running executable so you KNEW what you were seeing and tweaking?)

Prior to that, I'd written machine code (again in octal) for the Nova.
Data entry via the 16 toggle switches on the front panel. Data
readout via the 16 indicator lamps associated with them.

Again, a convenient capability (when access to an assembler/compiler
wasn't possible in the field... "I need to throw together a little
routine to exercise some particular bit of hardware so I can
'scope the hardware) but annoyingly complex and not a very portable
skillset.

On Wed, 14 Feb 2024 11:09:15 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 2/14/2024 6:05 AM, albert@spenarnc.xs4all.nl wrote:
>> Nobody hu? Smith does. Written a compiler in hex code using only
>> a hex to bin converter.
>> https://dacvs.neocities.org/SF/
>> The take away is, it is easier than you expect.
>
>One writes code to be *read*. Just because you CAN do something
>doesn't mean you SHOULD do that something. People spend inane
>amounts of time arranging dominos... just to knock them over
>(what's the point in that?)
>
>A kid I attended school with built his own little computer (pre-CP/M),
>wrote a monitor in machine code that he then burned into ROM.
>Used that to write an assembler. Then an OS, etc. Interesting
>"hobby" and worthwhile only if your time has no value.
>
>I had a job where we had a cheap, *live* system monitor that would
>let us watch variables and patch code while the system was running.
>But, the UI was limited to a six digit *numeric* display -- which
>means "split octal" (0xFFFF is 377377) instead of hexadecimal -- and
>keypad. So, you had to memorize opcodes in octal and convert
>all arguments to that prior to use/recognition.
>
>"Walking" (ADDRESS++) through the code required you to recognize
>opcodes and recall how many bytes followed before the next opcode
>would be encountered. Or *if* it would be encountered (as absolute
>and relative jumps/calls could interrupt the sequential flow).
>
>Having that *live* ability to interact with the system was a huge
>asset (at a time when ICE was uncommon -- and expensive!) and was
>present in every product that we released (so, you could carry a
>tiny piece of hardware to a site and interact with the system).
>You could twiddle data and code and watch how the system reacted
>without having to go back to the development environment and
>turn the crank for a "what if".
>
>But, the requirement to "hand disassemble/assemble" was just ridiculous!
>(why not the same hardware interface augmented with some code to make
>the UX less risky? Why not tied into the symbol table of the
>running executable so you KNEW what you were seeing and tweaking?)
>
>Prior to that, I'd written machine code (again in octal) for the Nova.
>Data entry via the 16 toggle switches on the front panel. Data
>readout via the 16 indicator lamps associated with them.
>
>Again, a convenient capability (when access to an assembler/compiler
>wasn't possible in the field... "I need to throw together a little
>routine to exercise some particular bit of hardware so I can
>'scope the hardware) but annoyingly complex and not a very portable
>skillset.

I write in machine code sometimes when it's the best approach. On the
comp.lang.c newsgroup, we've had a *lot* of entries for the
'obfuscated C contest' over the years and a sub-set of us decided it
would be a hoot to have an obfuscated machine code contest as well.
Personally I found it really, really enjoyable (I was in the minority
as we never had another one, though).

On Tue, 13 Feb 2024 12:00:59 -0000 (UTC), Dan Purgert <dan@djph.net>
wrote:

>On 2024-02-11, Don Y wrote:
>> [...]
>> E.g., my system is entirely object *based* despite not
>> being written in an OO language (think about the difference).
>> It makes sense for a developer (or user) to think of verbs
>> and nouns -- OPEN the GARAGE DOOR.
>
>You open the garage door. It's dark inside.
>
>
>( sorry, had to :) )

In German they would say "can you the garage door open make?"

Kind of makes more sense to a computer (or that gnome in the Star Wars
films).

On 2/14/2024 11:28 AM, Dan Green wrote:
>> Again, a convenient capability (when access to an assembler/compiler
>> wasn't possible in the field... "I need to throw together a little
>> routine to exercise some particular bit of hardware so I can
>> 'scope the hardware) but annoyingly complex and not a very portable
>> skillset.
>
> I write in machine code sometimes when it's the best approach. On the
> comp.lang.c newsgroup, we've had a *lot* of entries for the
> 'obfuscated C contest' over the years and a sub-set of us decided it
> would be a hoot to have an obfuscated machine code contest as well.
> Personally I found it really, really enjoyable (I was in the minority
> as we never had another one, though).

Core Wars, anyone? :>

But, nowadays, you are -- most often -- interfacing to a system that
was written in a HLL. So, knowing where you are in the algorithm isn't
as easily discerned as the compiler could have moved code around, elided
things it thought superfluous, etc. If your goal is to get productive
work done, you'd likely want more assurances that your code would
be doing what you intended (and, sooner or later, you're going to
have to "write it for real").

The boot ROM (bipolar) on the Reading Machine was, IIRC, just sixteen
16-bit words. So, you didn't have the luxury of being able to
write what you *wanted* but, instead, had to settle for what would
*fit*. E.g., I think the software loaded to some random address
and then immediately copied itself to the correct address. The
"random address" happened to be the opcode for one of the other
instructions in the ROM.

In my early designs, we relied heavily on self-modifying code to
provide features at low cost. E.g., to disable a task, you
would change the opcode of the CALL to that task to another
"benign" opcode for another 3-byte instruction (cuz CALL was a
3-byte instruction). This allowed you to preserve the entry
point to the task (the target of the CALL) while disabling
its execution (by converting the instruction to something
that effectively ignored the "address" argument)

When I worked on i4004's, we each found utility in carrying
a cheat sheet of opcodes in our wallets -- a "pocket assembler".
The development tools were slow and klunky (and only one set
shared among us all!) so it was effective to patch binary images,
if you could fit your change into the space you're overwriting.

This was an efficient use of time when your access to the
"real" tools was limited to one or two turns of the crank
in an 8 hour day! While a colleague had *his* turn, you
could load the image from whichever 1702 was to be modified
into the programmer and manually patch the bytes. Then, write
the new image into a new 1702, plug it into the prototype
and see how your proposed change would perform. Then, mark up
the (ASM) listing to incorporate a cleaner patch next time
you had access to the development system.

Nowadays, everyone effectively has access to BETTER tools,
simulators, etc. so dealing with real hardware is more of
a nuisance...