Old XMOS Board

[tggzzz]

The key advantage is not the hardware (although the io structures are very neat powerful and simple like an FPGA), but is the software and its integration with the hardware.

Yes, outstanding selling points of XMOS are their easy-to-use abstractions of multitasking and fast inter-IC networking.  Hardware is nothing to rave about.

They got massive initial boost by being almost the only company who had half-decent USB Audio 2.0 stack and usable Windows driver available - until Microsoft caught up, 10 years later with own half-working bodge (they still license UAC2.0 driver from Thesycon who wrote it for XMOS.) Similar to FTDI and USB-CDC situation.  I attribute their current market success to this twist of fate. USB Audio does not really need parallel multitasking or transputer network to work.  It was just a bit of good luck.

Notice how XMOS almost abandoned the market that made them - there is no support for USB Audio 3.0 for 4 years running.  They put all their efforts into chasing Alexa-like voice speakers for awhile.  Now it's all about AI.

Leo

It is entirely unsurprising that a small startup creates general purpose technology and then focusses on whoever finds a specific niche for it.

Ditto for pivoting to another area where they feel they could have a significant unique advantage.

It is unclear to me whether they are abandoning the core xC ecosystem, or whether it is still there under a veneer of libraries.

[Leo Bodnar]

It is unclear to me whether they are abandoning the core xC ecosystem, or whether it is still there under a veneer of libraries.

Anecdotally, one of their top brass privately commented that they are committed to keeping xCORE-200 line for the next 10 years but I don't trust anybody in this industry - especially executives.  And 10 years is nothing for a good, successful product.

If you mean xC as in development tool, I fully expect somebody will replace it with an interactive IDE where you drag jelly bean coloured blocks strung together with animated pipes.

Leo

[tggzzz]

It is unclear to me whether they are abandoning the core xC ecosystem, or whether it is still there under a veneer of libraries.

Anecdotally, one of their top brass privately commented that they are committed to keeping xCORE-200 line for the next 10 years but I don't trust anybody in this industry - especially executives.  And 10 years is nothing for a good, successful product.

If you mean xC as in development tool, I fully expect somebody will replace it with an interactive IDE where you drag jelly bean coloured blocks strung together with animated pipes.

Leo

Snort!

Has software by pictures ever been successful? Yes pictures can be OK as a top level block diagram, e.g. FSMs, but for the nitty gritty tests and actions text is normally better.

Yes, people have created drag-and-drool Lego stuff, but then it is used by people that cannot program in any language

[nfmax]

Has software by pictures ever been successful? Yes pictures can be OK as a top level block diagram, e.g. FSMs, but for the nitty gritty tests and actions text is normally better.

Yes, people have created drag-and-drool Lego stuff, but then it is used by people that cannot program in any language

