P1 language thoughts

This discussion was created from comments split from: Now that the P2 - era begins - is there an EOL for P1 planned ?.

Comments

  • Brian FairchildBrian Fairchild Posts: 512
    edited 2019-12-04 - 13:06:39
    VonSzarvas wrote: »
    Many other languages seem to come-and-go with changing fads and generational changes in the community that develops and consumes one language or another.

    Which is why professional developers use C. It's been around for 47 years and shows no sign of going away.
  • (Notice tongue planted firmly in cheek here)

    I’d just point out that BASIC was born on May 1, 1964. So it had already read the first 5 volumes of “Fun With Janet & Mark”, was playing softball, and had already been punished twice for throwing frogs at girls when C first started soiling its nappies. (And I’ll wager that, like the rest of us, it’ll be working long after it hits “retirement age”!). :smiley:
  • JRoark wrote: »
    (Notice tongue planted firmly in cheek here)

    I’d just point out that BASIC was born on May 1, 1964. So it had already read the first 5 volumes of “Fun With Janet & Mark”, was playing softball, and had already been punished twice for throwing frogs at girls when C first started soiling its nappies. (And I’ll wager that, like the rest of us, it’ll be working long after it hits “retirement age”!). :smiley:

    And for completeness, before anyone mentions it, Forth has been around for 49 years.


  • JRoark wrote: »
    (Notice tongue planted firmly in cheek here)

    I’d just point out that BASIC was born on May 1, 1964. So it had already read the first 5 volumes of “Fun With Janet & Mark”, was playing softball, and had already been punished twice for throwing frogs at girls when C first started soiling its nappies. (And I’ll wager that, like the rest of us, it’ll be working long after it hits “retirement age”!). :smiley:

    And for completeness, before anyone mentions it, Forth has been around for 49 years.

    I hope you got over that habit of throwing frogs at girls.

    But now I have to chime in for COBOL, as far as old it beats both, BASIC and C.

    Sadly my only copy of COBOL for CP/M does NOT run on the P1-ZiCog Z80 and @pullmoll disappeared again after surfacing for some posts. @Cluso99 seems to be to busy for porting ZiCog to the P2 and I am still to stupid to write a working emulator - maybe my choices are to far fetched, but currently it seems my IBM/360 emulator does better then the 68000 one.

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • JRoark wrote: »
    (Notice tongue planted firmly in cheek here)

    I’d just point out that BASIC was born on May 1, 1964. So it had already read the first 5 volumes of “Fun With Janet & Mark”, was playing softball, and had already been punished twice for throwing frogs at girls when C first started soiling its nappies. (And I’ll wager that, like the rest of us, it’ll be working long after it hits “retirement age”!). :smiley:
    And there are about a zillion dialects of BASIC all incompatible with each other. At least C has been fairly constant over the years although I'm not sure modern compilers will still accept the old K&R function parameter syntax.

  • David Betz wrote: »
    And there are about a zillion dialects of BASIC all incompatible with each other. At least C has been fairly constant over the years although I'm not sure modern compilers will still accept the old K&R function parameter syntax.

    I think most of them do accept the old syntax. fastspin does (now) although there are probably some edge cases that may give problems.
    FlexGUI, a GUI for programming the P1 and P2 in Spin, PASM, BASIC, and C.
    Help support its development at Patreon or PayPal.
  • The thing about BASIC is that it always seems to provide quick/easy access to new platforms. Look at Micromite...everything, including editor on a $5 chip and there is Annex for the ESP8266. They are about to release the ESP32 version but you have to search the forum to find mention of it.
    Failure is not an option...it's bundled with the software.
  • ersmith wrote: »
    David Betz wrote: »
    And there are about a zillion dialects of BASIC all incompatible with each other. At least C has been fairly constant over the years although I'm not sure modern compilers will still accept the old K&R function parameter syntax.

    I think most of them do accept the old syntax. fastspin does (now) although there are probably some edge cases that may give problems.
    Perhaps but does anyone actually program using the older line-numbered syntax?

  • David Betz wrote: »
    ersmith wrote: »
    David Betz wrote: »
    And there are about a zillion dialects of BASIC all incompatible with each other. At least C has been fairly constant over the years although I'm not sure modern compilers will still accept the old K&R function parameter syntax.

    I think most of them do accept the old syntax. fastspin does (now) although there are probably some edge cases that may give problems.
    Perhaps but does anyone actually program using the older line-numbered syntax?

    Whoops, sorry, I was referring to the modern C compilers accepting old K&R function parameters. I think most of them do, even fastspin. The only one I know of that doesn't is the plan9 C compiler (which is somewhat non-standard anyway).

    As for line numbers in BASIC, yeah, fastspin accepts those, but the docs do suggest avoiding them in new programs. Mainly I wanted to be able to compile some of the old BASIC games of my mis-spent youth. I agree that the zillions of incompatible BASIC dialects are a problem. LISP, unfortunately, suffers from the same issue.
    FlexGUI, a GUI for programming the P1 and P2 in Spin, PASM, BASIC, and C.
    Help support its development at Patreon or PayPal.
  • ersmith wrote: »
    David Betz wrote: »
    ersmith wrote: »
    David Betz wrote: »
    And there are about a zillion dialects of BASIC all incompatible with each other. At least C has been fairly constant over the years although I'm not sure modern compilers will still accept the old K&R function parameter syntax.

    I think most of them do accept the old syntax. fastspin does (now) although there are probably some edge cases that may give problems.
    Perhaps but does anyone actually program using the older line-numbered syntax?

    Whoops, sorry, I was referring to the modern C compilers accepting old K&R function parameters. I think most of them do, even fastspin. The only one I know of that doesn't is the plan9 C compiler (which is somewhat non-standard anyway).

    As for line numbers in BASIC, yeah, fastspin accepts those, but the docs do suggest avoiding them in new programs. Mainly I wanted to be able to compile some of the old BASIC games of my mis-spent youth. I agree that the zillions of incompatible BASIC dialects are a problem. LISP, unfortunately, suffers from the same issue.
    Yup. LISP too. And it seems Spin may join this group as well since the P1 and P2 versions may not be compatible. I'm still hoping they will be though.

  • The reason there were so many dialects of early BASIC is that each one was tailored to the machine on which it ran, so memory and I/O shaped the mix of functions implemented. I expect Spin2 to be fairly compatible with Spin1 by comparison, but here the issue will be the objects used for I/O. Anything remotely creative that was done to improve memory usage, such as methods of reusing PASM image RAM, may have to be reworked. And any but the most basic video drivers are likely to have different resolution and different tile formats for different color schemes, etc.

    It will also be interesting to see how Spin2 compares to FastSpin, which compiles directly to Hub PASM. When I ported the ENC28J60 drivers I didn't need to launch a cog to get near maximum performance of the SPI interface, but I wonder how fast Spin2 will be. And if Spin2 provides a mechanism for reclaiming cog RAM images -- something Spin1 lacked and desperately needed due to the 32K memory limit -- it will obviously be completely different.
  • (-this is some epic thread drift. I think my work here is done!. Hehehe-)
  • Don't even get me started on all of those incompatible assembly languages. ;-)
  • Oh and Forth has already spent time in space wondering what it did wrong to be up there. Basically a dialect based on Forth was created for the purposes of being run in the CDP1802 family members to manage the different OSCAR sats up there.
  • The rapid development advantages of Forth must have been compelling to the OSCAR team because being familiar with the 1802 instruction set, it's hard to imagine a worse starting point for a FORTH inner interpreter.
  • Way back in the mid sixties during my college days, I solved engineering problems using FORTRAN matrix operations and it was really easy to use. After graduation and the availability of the IBM PC, there was a small version of FORTRAN that ran on the PC but I used BASIC configured to handle the same matrices and it worked perfectly. I have been trying to use BASIC ever since.

    Discovery
  • localroger wrote: »
    The rapid development advantages of Forth must have been compelling to the OSCAR team because being familiar with the 1802 instruction set, it's hard to imagine a worse starting point for a FORTH inner interpreter.

    Actually yes according to the folks on the new CDP1802 forums yes.


  • In my opinion the best use of the '{' and '}' is to contain comments in Spin :) To build a language upon these messy characters is just confusing :wink:
    21st century - when everything changes
    "Better with a DAT and a COG than with a CAT and a DOG"
  • David BetzDavid Betz Posts: 13,592
    edited 2019-12-09 - 12:09:53
    Erlend wrote: »
    In my opinion the best use of the '{' and '}' is to contain comments in Spin :) To build a language upon these messy characters is just confusing :wink:
    You're right. Those brace characters are confusing. So are parens. We really should write arithmetic expressions like this. It would be some much clearer!
    begin a plus b end times c
    
    That's so much easier to read than:
    (a + b) * c
    
    :smile:
  • David Betz wrote: »
    Erlend wrote: »
    In my opinion the best use of the '{' and '}' is to contain comments in Spin :) To build a language upon these messy characters is just confusing :wink:
    You're right. Those brace characters are confusing. So are parens. We really should write arithmetic expressions like this. It would be some much clearer!
    begin a plus b end times c
    
    That's so much easier to read than:
    (a + b) * c
    
    :smile:

    You are reinventing COBOL

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • I favor parentheses for expression evaluation since that's what we are all taught in math class and expressions usually don't reach an unreasonable depth. I don't favor using more than one type though, such as mixing square brackets for array indeces. If you need your editor to highlight the matching marker, your language is too obscure.

    And that said, I hate curly brackets for delimiting code blocks. Keywords like end (and preferably typed keywords like end if, rather than just end for everything I'm lookin' at you Lua). Ideally code should also be block-indented, and Spin forces that but I find the absence of closing keywords distracting. If you are using brackets for everything it can become stupidly confusing, especially if a programmer decides to save a little space]))}}}))}).
  • David BetzDavid Betz Posts: 13,592
    edited 2019-12-10 - 03:00:11
    localroger wrote: »
    I favor parentheses for expression evaluation since that's what we are all taught in math class and expressions usually don't reach an unreasonable depth. I don't favor using more than one type though, such as mixing square brackets for array indeces. If you need your editor to highlight the matching marker, your language is too obscure.

    And that said, I hate curly brackets for delimiting code blocks. Keywords like end (and preferably typed keywords like end if, rather than just end for everything I'm lookin' at you Lua). Ideally code should also be block-indented, and Spin forces that but I find the absence of closing keywords distracting. If you are using brackets for everything it can become stupidly confusing, especially if a programmer decides to save a little space]))}}}))}).
    Darn! I forgot that I should have used typed keywords. Make that:
    begin subexpression a plus b end subexpression times c
    
    Much less confusing.

    I'm just being silly here. I have to admit that I've been writing Python a bit lately and am starting to like the "block structure by indentation" feature.

  • David Betz wrote: »
    localroger wrote: »
    I favor parentheses for expression evaluation since that's what we are all taught in math class and expressions usually don't reach an unreasonable depth. I don't favor using more than one type though, such as mixing square brackets for array indeces. If you need your editor to highlight the matching marker, your language is too obscure.

    And that said, I hate curly brackets for delimiting code blocks. Keywords like end (and preferably typed keywords like end if, rather than just end for everything I'm lookin' at you Lua). Ideally code should also be block-indented, and Spin forces that but I find the absence of closing keywords distracting. If you are using brackets for everything it can become stupidly confusing, especially if a programmer decides to save a little space]))}}}))}).
    Darn! I forgot that I should have used typed keywords. Make that:
    begin subexpression a plus b end subexpression times c
    
    Much less confusing.

    I'm just being silly here. I have to admit that I've been writing Python a bit lately and am starting to like the "block structure by indentation" feature.

    Yes I like the indentation in Python too :smiley:
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • In an attempt to get this thread back on track, I'd like to say that in my opinion the most powerful language for the P1 is probably Tachyon Forth. It is absolutely amazing how much Peter squeezed into the relatively tiny memory of the P1!
Sign In or Register to comment.