I have but not for a long time. BASIC (various types), COBOL, PL/1, APL, FOCUS, ACUMEN, FORTRAN, REXX, VBA, Visual Basic mainly.
Non-professionally used languages include PERL, C/C++, PASCAL, LISP and an old favourite FORTH.
Somewhere in-between fall PHP, Python and JavaScript. I've occasionally used them in professional projects but not as a professional developer as such.
I've seen some other simulation software that was graphical. Nice but highly specialised.
Indeed and indeed.
JavaScript makes it accessible to the likes of me and i'm very happy because of that
And indeed it is/was designed like that on purpose. Leaving the function node as a place where users can start to write bits of code to "fill in gaps" is/was intended as way to allow them to dip their toe into javascript programming and then who knows what may happen
I was not so much thinking about the function node as about the node.js infrastructure and the need to code contributed nodes in JavaScript. This has the enormous advantage that JS is second nature to so many web developers. The down side for old goats like me is that JS can be new and strange -- and it just doesn't feel right for solving really complex problems.
Absolutely! Please don't construe by disdain for JS as anything other than the annoyance of having to change ones ways. Having said that, I don't think JS is the answer to everything, but NR is certainly the answer to many things and along with that must go JS.
It might not be the solution you're after but TypeScript really does go along way in helping to facilitate complex projects. I've noticed many contrib nodes are written in TypeScript so "vanilla" JS is not the only option. E.g. GitHub - tbowmo/node-red-contrib-mysensors: Mysensor nodes for node-red
I'm currently involved in a 10 developer project (on its 3rd year) which includes the main React based frontend code written in TypeScript and a cross-platform Android/iOS app built with React Native also in TypeScript. I would consider the code base incredibly difficult and regression prone to work with if we weren't using TypeScript. It has made it possible even for new developers joining later to do big refactorings on the code that would have likely never happened otherwise.
I'm so reluctant to write plain JS these days that at one point I spent a lot of time trying to find a way to hack in TS support also for function nodes but unfortunately didn't get further than managing to add TS syntax highlighting to the embedded ICE code editor... There is a project called ts-node which allows running TS code without a separate compilation step that might help in achieving this though.
I have ported our back-end code at work from plain JS to Typescript without regretting it a bit. Especially I wouldn't want to miss the support that VS Code provides for Typescript projects. I have even found some bugs and edge cases during the porting process that would have gone unnoticed for a while in plains JS.
TS doubtless is good for complex projects if you are a professional developer and are working with it day-in-day-out. Especially if you are working in larger, pro, teams.
However, one of the major advantages of Node-RED is that you don't have to be a developer to make use of it. For those of us who aren't full-time developers, learning - even remembering - JavaScript as our only language is enough of a challenge.
JS has a number of advantages for us not least of which is its flexibility, generally simple syntax and the wealth of Internet support available - tutorials, references, etc.
If we want to gain some of the advantages of TS without being forced to use it, we can us VSCode and JSDoc.
On top of what Julian mentioned, TypeScript isnāt the easiest language to get started with, even after years of programming experience with both static and dynamic typed languages. The official documentation is always lagging behind when an update comes, and some of the new syntax that got introduced over a year ago still hasnāt made it to the actual documentation, unless you consider blog posts about new releases and the changelogs part of the documentation for the language itself. For example, the exclamation mark syntax is similar to how things work in Swift, which is how I understood how to use it in the end. But itās only explained in the changelog.
What I mean to say is that the written documentation itself is not enough to learn the language. Obviously thereās video tutorials and tutorials to get started per frontend framework, but for me such a form of learning does not work. For me itās books and text based documentation, or not at all. Most of why I gave it a chance in the first place was because of Anders Hejlsberg, and Turbo Pascal being my first actual programming language. Except any of my turbo pascal experiments from when I was 12/13 I can still read and understand, and the TS code I wrote back in March is already difficult to read now.
So while TS does indeed give possibilities because of the static typing, itās not always the best solution.
You have probably been asked this many,many times but is there a way to get a copy or info on how you did this? I think your swim lane effort is great and perfect for my situation?
