Too many programming languages?

[techman-001]

Splendid! 

How does it compare to the other Forths you use? Is it speedy? Is the binary small-ish? How does the .bin size compare to the other ones you've got?

Edit:
I'd want to use the smaller one I can find, because I'm seeing quite a lot of flash cache misses. That slows down my esp32s.

Caveat: I'm a Forth user, not a Forth designer, although I program, I'm not a programmer, I'm a 65 year old electronics technician.

Comparisons.
I can't really compare any two Forths, they're all different. Even the one I use everyday "Mecrisp-Stellaris" has differences between Cortex-M chips, even ones made by the same company due to Flash controller designs, peripheral differences etc.

Speed
It's blindingly fast on this 8 core I7, but then so is Cortex-M Forth running under QEMU.

Binary Size
Atlast on FreeBSD X86: 123072 Bytes, not particularly small.
Picolisp on FreeBSD X86 is 209608 Bytes.
FICL Forth on FreeBSD X86 is 7232 bytes, REALLY TINY. http://ficl.sourceforge.net/
   Ficl is a complete programming language interpreter designed to be embedded into other systems (including firmware based ones) as a command, macro,
and development prototype language.  Ficl stands for "Forth Inspired Command Language".
Mecrisp-Stellaris on 32 bit Cortex-M0 is 16KB, written in Assembly.

General Comments
Documentation: excellent and professionally written
Resources: it has a TON of useful Words for X86 including file operations, maths, geometry etc.
General feel: it feels very well designed and slick, I like it

I have a question or two myself
1. how do you talk to ATlast on a ESP32, I assume you had to write a USART terminal interface ?
2. I assume you use GCC and compile C for the ESP32, then use ATlast  as a debugger for your program ?

[GeorgeOfTheJungle]

Here it is: https://gitlab.com/xk/esp32_pseudo_forth

If you want to telnet or netcat that's not there, it's a later version I haven't uploaded there. This one works over the serial port only. I can try to update it soon-ish if you're interested. Just let me know.

[techman-001]

Here it is: https://gitlab.com/xk/esp32_pseudo_forth

If you want to telnet or netcat that's not there, it's a later version I haven't uploaded there. This one works over the serial port only. I can try to update it soon-ish if you're interested. Just let me know.

That's very kind of you but I won't need it as I'm pretty much only Cortex_M0 for the next decade or so

I do everything via serial and GnuScreen for automated remote source uploads, error detection etc.
 

[GeorgeOfTheJungle]

That's very kind of you but I won't need it as I'm pretty much only Cortex_M0 for the next decade or so

I do everything via serial and GnuScreen for automated remote source uploads, error detection etc.

You ought to play with an esp32 asap... Then you'll routinely do many more nc_s than screen_s...

FICL Forth on FreeBSD X86 is 7232 bytes, REALLY TINY. http://ficl.sourceforge.net/
   Ficl is a complete programming language interpreter designed to be embedded into other systems (including firmware based ones) as a command, macro,
and development prototype language.  Ficl stands for "Forth Inspired Command Language".

I'm going to have to try that one.

[westfw]

Whilst I can't presume to speak for Westfw, I feel it's more likely that he believes that you have poor fact retention because I'm the Forth guy around here, not him.

heh.  Pretty much.   And thank you for the kind words...
I hope that what the original poster gets from all these many pages of discussion is that there are a lot of "languages" that have a significant segment of "haters", but are still useful IN SOME SITUATIONS.Not many things hurt worse than trying to shoe-horn some function into a language where it just doesn't belong, just because it's the language you know (or worse, the language your employer forces you to use.)

[legacy]

or worse, the language your employer forces you to use.

DTB is a sort of *language* to describe nodes in a device tree. I know where it makes sense, but PowerPC SoCs (by AMCC) cannot be listed in any valid motivation, besides I do find DTB as unnecessary extra compressibility (which makes things more prone to fail), hence I do not like it, but I am forced to learn and use it.

[legacy]

I do everything via serial and GnuScreen for automated remote source uploads, error detection etc.

Can you tell me more about this?

[techman-001]

I do everything via serial and GnuScreen for automated remote source uploads, error detection etc.

Can you tell me more about this?

Love to

Traditional Forth uses a serial terminal to interactively command (in real time) and upload source to the MCU. The Forth I use on Cortex-M is a traditional but modern Forth which I use traditionally making use of modern applications.

Forth serial Terminal use has a few variations not limited to my description below because anything is possible with Forth.

1. A terminal such as Minicom, Picocom, even Hyperterm in Windows is used to interactively command in real time and to upload source to the MCU making use of  the ASCII serial upload capability of the terminal or a 'helper' program called by the terminal for uploading.
In these cases the source code comments are read but rejected by the on-mcu Forth compiler and End Of Line delays are inserted by the terminal (where supported) to prevent the on-mcu Forth compiler choking on long or complex source. There is usually no handshaking of any kind to use as a alternative to the EOL delays and speeds are often 9600 Baud so that errors and warnings from the on-mcu Forth compiler can be read by the programmer as they occur.

