Thinking out loud...what is wrong with this world?

Mickster · 2021-11-25 00:13

I am typing perfectly legible FlexBasic code and it simply works and is readable...I look at code that is written in other languages and it is just effed-up!!!!

Why do we do this?

I became self-employed in 1986, thanks to QuickBasic and have only kicked butt ever since.

BASIC has interpreters AND compilers... Does any other language?

Wuerfel_21 · 2021-11-25 00:52

When I read any BASIC code, it just comes off as verbose and clunky

Then again, Spin and C aren't great either.

My favorite language in terms of the language itself is Ruby. It is crazy expressive. Not really microcontroller suitable though....
For example, reading a file of key = value pairs into a hash table, ignoring comment and invalid lines:

def file_to_hash(filename)
  File.readlines(filename).reject{|s|s=~/$#/}.map{|s|s.match(/(\w+)\s*=\s*(\w+)/)&.captures}.compact.to_h
end

Yep, one line.

Little-endian · 2021-11-25 01:07

I've programmed in so many different languages over the years I've learned to just accept them for what they are.

evanh · 2021-11-25 03:37

@Wuerfel_21 said:
Yep, one line.

Sometimes I like to see the underlying sources ... and less cryptic parameters. I've never looked but do wonder how much of Ruby is written in Ruby?

I did a little Bash coding a while back and although it was effective for the purpose, it was also easily forgotten how it worked. Just too cryptic. Bash, and its many extended features, will be entirely written in C I suspect.

Not a real language if it's not self-built from a few small primitives. :P

rogloh · 2021-11-25 03:56

LOL @Wuerfel_21 by not using C (my personal fave) you are not being green. Ruby is around 70 times less energy efficient in some code according to this paper linked here (and Python is worse):

https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/

Ideally they should also somehow account for all the energy it takes to develop/debug/maintain the code in a language that is hard to follow and all too easy to introduce hard to find bugs.

It's strange to think about how much energy would actually be wasted running inefficient/bloated code on all the world's CPUs these days. Might well be the vast majority of the total energy used for computing.

evanh · 2021-11-25 04:08

Lol, and Forth is just weird. It's both interpreted and self-built. It looks like machine code.

Scroungre · 2021-11-25 04:29

Gotta lurv assembler. It does EXACTLY what it says - nothing less, nothing more. What more could you ask for a language? There is no 'interpretation'. There is no 'compiling'. It rocks... S.

pik33 · 2021-11-25 07:03

I started programming long time ago, in Basic, on 8-bit Atari.
Then I learned 6502 asm
Then, at the university, they teached Fortran. On a big mainframe, using Georgre3 OS and perforated cards... and at the same time, on the same university mainframe, I learned Pascal.
Later I learned c,c++, Perl,etc... and, several years ago, Spin, for P1

The result is: I still use Pascal today. Everywhere, except P1/P2 where there is no Pascal... This: https://www.lazarus-ide.org/ - is free/LGPL, works on everything, win, lin, Rpi with and without OS, ( RPi without OS: https://ultibo.org/ ), mac, amiga... No Propeller support (yet)...
Spin is similar enough so I use Spin. And PASM. Spin lacks goto , has strange operators, beware.... If x<-1 doesn't work as in Pascal... and there is PITA with indenting... The rest is fine
Modern Basics are not Basics. They have no line numbers
And you cannot do

100 goto 500+10*i

evanh · 2021-11-25 07:34

@pik33 said:
Modern Basics are not Basics. They have no line numbers

So true. Functions are an easy enough fit but they are completely not a Basic thing originally.

RossH · 2021-11-25 09:08

@pik33

The result is: I still use Pascal today. Everywhere, except P1/P2 where there is no Pascal...

Catalina has a self-hosted ISO-compliant Pascal development system on both the P1 (you need a P1 with XMM RAM and an SD Card) and on the P2 (you need an SD card).

Check out Catalyst and its demo programs - the Pascal development system is one of the demos.
_
The Pascal compiler is in demos\catalyst\pascal

You can edit sources on the Propeller using the vi text editor - see demos\catalyst\xvi

To build Catalyst and all the demos, use the build_all script in demos\catalyst. See the README.TXT file in that folder.

Ross.

Christof Eb. · 2021-11-25 09:20

@evanh said:
Lol, and Forth is just weird. It's both interpreted and self-built. It looks like machine code.

You forgot to say, that it is compiled also and most important: FUN. :-)
(In my personal view, a lot of the weirdness comes from squeezing source code into the very limited historic forth screens with only 15 lines of code. Partly they had the comments on different screens. And from the historical missing local variables.)

Christof Eb. · 2021-11-25 09:28

