Shop OBEX P1 Docs P2 Docs Learn Events
P1 language thoughts — Parallax Forums

P1 language thoughts

SystemSystem Posts: 45
in Propeller 1
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: 549
    edited 2019-12-04 13:06
    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.
  • JRoarkJRoark Posts: 1,215
    (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:
  • Brian FairchildBrian Fairchild Posts: 549
    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.


  • msrobotsmsrobots Posts: 3,709
    Brian Fairchild wrote: »
    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
  • David BetzDavid Betz Posts: 14,516
    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.

  • ersmithersmith Posts: 6,052
    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.
  • MicksterMickster Posts: 2,693
    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.
  • David BetzDavid Betz Posts: 14,516
    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?

  • ersmithersmith Posts: 6,052
    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.
  • David BetzDavid Betz Posts: 14,516
    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.

  • localrogerlocalroger Posts: 3,451
    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.
  • JRoarkJRoark Posts: 1,215
    (-this is some epic thread drift. I think my work here is done!. Hehehe-)
  • AJLAJL Posts: 517
    Don't even get me started on all of those incompatible assembly languages. ;-)
  • Buck RogersBuck Rogers Posts: 2,185
    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.
  • localrogerlocalroger Posts: 3,451
    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.
  • DiscoveryDiscovery Posts: 606
    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
  • Buck RogersBuck Rogers Posts: 2,185
    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.


  • ErlendErlend Posts: 612
    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:
  • David BetzDavid Betz Posts: 14,516
    edited 2019-12-09 12:09
    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:
  • msrobotsmsrobots Posts: 3,709
    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
  • localrogerlocalroger Posts: 3,451
    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: 14,516
    edited 2019-12-10 03:00
    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.

  • Cluso99Cluso99 Posts: 18,069
    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:
  • David BetzDavid Betz Posts: 14,516
    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!
  • Heater.Heater. Posts: 21,230
    BASIC or C or Forth or COBOL....?
    Keywords or braces or white space...?
    TABs of spaces...?

    Having been away from the forum for the best part of a year I'm glad to see this debate is still going on.

    This year I have been doing everything in Rust: https://www.rust-lang.org

    I have spent years avoiding all the new languages that spring up like weeds. Preferring to invest my time and effort into language with a recognized standard that are cross platform and likely to be around for the long haul. That pretty much means C, C++ and Javascript.

    So why Rust?

    Rust compiles to native binaries like C. As such it can match C in performance. Rust requires no run time, garbage collector etc, so like C it can be used "bare metal" on micro-controllers and the like. Rust is a much higher level language than C though, but in a much neater way than the mess of complexity that is C++.

    The killer Rust feature though is something I have never seen in any other compiled language, memory safety. In Rust you cannot create memory usage bugs like dereferencing a null pointer, accessing memory after it has been freed, indexing off the end of arrays etc, etc. All this is checked at compile time rather than run time thus ensuring the performance of languages like C.

    Now, did anyone ever create a Propeller back end for Clang/LLVM? If that were so there would be some chance of getting Rust for the Propeller.







  • KMyersKMyers Posts: 433
    Welcome back Heater!
  • Heater.Heater. Posts: 21,230
    Thanks. I'm not sure how "back" I am. There is another busy year coming.
  • potatoheadpotatohead Posts: 10,261
    edited 2019-12-26 19:44
    LOL, make yourself a portable "travel" kit. That's what I've ended up doing.

    Did that years ago with P1. Had composite and RF back then, easy peasy. (for those times I wanted a display, or was working on display code)

    Today, we've got HDMI. After one fail, for lack of a +5V signal, I'm happy to report the next couple trips resulted in hotel room Propping in style!

    The other difference today, is I check my kit. No carry on. People are too spooked by electronics stuff. The last time I took it out on the plane, I got looks. Ended up fine, but I had to turn on the charm.

    I've got a little Pelican case. The stuff gets packed in, ready to rock.

    (assuming you travel to that hardware like you have in the past)

  • Heater.Heater. Posts: 21,230
    Luckily, at least for the next year all our installations will be across town from here.

    No, it's the ton of software we have committed to produce... and that hardware needs spec'ing properly, procuring, assembling etc...

    But get this: When Microsoft acquired Nokia and made thousands of engineers redundant, they put up a pile of money towards helping them find new jobs and create new businesses etc. About 20 million of that got put into a thing called IoTForge. http://iotforge.fi

    Basically a professional maker space that startups can use. It's crammed with every kind of machine tool and electronics test gear. http://iotforge.fi/laboratory. It's a lot of expensive kit that was Nokia's.

    Heavenly. And we get to go down there and use it any time we like 24/7. Which is just as well as we don't even have an office let alone a workshop.


  • DavidZemonDavidZemon Posts: 2,973
    Heater. wrote: »
    BASIC or C or Forth or COBOL....?
    Keywords or braces or white space...?
    TABs of spaces...?

    Having been away from the forum for the best part of a year I'm glad to see this debate is still going on.

    This year I have been doing everything in Rust: https://www.rust-lang.org

    I have spent years avoiding all the new languages that spring up like weeds. Preferring to invest my time and effort into language with a recognized standard that are cross platform and likely to be around for the long haul. That pretty much means C, C++ and Javascript.

    So why Rust?

    Rust compiles to native binaries like C. As such it can match C in performance. Rust requires no run time, garbage collector etc, so like C it can be used "bare metal" on micro-controllers and the like. Rust is a much higher level language than C though, but in a much neater way than the mess of complexity that is C++.

    The killer Rust feature though is something I have never seen in any other compiled language, memory safety. In Rust you cannot create memory usage bugs like dereferencing a null pointer, accessing memory after it has been freed, indexing off the end of arrays etc, etc. All this is checked at compile time rather than run time thus ensuring the performance of languages like C.

    Now, did anyone ever create a Propeller back end for Clang/LLVM? If that were so there would be some chance of getting Rust for the Propeller.

    I'm right there with you.
    And no, no one created an LLVM backend for P1. For P2, I started a conversation on Rust here: http://forums.parallax.com/discussion/170419/rust-on-propeller-2-well-need-llvm-for-that
Sign In or Register to comment.