2. A purpose made terminal with on board smarts and file upload capability such as eforthcom is used instead. This special terminal is made especially to suit Forth, and strips the comments from the source, recognizes errors and colors them and/or stops the upload completely at the error , plus waits for the "OK," return from the on-mcu Forth compiler giving the fastest possible upload speed without EOL delays or traditional hardware handshaking.

3. What I use.
I use gnuscreen in my own IDE (which is designed for the fastest possible speed) to do the following:

a. Interactively command the on-mcu Forth in the gnu screen window.
b. upload source to the mcu when I click my editor 'make button'. It does this by opening a remote connection to gnu screen and uploading commands and source via a Makefile. I do all this from the editor window but I see the upload as it occurs in the gnu screen window ... sort off, because at 460800 baud with hardware handshaking its hard to read anything as it flashes up the screen.
c. all comments are stripped from the source by SED before being uploaded in b. above
d. Any errors from the on-mcu Forth compiler are highlighted in RED in gnu screen using a sub-process involving configurable SED keywords and ANSII escape codes inserted into the RX stream. Warnings are coloured BLUE.
Warnings and errors RING the gnu screen terminal bell as they occur. This is all needed because the uploads are to fast to read.
e. Stop the upload at the error if desired. This can be done with a toggle switch at the development hardware. I don't use this nowadays as color errors and the beep of the terminal bell are all I need. Gnu screen has a long history buffer and I can easily scroll back to look for the colored error after hearing a beep.
f. Suck the entire Dictionary from the MCU in IntelHex and build a complete binary image of everything including user Words from a project. This image can then be flashed to another mcu which is then a 100% clone.

Personally I find traditional Forth such as 1. above far,far,far too slow and I wouldn't blame anyone who tries Forth in this way from thinking it was a load of ancient crap compared to using arm.none.eabi and GDB via SWD on a Cortex-M.

I developed my system until it was faster than arm.none.eabi and GDB via SWD on a Cortex-M using the usual write code, try, fix, repeat development cycle.

Only then was I happy.

My system is far more than just gnu screen above as it involves:
1. a project builder
2. integrated Fossil SCM with webserver
3. integrated configurable CMSIS-SVD memory map and bitfield generator for any STM32 Cortex-M mcu. This means I can easily write Forth code as I have every peripheral memory mapped automatically. I never  have to refer to the documentation for memory locations or register bitfields.Doing this manually is tedious, error prone and incredibly slow. No one should ever have to do this and I'm amazed by Forth people who still do this manually on Cortex-M.

[nigelwright7557]

I am currently working on a MVC website project.
It uses HTML, ASP.NET. .net framework, C#, Razor, ajax, javascript, JSON and jquery.
It took a while to get into transferring data between the different languages.

[tggzzz]

It uses HTML, ASP.NET. .net framework, C#, Razor, ajax, javascript, JSON and jquery.

My condolences.

[Berni]

I am currently working on a MVC website project.
It uses HTML, ASP.NET. .net framework, C#, Razor, ajax, javascript, JSON and jquery.
It took a while to get into transferring data between the different languages.

And this is one of the reasons i don't like web development.

Not only are there a gazillion languages for every single thing, but as time goes on browsers drop support for some technology and introduces new ones. Its all frameworks running on top of frameworks that use a framework trough another framework that runs inside a convoluted interpreter in a browser while having a few unique sets quirks depending on if your browser is Firefox, Chrome or Edge

[tggzzz]

I am currently working on a MVC website project.
It uses HTML, ASP.NET. .net framework, C#, Razor, ajax, javascript, JSON and jquery.
It took a while to get into transferring data between the different languages.

And this is one of the reasons i don't like web development.

Not only are there a gazillion languages for every single thing, but as time goes on browsers drop support for some technology and introduces new ones. Its all frameworks running on top of frameworks that use a framework trough another framework that runs inside a convoluted interpreter in a browser while having a few unique sets quirks depending on if your browser is Firefox, Chrome or Edge

... and all to put a few pixels on a screen, while pretending the screen a paper-like display

I exaggerate, but the layering of frameworks with poor documentation and unclear interactions which obscure fundamental principals is indeed a real issue.

[GeorgeOfTheJungle]

As there's a million ways to do a web, people are doing it in a million different manners. Both server and client side. That's a good thing if you ask me. I like it.

[westfw]

I had a co-worker/friend in college (~1980) whose resume trumpeted that it had used 9 different programs (or something like that) to format/print it.

I wasn't sure that that was a good thing to put in a resume :-)

(OTOH, that was back when most resumes were just typed on an actual typewriter, and programmers were rarer...)

[Berni]

As there's a million ways to do a web, people are doing it in a million different manners. Both server and client side. That's a good thing if you ask me. I like it.

Yeah but just because you can do it differently doesn't automatically mean you should.

A lot of these web technologies are quickly thrown together things that are not extensively tested trough time and history while having often poor documentation. Then making things worse these things are layered on top of each other to the point where the developer has no idea what is actually going on under the hood. Weird nonsense bugs pop from the interaction of all these and the developer "fixes" the bug by mostly just trying random things until it goes away.