@rogloh said:
LOL @Wuerfel_21 by not using C (my personal fave) you are not being green. Ruby is around 70 times less energy efficient in some code according to this paper linked here (and Python is worse):

https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/

Ideally they should also somehow account for all the energy it takes to develop/debug/maintain the code in a language that is hard to follow and all too easy to introduce hard to find bugs.

It's strange to think about how much energy would actually be wasted running inefficient/bloated code on all the world's CPUs these days. Might well be the vast majority of the total energy used for computing.

Yes, it is very strange, that education has this focus on Python and at the same time everyone is speaking about energy consumption and CO2....

yeti · 2021-11-25 09:58

Sometimes the weird ones even are fun, at least as puzzle for long winter nights.

I started coding in the 70s by playing assembler on paper and typing in the resulting hex codes via a debugger keyboard. Since then I used and forgot lots of languages and the ones that let me smell the metal thru the code I type are my favourites. Too many layers between my code and the CPU are just scary.

I'm ok when today some call C "universal assembler" and not "high level language".

And sure, sometimes nothing can beat a quick and dirty throw away one-liner in AWK.

Diversity rocks!

Just use what fits the job...

evanh · 2021-11-25 12:13

@pik33 said:
... This: https://www.lazarus-ide.org/ - is free/LGPL, works on everything, ...

Lindsay should swap out Delphi for Lazarus for the Prop Tool sources.

ersmith · 2021-11-25 12:17

@pik33 said:
Modern Basics are not Basics. They have no line numbers

Enter the program below into a FlexProp window, save it as "test.bas", and then run it. Observe the output .

10 gosub 400
20 goto 10

400 print "FlexBasic does support line numbers!"
410 return

And you cannot do

100 goto 500+10*i

Fair enough, although you can do 100 on i goto 510, 520, 530, 540

As for Pascal: the language itself is close enough to Spin, BASIC, and C that I could certainly add it to FlexProp. I'm just not sure how many people would use it, and whether it would be worth the support cost.

Mickster · 2021-11-25 13:43

@ersmith

You deserve fame and fortune for FlexProp, Eric

How the heck to get the word out? Time-to-market is going to be relatively rapid for my project and could be for a heck of lot others, currently battling with ARM and such like.

pik33 · 2021-11-25 14:10

@ersmith said:

@pik33 said:
Modern Basics are not Basics. They have no line numbers

Enter the program below into a FlexProp window, save it as "test.bas", and then run it. Observe the output .
10 gosub 400
20 goto 10

400 print "FlexBasic does support line numbers!"
410 return
And you cannot do

100 goto 500+10*i

Fair enough, although you can do 100 on i goto 510, 520, 530, 540

As for Pascal: the language itself is close enough to Spin, BASIC, and C that I could certainly add it to FlexProp. I'm just not sure how many people would use it, and whether it would be worth the support cost.

Good So the FlexBasic is worth to try. I have now about 3500 lines of Spin code... too many for Spin, but now there is too late to rewrite it, I can only clean it up.

There are C preprocessor macros available that translate Pascal code to C

JRoark · 2021-11-25 14:39

@Mickster said:
@ersmith You deserve fame and fortune for FlexProp, Eric

Here here! And maybe a digital knighthood too!

How the heck to get the word out?

You’re doing it already. Support Eric (Patreon, yo!) and keep whupping azz in the marketplace while the ARM guys are wondering how you do it. So make a mint, retire on an island somewhere, and then let it be known all that code was in BASIC. 🤣

Mickster · 2021-11-25 15:21

@JRoark said:

Support Eric (Patreon, yo!)

Went the PayPal route. I intend to regard FlexProp as a paid-for add-on for each Prop that I purchase

Wuerfel_21 · 2021-11-25 16:12

@evanh said:

@Wuerfel_21 said:
Yep, one line.

Sometimes I like to see the underlying sources ... and less cryptic parameters. I've never looked but do wonder how much of Ruby is written in Ruby?

Ruby documentation generally has a "view source" button for all methods.

CRuby (= the "official" ruby interpreter) implements pretty much all the core stuff in C, but more because it's faster than because it is necessary.
For example, CRuby's implementation of Integer#times in C (oddly written C at that, why is the non-fixnum case not using a while loop???):

static VALUE
int_dotimes(VALUE num)
{
    RETURN_SIZED_ENUMERATOR(num, 0, 0, int_dotimes_size);

    if (FIXNUM_P(num)) {
        long i, end;

        end = FIX2LONG(num);
        for (i=0; i<end; i++) {
            rb_yield_1(LONG2FIX(i));
        }
    }
    else {
        VALUE i = INT2FIX(0);

        for (;;) {
            if (!RTEST(rb_funcall(i, '<', 1, num))) break;
            rb_yield(i);
            i = rb_funcall(i, '+', 1, INT2FIX(1));
        }
    }
    return num;
}