Yes: look at Node-RED (https://nodered.org/) for an example. It doesn't try to do everything (though it can) but the paradigm of messages flowing through pipelines of nodes, each performing a specific operation, is fruitful.

[Berni]

Snort!

Has software by pictures ever been successful? Yes pictures can be OK as a top level block diagram, e.g. FSMs, but for the nitty gritty tests and actions text is normally better.

Yes, people have created drag-and-drool Lego stuff, but then it is used by people that cannot program in any language

Successful graphical programing languages? Yep there are quite a few actually.

For example:
 -LabView: the license costs a few grand per year or a few tens of grand for a permanent license and a lot of people use it (Tho its mostly academic and research type of stuff)
 -Matlabs Simulink: Also very expensive, yet still popular (tho mostly because its free for academic)
 -Shader programing: Every major piece of software dealing with high end graphics has some form of graphical node based shader language, Be it artistic 3D moderling such as Blender or popular game engines such as Unity, UnrealEngine, Godot..etc
 -Animation state machines: Also used in 3D software and game engines for automating animation transitions
 -UnrealEngine Blueprints: Used as the primary way of programing in one of the biggest game engines on the market. Behind the scenes its just getting translated back to C++ (And can use user written C++ functions) but the workflow puts the blueprint workflow in the spotlight as the primary way of doing things.
 -Industrial PLCs: Every PLC vendor out there has a graphical language of some sort. Essentially all of them supporting ladder diagrams, but some also have more data flow based block diagrams.
 -NodeRed: As mentioned above, it is a reasonably well known browser based scripting engine, fits well into the IOT stuff.

I don't always like these graphical programing things, but they are out there and they are indeed popular too.

[tggzzz]

Has software by pictures ever been successful? Yes pictures can be OK as a top level block diagram, e.g. FSMs, but for the nitty gritty tests and actions text is normally better.

Yes, people have created drag-and-drool Lego stuff, but then it is used by people that cannot program in any language

Yes: look at Node-RED (https://nodered.org/) for an example. It doesn't try to do everything (though it can) but the paradigm of messages flowing through pipelines of nodes, each performing a specific operation, is fruitful.

At a very quick look, it looks like it is graphical at the level of FSM languages. It is graphical in terms of top level blocks, but all the useful stuff is done in a range of other text based languages.

I'm not sure how you would do fundamental operations like multiplexing (nodes have only one input) nor iteration.

[tggzzz]

Snort!

Has software by pictures ever been successful? Yes pictures can be OK as a top level block diagram, e.g. FSMs, but for the nitty gritty tests and actions text is normally better.

Yes, people have created drag-and-drool Lego stuff, but then it is used by people that cannot program in any language

Successful graphical programing languages? Yep there are quite a few actually.

For example:
 -LabView: the license costs a few grand per year or a few tens of grand for a permanent license and a lot of people use it (Tho its mostly academic and research type of stuff)
 -Matlabs Simulink: Also very expensive, yet still popular (tho mostly because its free for academic)
 -Shader programing: Every major piece of software dealing with high end graphics has some form of graphical node based shader language, Be it artistic 3D moderling such as Blender or popular game engines such as Unity, UnrealEngine, Godot..etc
 -Animation state machines: Also used in 3D software and game engines for automating animation transitions
 -UnrealEngine Blueprints: Used as the primary way of programing in one of the biggest game engines on the market. Behind the scenes its just getting translated back to C++ (And can use user written C++ functions) but the workflow puts the blueprint workflow in the spotlight as the primary way of doing things.
 -Industrial PLCs: Every PLC vendor out there has a graphical language of some sort. Essentially all of them supporting ladder diagrams, but some also have more data flow based block diagrams.
 -NodeRed: As mentioned above, it is a reasonably well known browser based scripting engine, fits well into the IOT stuff.

I don't always like these graphical programing things, but they are out there and they are indeed popular too.

Is Minecraft a graphical programming language? I've heard it is Turing complete

I had forgotten about PLC ladder logic, never having used them. Can they express unbounded iteration? ISTR there being some unpleasant hacks to sort-of enable advanced concepts like subroutines.

I've used some of the simulation languages, and they are top level block diagrams where the processing is done in C/C++. To me that is syntactic sugar like FSM diagramming languages. Nobody thinks Harel Statecharts are a programming language.

It looks like you are right about LabView. It had changed a lot since I first glanced at it decades ago. I suspect HP's VEE is similar.

I'm completely unfamiliar with gaming environments, and it will stay that way

[Berni]

Is Minecraft a graphical programming language? I've heard it is Turing complete

I had forgotten about PLC ladder logic, never having used them. Can they express unbounded iteration? ISTR there being some unpleasant hacks to sort-of enable advanced concepts like subroutines.

I've used some of the simulation languages, and they are top level block diagrams where the processing is done in C/C++. To me that is syntactic sugar like FSM diagramming languages. Nobody thinks Harel Statecharts are a programming language.

It looks like you are right about LabView. It had changed a lot since I first glanced at it decades ago. I suspect HP's VEE is similar.

I'm completely unfamiliar with gaming environments, and it will stay that way

I never said that these graphical programing languages are actually any good. I hate most of them in at least some way.

None the less they are languages that are sold for prices of a decent used car and/or have user bases counting into the millions. So id argue that they do count as being "successful languages", so apparently there are a lot of people out there that do like them.

Those PLC ladder diagrams are particularly high up my hate list. They have hacky ways of making them do all sorts of things due to allowing a sort of "assembler instruction inlining". That makes it into even more of a horrible unreadable mess, but again pretty much every industrial automation technician knows them and many among them use it to program stuff.

Minecrafts redstone mechanic could indeed be seen as a primitive graphical HDL language. But lets be honest when have you ever seen a fully graphically based HDL that actually was useful and productive? (AltiumDesigners FPGA tools was pretty close actually until new management came along shitcanned the feature)

That being said some of the languages on my list i actually see being more productive versus classical coding. For example Matlab Simulink does make sense in visualizing how signals flow from one thing to the next since it is tailored to work very much like signal processing. I also see shader graphs as a sensible language for programming GPUs since those things tend to have a very signal processing like structure (like simulink) and so a node graph is clearer than just passing things in chains from function to function. Combine that with the typical say Blender(or other <insert other artistic 3D tool>) user that might just be a visual effects artist working on a movie CGI render, so they have no idea what coding even is, nor anyone on the team that knows it (like perhaps a game development studio might have)

[Leo Bodnar]

All languages have their place but a lot of them are raving solutions looking for a problem that is easily solved without them.
You can probably use classical ballet to propose to a swan but it's not too useful to explain your car mechanic what's wrong with the gearbox.
Leo

[nfmax]

Has software by pictures ever been successful? Yes pictures can be OK as a top level block diagram, e.g. FSMs, but for the nitty gritty tests and actions text is normally better.

Yes, people have created drag-and-drool Lego stuff, but then it is used by people that cannot program in any language

Yes: look at Node-RED (https://nodered.org/) for an example. It doesn't try to do everything (though it can) but the paradigm of messages flowing through pipelines of nodes, each performing a specific operation, is fruitful.

At a very quick look, it looks like it is graphical at the level of FSM languages. It is graphical in terms of top level blocks, but all the useful stuff is done in a range of other text based languages.

I'm not sure how you would do fundamental operations like multiplexing (nodes have only one input) nor iteration.

Multiplexing - just wire your multiple message-sourcing nodes to the processing node input. Each message is handled independently. If you want to combine a message from node 'A' with one from node 'B', then you may be able to use a special-purpose aggregator node, e.g. https://flows.nodered.org/node/node-red-contrib-msg-aggregator. Otherwise you could write some Javascript yourself (in a function node) and remember messages using context variables.

Iteration is generally implicit. The processing flow repeats for each new input message, so the implicit unbounded iterator is the underlying NodeJS event loop. If you want something to happen at regular intervals, start a flow with an inject node or similar, set to the required time interval. Where appropriate, some nodes have internal bounded iterators: they may generate one message for each line of a text file, or for each row of a database query result.

You can write any sort of loop you like in a function node, but beware it will block the event loop while it executes.

[tggzzz]

Is Minecraft a graphical programming language? I've heard it is Turing complete

I had forgotten about PLC ladder logic, never having used them. Can they express unbounded iteration? ISTR there being some unpleasant hacks to sort-of enable advanced concepts like subroutines.

I've used some of the simulation languages, and they are top level block diagrams where the processing is done in C/C++. To me that is syntactic sugar like FSM diagramming languages. Nobody thinks Harel Statecharts are a programming language.

It looks like you are right about LabView. It had changed a lot since I first glanced at it decades ago. I suspect HP's VEE is similar.

I'm completely unfamiliar with gaming environments, and it will stay that way

I never said that these graphical programing languages are actually any good. I hate most of them in at least some way.

None the less they are languages that are sold for prices of a decent used car and/or have user bases counting into the millions. So id argue that they do count as being "successful languages", so apparently there are a lot of people out there that do like them.

Those PLC ladder diagrams are particularly high up my hate list. They have hacky ways of making them do all sorts of things due to allowing a sort of "assembler instruction inlining". That makes it into even more of a horrible unreadable mess, but again pretty much every industrial automation technician knows them and many among them use it to program stuff.

Minecrafts redstone mechanic could indeed be seen as a primitive graphical HDL language. But lets be honest when have you ever seen a fully graphically based HDL that actually was useful and productive? (AltiumDesigners FPGA tools was pretty close actually until new management came along shitcanned the feature)

That being said some of the languages on my list i actually see being more productive versus classical coding. For example Matlab Simulink does make sense in visualizing how signals flow from one thing to the next since it is tailored to work very much like signal processing. I also see shader graphs as a sensible language for programming GPUs since those things tend to have a very signal processing like structure (like simulink) and so a node graph is clearer than just passing things in chains from function to function. Combine that with the typical say Blender(or other <insert other artistic 3D tool>) user that might just be a visual effects artist working on a movie CGI render, so they have no idea what coding even is, nor anyone on the team that knows it (like perhaps a game development studio might have)

I find it hard to argue with that

(I ought to declare that I became beguiled by the possibilities of graphical programming back in 1985 after playing with the first Macs. I even tried to find a way of creating a product which could have ended up like Vizio or perhaps LabView, but I couldn't find a way to finance it. Oh well I've continued to keep an eye out for graphical languages since then, with little success)

Certainly some problems are inherently dataflow oriented, and those ought to map well onto "schematics". By "schematics" I mean top-level blocks connected by wires along which signals flow.

I'm trying to remember which comms simulation system I looked at >25 years ago. It might have been Comdisco or Matlab. In the end it was faster for me to simply code up my problems without the learning curve associated with the Big Tools.

I do remember that any "interesting" special purpose algorithms relevant to your problem domain had to be coded as C functions inside a wrapper/block. Conceptually obvious, but sensibly indicating that graphics were the wrong tool. The LabView technique seems too low level for all but simple automation (shades of COBOL's "add a to b giving c"!)

PLC ladder diagrams are a good example of a hammer; excellent at their specialised job, but bloody awkward when you need a screwdriver. Most languages of all types end up becoming foul messes over the decades.

In the early 90s I watched a team try to automate going from SDL specifications to code. They spent far too much time farting around with the pretty pixels in C++, when they could easily have accomplished that task in Smalltalk. The nice pretty pixels were also annotated with the usual foul C++ required to implement the actions and event processing.

[Berni]

Yeah a lot of times graphical programing-ish solutions are shoehorned into solutions that they don't fit into.

One of the places it does fit into in my opinion however is HDL stuff, but again as a hybrid graphical thing. I would never want to program a FPGA with 100% graphical schematics, but writing blocks of HDL code in the usual stuff like Verilog/VHDL and then connecting those blocks together on a schematic would be nice. The top level file in most FPGA designs tends to be just a bunch of modules that are connected together in various ways with perhaps a gentle sprinkling of logic (like a NOT gate to flip a signal or some OR to join a bus together). Looking at this as a schematic makes more sense than reading trough the code. You can instantly see what blocks connects to what else in what way rather than hunting down a signal name trough the code.

Yes i know this already exists in all the FPGA tools of the major vendors, but the UI is so horrendously bad that it negates any benifit. They all have some of the worst 90s UI design that takes way to many clicks to do things in the most ununtuitive ways possible. As a result i rather just write code instead, then if i want to see it graphically (because i forgot how an old design is done, or i want to sanity check my code) then i just compile it and open the synthesis results in the schematic view. But i could totally see myself using the schematic entry for the top level design file if i could simply drag *.v files into the schematic, have them appear as a block, easily rearrange the pins by just dragging them around and then connect pins with one click at each end. It would allow me to arrange my top level design in 2D in a nice way, better than just 1D code line numbers can. This way you get the strengths of a schematic to clearly show connections between things at a glance, but keeping the coding for the parts its more suited for like describing long windy algorithms with many branches and loops.

Sorry for taking things a bit off topic.
But yeah multithreaded programming is indeed difficult, but some graphical language is probably not the solution to making it easy.

[tggzzz]

Again we are in violent agreement.

The top level HDL argument can also be applied to some enterprise-level software, which is multiple blobs (e.g. micro services) glued together.

Ditto telecoms systems, where the blobs are usually defined in terms of FSMs, and implemented as FSMs in whatever language and environment is convenient.

Choose whatever programming patterns match the specification patterns, so that the correspondence between the two is clear and simple.