If you look at the common languages used for developing classical Windows or Linux applications you see there is a lot less of them and its rare for languages to be layered on top of each other. Sure there are still multiple languages found in some apps such as perhaps a C# app using a DLL written in C++, but it doesn't tend to go to nearly the same extent as web stuff. Also finding bugs tend to be more methodical where you use a debugger to drill down all the way to the memory of a program and see if its doing what it should.

Nothing wrong with reinventing the wheel when there is a reason to do it. But don't reinvent the same 4 spoked aluminum wheel with 9 bolt holes in a star pattern and secure it using Triwing screws because you have a deep religious belief that things that are a multiple of 3 are better despite this making you incompatible with the same 4 spokes aluminium wheels that have a standard 5 hole pattern and hex head bolts that people have been using for many years with great success.

[GeorgeOfTheJungle]

and hex head bolts that people have been using for many years with great success.

That's the thing: nobody has been doing webs (in the same way, with the same "bolts" as you say) for many years with great success, because everything is in permanent flux. No two webs are the same, yet still, it works. There's beauty in that.

[tggzzz]

Nothing wrong with reinventing the wheel when there is a reason to do it.

Merely one infamous example of that was SOAP, which was RPC over HTTP with XML format. Now RPC just about works inside a single organisation with fast reliable intranets and that can control all the machines and processes interconnected with it. Even then it is a real pain to keep going; ask anybody that has dealt with CORBA-based systems!

Unfortunately none of those pre-requisites exist on the web, and it completely ignores the positive features of the web.

That didn't stop those ignorant of the past from unthinkingly jumping onto the SOAP bandwagon, and it took a long time for that fad to decline.

[Berni]

Things don't have to be constantly changing.

A good example of it is E-Mail. You could take a old 286 PC running MS-DOS, install a email client, dialup modem into the internet and read emails that someone sent you from a phone running the latest Android release.

Sure E-Mail did have some tweaks and updates over the many years but its still fundamentally the same thing.

[GeorgeOfTheJungle]

That didn't stop those ignorant of the past from unthinkingly jumping onto the SOAP bandwagon, and it took a long time for that fad to decline.

The utter cluelessness of the W3C is to blame. They were trying to shove down our throats for more than a decade these and many other, complicated, useless, insufferable massive amounts of crap. Thankfully the WHATWG ended with that and most of it rests in peace now.

For example, don't you know that for FOURTEEN years there's been no way to programatically draw a line or paint not even a mere pixel on a web page? That's (the idiocy of) the W3C in action. No wonder people liked Flash!

[tggzzz]

For example, don't you know that for FOURTEEN years there's been no way to programatically draw a line or paint not even a mere pixel on a web page? That's (the idiocy of) the W3C in action. No wonder people liked Flash!

No! A major point of the web and HTML is that the user's browser works out how best it can display the content on the user's device.  Note that there is no "server" in that sentence.

The concept that a web designer can specify individual pixels has lead to some of the worst design and least functional web pages. Consider the web page shown below that I have to contend with frequently:

• what's all that white space down the sides?
• why is there a small viewport in the middle, concealing half the things I need to see?
• why not just give me the information, and let my browser decide how to display it on my wide screen?
• WTF has the web designer defined that I only have X pixels in which to display the info. It isn't a printed page!

Alternatively, have a look at this idiocy, which I could read from the other side of the room...

[GeorgeOfTheJungle]

Things don't have to be constantly changing.

The web gives you an empty virtual machine with an empty screen that's the web page, a low level API (the DOM), a fantastic language that's a chameleon, and there you are free to do whatever you want, however you like. Therefore: chaos. 7.7 billion people in the world => 7.7 billion ways to do it. But it works!

[GeorgeOfTheJungle]

No! A major point of the web and HTML is that the user's browser works out how best it can display the content on the user's device.  Note that there is no "server" in that sentence.

I meant the <canvas> tggzzz. Nothing to do with that! Have you seen the über cool web interface of the Rohde & Schwarz scopes? That's impossible to do without it.

[tggzzz]

No! A major point of the web and HTML is that the user's browser works out how best it can display the content on the user's device.  Note that there is no "server" in that sentence.

I meant the <canvas> tgzzz. Nothing to do with that! Have you seen the über cool web interface of the Rohde & Schwarz scopes? That's impossible to do without it.

No, I haven't seen those but I doubt it is a benefit. Have a look at Digilent Waveforms. And no, I don't want to see a scope display on a cellphone, thank you.

Let's get the basics right before emulating TVs in a small part of the screen

[GeorgeOfTheJungle]

You don't like web apps?

[tggzzz]

You don't like web apps?

I've tried a WiFi scope on an 8" 1920*1024 tablet. Usable in special circumstances (e.g. up a ladder), not as a bench tool.

Q1: what's the USP benefit of a webapp over an app?

Q2: if running in a smartphone, what's the battery life?

Q3: if running in a smartphone, are the GUI controls usable on such a small screen?

Q4: how do you support the display so that it can be used hands free?

And most importantly, is it worth giving shiny new toys to web developer so they can ignorantly cock up finding information on the web in more ways? The latter is a resounding "no".