vs. TruffleRuby's in Ruby itself:

  def times
    return to_enum(:times) { self } unless block_given?

    i = 0
    while i < self
      yield i
      i += 1
    end
    self
  end

EDIT: Because it perhaps isn't obvious, Integer#times is just a simple counted loop:

4.times do |i|
  puts i
end

prints

@rogloh said:
Ideally they should also somehow account for all the energy it takes to develop/debug/maintain the code in a language that is hard to follow and all too easy to introduce hard to find bugs.

That is kind of the Ruby ethos: Optimize for programmer time first, CPU time second.
That works really well when you're writing something for yourself and maybe a few other people.

It's strange to think about how much energy would actually be wasted running inefficient/bloated code on all the world's CPUs these days. Might well be the vast majority of the total energy used for computing.

Yeah, energy """wasted""" by running inefficient programs probably does exceed the energy that's captial-W Wasted by crypto mining even. Though the latter is easier to eliminate ;p

@ersmith said:
As for Pascal: the language itself is close enough to Spin, BASIC, and C that I could certainly add it to FlexProp. I'm just not sure how many people would use it, and whether it would be worth the support cost.

I've kindof been thinking about what a custom language that exposes all of flexspin's internal features in an elegant way would look like. A "super spin" of sorts. Though I don't think I'm a language designer.

JRoark · 2021-11-25 17:09

@Mickster said:
I intend to regard FlexProp as a paid-for add-on for each Prop that I purchase

That is where I’m at too. I dont view it as a gift (although it is) so much as a tool I’m leasing.

pik33 · 2021-11-26 20:41

@pik33 said:
@ersmith said:

@pik33 said:
Modern Basics are not Basics. They have no line numbers

Enter the program below into a FlexProp window, save it as "test.bas", and then run it. Observe the output .
10 gosub 400
20 goto 10

400 print "FlexBasic does support line numbers!"
410 return
And you cannot do

100 goto 500+10*i

Fair enough, although you can do 100 on i goto 510, 520, 530, 540

As for Pascal: the language itself is close enough to Spin, BASIC, and C that I could certainly add it to FlexProp. I'm just not sure how many people would use it, and whether it would be worth the support cost.
Good So the FlexBasic is worth to try. I have now about 3500 lines of Spin code... too many for Spin, but now there is too late to rewrite it, I can only clean it up.

It seems I will love this Basic

A petition: don't remove/deprecate these classic features

A question: What are these reserved handles #0 and #1? Are they stdin and stdout and connected to the PropPlug? Is print something equivalent of print #0 (or #1?) something? What will happen if close #0?

Mike Green · 2021-11-26 22:34

I've used a lot of programming languages over the years, Fortran, Algol 60, Basic, Pascal, C, PL/I, PL/360, Python, SmallTalk, LISP, Snobol, and at least as many assembly languages including some with nice macro processors. My favorites were Pascal (with some extensions for the IBM 360) and SmallTalk. Pascal would be a nice addition, but it would need some of the extensions found in Delphi and Lazarus ... for handling run-time allocatable arrays (and strings) and procedure/function parameters.

JRoark · 2021-11-26 23:54

@pik33 said:
A question: What are these reserved handles #0 and #1? Are they stdin and stdout and connected to the PropPlug?

Yup! Its the TTY link up the USB chain to the host machine.

What will happen if close #0?

You know, I’ve never even considered this, or tried it, but I’m guessing the universe will explode. I may have to try this! Will report back later.

ersmith · 2021-11-27 15:02

@Wuerfel_21 said:
I've kindof been thinking about what a custom language that exposes all of flexspin's internal features in an elegant way would look like. A "super spin" of sorts. Though I don't think I'm a language designer.

Yes, that would be interesting to have. FlexBasic was intended to expose everything, but it isn't quite there yet. LOOKUP/LOOKDOWN aren't present, nor are SEND/RECV; although the latter two are just special cases of function pointers. The BASIC syntax isn't to everyone's taste, but then I think no syntax ever is .

@pik33 said:
A question: What are these reserved handles #0 and #1? Are they stdin and stdout and connected to the PropPlug? Is print something equivalent of print #0 (or #1?) something? What will happen if close #0?

Yes, they are stdout (#0) and stdin (#1), and PRINT is equivalent to PRINT #0. If you close #0 you'll lose the ability to PRINT with the default handle. Theoretically you could re-open #0 with a custom I/O handler (e.g. from a Spin object using SendRecvDevice) and change how the default PRINT works. That isn't well tested though, so there could be problems with some library code.

ersmith · 2021-11-27 15:08

Note that the default handles are backwards from how Unix (and C) does them. It does look like FlexC has them the "right" way round. I don't remember right now why the BASIC handles are that way, it may be for compatibility with some older BASIC. But maybe I should flip them?

RobertF · 2021-11-27 16:20

@ersmith said:

As for Pascal: the language itself is close enough to Spin, BASIC, and C that I could certainly add it to FlexProp. I'm just not sure how many people would use it, and whether it would be worth the support cost.

I would certainly love to see Pascal added. It appears there are a few other Prop users who feel the same. Enough users to make it worth adding and supporting? That doesn't seem probable but maybe more of us than expected will chime in.

pmrobert · 2021-11-27 16:31

I would certainly use Pascal. It was among the first languages I learned and using it feels like an old pair of comfortable shoes.

Christof Eb. · 2021-11-28 11:05

What I kind of miss in this discussion is: Libraries.
When I write code, my selection of language is very much influenced by the question, if for my task there are libraries, which can be used easily. As the number of P2-users is relatively small, the number of libraries is growing very slowly. How could it made possible to use existing libraries written for other processors?
Is a subset of C++ thinkable, which would open the world of Arduino-libraries, or 95% of them?
Is a subset of (Micro)python thinkable, which would open the world of their libraries? (Certainly without dynamic types, I think....)

The strength of these early PC compilers like qbasic/freebasic or turbopascal/freepascal (and FPC) seems to be, that it is relatively easy to for example plot a single point onto the screen. They provide a "simple" (builtin library) subset of all the nice looking possibilities of windows gui. I think, that the differences between the languages are less important than the libraries.

Ramon · 2021-11-28 13:12

Mickster,

** Perl has interpreter AND compiler ... AND CPAN LIBRARIES. **

Libraries. True, I agree. And this is frustrating.

P1 and OBEX grew mostly with SPIN and PASM objects (for P1). P2 currently cannot re-use almost anything. So we are here, re-inventing everything again (Serial driver, I2C, SPI, ...) for SPIN2/P2ASM on Github.

No effort was ever done to adsorb the C++/Arduino IDE environment into the P1 or P2 (for fun and profit). It seems that this is not going to change.

Is there any 2 or 4 cogs P2 at US $2 or $4 that can attract thousands of new users? That could probably create more and more code and libraries? Not yet. So we (the few dozen P2 users here) have to create the whole universe again (until the new greatest P3).

You have US $49 in your pocket (*) and are asking yourself which new fancy SBC, Raspberry PI, Teensy, ESP32, one of the one thousand different ARM Cortex XX boards are you going to buy to invest time to learn and play ... or you decide to buy a P2.

P8X32A, in 2006, was an eight cog 32-bit MCU, able to interface directly to a VGA/RCA monitor and Keyboard. The P2 is faster, bigger, more power hungry, and could provide new undreamed things that we are yet to discover.

(*) US $49 if your are lucky (you live in Australia or in the US). Expect $149 ($200 after taxes) or more in other countries.

-----------------------------------------------------------------------------------------------------
C, the Standard C Library, and UNIX stream Input-Output.
C++, Arduino IDE/Libraries, Arduino boards (and clones) and their FIXED hardware functions and pinout.
Raspberry PI, Wiring PI and GNU/Linux, and it's FIXED board pinouts.
Perl, CPAN
Python, PIP
-----------------------------------------------------------------------------------------------------
SPIN1/PASM, P1, Obex  !=  SPIN2/P2ASM, P2, Github
-----------------------------------------------------------------------------------------------------

pik33 · 2021-11-28 15:30

Libraries are evil Propeller2 has smart pins instead.

Serial communication, audio, SBUS, HDMI, PWM, all of these can be done in less than 100 lines of Spin/PASM code, so we don't need libraries. We need only a set of functional code snippets to do all these things we need.

I have now a P2 controlled robot. It can move controlled by a drone type remote controller (SBUS)- or autonomically according to the preprogrammed/learned map. It can track walls using ultrasonic sensors, it can stop when it detects an obatacle and say, using speakers, "remove the obstacle, please" and if removed, resume its operation. It can display its status on a 5" HDMI LCD screen.

All of this needed no libraries. I wrote a HDMI driver myself, it took less than 100 longs of PASM, the audio "driver" was <10 lines of Spin code, which I rewrote to about 20 lines of Pasm to have more control on the sample rate, SBUS procedures are here at this forum, I had to modify them a little, these are less than 50 lines of Spin with no PASM at all, PWM is simply a matter of WRPIN, WXPIN and then WYPIN new value if needed.

Thinking out loud...what is wrong with this world?

Comments