Categories

Embrio: A visual programming environment for Arduino

Posted on Friday, March 6th, 2015 in Arduino by DP

embrio-screenshot-1

Embrio, create Arduino programs without writing code:

Easy To Use -Make programs by adding and connecting nodes. No coding necessary!

Real Time Connection -Work with a live connection to your Arduino, see how your program works as you build it!

Powerful -While easy to use, Embrio is a powerful development tool that you won’t outgrow as your skills develop.

Via the contact form.

This entry was posted on Friday, March 6th, 2015 at 9:00 pm and is filed under Arduino. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

26 Responses to “Embrio: A visual programming environment for Arduino”

  1. Jan says:

    Yay, the scary, evil “coding” strawman again. Is typing more difficult than clicking a mouse or what?

    I would love to see whether the clowns pushing any of these “visual” languages, such as LabView or this have tried to actually build *and maintain* any significant codebase in them.

    • KH says:

      Any company who uses this kind of coding deserve what they get, heh.
      IMHO a serious coder will quickly grow out of this kind of GUI thingy. Anyone who keeps using this thing is using an unnecessary crutch, a kind of self-inflicted crippling.
      Methinks some ideas from the MIT Media Labs (who are always very good at promoting this kind of visual thing)(who are no doubt good at showmanship) is good for certain things. I can’t help but compare this to Scratch (programming language) (see Wikipedia) but once coders need more power, they end up with Processing (programming language) (see Wikipedia).
      So young kids can use Embrio, then Arduino IDE, then I hope they move to proper AVR gcc. ;-)

      • Jan says:

        The main problem is that this isn’t targeted at companies or serious developers. This is targeted at newbies and beginners who are given the false impression that they won’t have to learn to program and that it is somehow “easier” if they don’t have to write code but can connect blocks instead. Only $50 and much wasted time later they will discover that it isn’t the case, unfortunately.

        Scratch and similar languages (e.g. the Lego Mindstorms LabView based system) are designed to actually teach programming, as a step towards writing code, not as something to replace it. There it makes sense to use something like this, but that is a very different situation.

      • KH says:

        I agree, it’s an unnecessary $50. As long as a kid can read well, Arduino IDE and some sample code and projects should give them a good start.

    • Hello! I’m the maker of Embrio. I appreciate the comments, though maybe not the “clown” part. I’ve changed the tag line of the site, I believe the “without coding” line gave off the wrong impression. I don’t see coding as evil and am not trying to replace it with a dumbed down shell, but I understand your skepticism, I am after all a long time programmer myself. Coding will of course always be important and I’m not trying to replace it, and certainly wouldn’t encourage anyone not to learn it. Embrio is just another development tool, it might not be the right tool for all jobs but I think it’s a great tool for a lot of jobs.

      I encourage you to check out the autonomous car example project. This is the kind of project that led me to make Embrio, first for my own use and eventually for release as a product after using it for a while and thinking others would like it, and I think you’ll see some things in this sort of project are easier to do visually than with coding, specifically the challenges of many parallel processes happening at once. I find this sort of project a lot more fun to do in Embrio than with coding, you might disagree.

      Upcoming versions of the software will not hide the finished code, I agree that is unacceptable if it’ll ever be a serious development tool, but phase one is focusing on Arduino and hobbyist users until the software is flexible and powerful enough for a wider audience.

      Thanks for your feedback! Just please remember the internet is a pretty small place.

      Ezra

      • Jan says:

        Hello Ezra,

        Thanks for finding the time for replying. And I do apologize for the “clown”, that was my bitter past experience with some people forcibly pushing these visual languages (mainly LabView and Max/MSP) speaking, causing a lot of damage and problems in the process.

        The problem with the “no coding” moniker is that a lot of time “no coding” equates to “no programming”, which is at best misleading. It gives the false impression that solving a task using a graphical language is going to be somehow easier only by the virtue of the language being graphical.

        I think that these approaches have their place for certain types of problems, for example they work great for signal processing tasks where the problem lends itself well to the flow-based programming. Max/MSP or PureData are good examples of that.

        Unfortunately not all problems are like that. In general, the limits of the visual paradigm show themselves quickly – e.g. how do you implement recursion or something like a sorting algorithm unless there is some sort of a built-in block for that? It is possible, but it won’t be neither intuitive nor easy to understand, probably even less than equivalent text code.

        Also larger problems are much faster and less tiring to implement using a textual representation than visual one by connecting blocks. There is a reason why no one is using schematic capture for programming FPGAs, even though it is perfectly possible (the tools are available), for example – what takes 3 lines of text code to express would take half an hour or more to draw by laying down gates and flip flops …

        That’s why I am fairly skeptical of the general utility of this type of tool, except for the beginners. However, those will likely be better served by other approaches, as I have said in my other replies already.

        Regards,

        Jan

      • Hi Jan,

        Thanks for the reply. No hard feelings, this is the internet after all, and I do share your skepticism and am aware of the issues you are talking about and am working to give Embrio the best of both worlds. I agree I think I should remove the “no coding” and “no programming” mentions from my marketing, it just seemed like a good angle to attract interest, but it misrepresents my intentions.

        There are two places to write code in my software, both need to be expanded before the software is flexible enough for any programming project. The first is a node that you can type Arduino code directly into, making it possible to interact with just about any library that runs on the Arduino, rather than try to include nodes that work with all existing hardware. http://embrio.io/documentation/Nodes/InputOutput/CustomIO.aspx I’m currently building out a feature to have a library of these nodes maintainable by users on the website that can be used directly in the software.

        Second, is the ability to write your own internal nodes: http://embrio.io/documentation/node-definitions. Most nodes in the application are implemented as XML, so a user can set the available inputs and outputs at design time, and write code that is dynamically compiled to run in the UI, and transformed to C for when compiled. It also runs a timing test of the C code on your target hardware, and uses that timing data when compiling the final program. It’s very useful to know how long code takes to execute in a processor resource limited environment, especially when you know exactly how often the code needs to be run. This feature needs a good amount of work, it’s still fairly limited what can be done with these (some nodes in the software are hard coded because they can’t yet be implemented in the design time editor), but expanding this is high on my to-do list and important to make the software more flexible. As you said, there are some things the software just can’t do now, but I hope to make that not the case soon.

        What I think people will really like about Embrio is how easy it makes the issue of multiple processes happening at once, which I think is a real challenge for embedded programming, even for moderately advanced programmers. The Arduino site is filled with simple examples of how to read from or write to this or that sensor, which are very easy to get working in a simple program. But once you have multiple things happening at once, it starts to become a very difficult programming task to schedule and time them all effectively. The nodes in Embrio update X times per second, as set by the user, and all of the nodes in the program are always updating. So adding features is basically done in isolation, you don’t have to think much about how it’s effecting the timing of other parts of your program. I think this is a very easy to use yet powerful architecture for programming software that interacts with the real ever changing world, and once the custom code feature is expanded upon a bit more, I think the software will be flexible enough for any task, and make the overall architecture of embedded and embodied software a lot easier to work with without giving up the power and flexibility of text based coding.

      • To clarify, I didn’t mean “for any programming project”, I mean for “every” project, there are already quite a lot of projects that can be done with Embrio, but there are still some things that can’t be done.

        To sum up, Embrio is not supposed to replace text coding, and it’s not meant as a beginner tool that people can use to avoid learning to code. It does serve that purpose, and I’m pushing that a bit in the early marketing effort, but it’s intended to be a serious development tool for creating embedded and embodied software. There are a lot of great benefits to a visual architecture, and coupling that with an ability to hand code the parts that visual programming is not good for, I think Embrio could be a very powerful tool. Don’t write it off just yet because of your negative experiences with visual programming in the past.

      • KH says:

        Seeing this discussion, I’m really saddened that people pushing Arduino (not anyone here, I’m just saying in general) don’t talk about AVR. Many mentally limit others by insisting on convoluted Arduino code, as if the AVR world did not exist. Or they need this library or that library. Someone should do a survey, how many Arduino users have read the MCU data sheet. Perhaps Banzi’s marvel has not been totally successful…

        Back in the stone age, I moved from the Arduino kind of setup/loop program structure VERY quickly, when it became evident that it did not suit my needs or scale or complexity. Interrupt driven programming works just fine for embedded apps, as long as the cpu is not overworked and it meets your spec objectives. Some programming discipline (and good templates or prototype examples) goes a long way. Arduino people hardly ever push the capabilities of the MCU, then they move onto boards with bigger chips, a bit like Microsoft and Intel, ha ha.

        Going to AVR and PIC C/C++ frees the shackles. Complex sequencing with interrupts is better. I write sleep/wake/reset code just the way I want it. I prepare IR remote control output on the fly, in between switching the PWM carrier state, then add keyboard scanning at a lower priority and freq, then add a display heartbeat in the idle loop. Sometimes a dinosaur like me just don’t get how so many people are comfortable without interrupt-driven sequencing in a complicated app. AVR C AVR C AVR C! ;-)

    • Laurence Stant says:

      As a clown who used to push LabVIEW, I know SpaceX maintains an extensive codebase which they launch their rockets with.

    • unlocal says:

      The short answer to your question is “yes”. In fact, model-based development is widely used in many industries, where it offers many benefits over more “traditional” methodologies.

      If you have driven a motor vehicle, ever used a cellular network, ridden an elevator or flown in a commercial airliner you have been using, if not placing your life in the hands of, code developed and maintained using tools like this.

      Given the impractical expense of things like Simulink Embedded Coder, it’s good to see the early emergence of similar tools in the DIY space.

  2. dr3patel says:

    Its only good for primary school kids for fun project only. No one will ever want to use this type of thing where they don’t get to see the actual code. It is also a bad habit to start robotics or arduino.

    • KH says:

      You know what? It’s like Scientific American and National Geographic these days. It’s built for the American audience… much bling, much hand-holding. Yet once upon a time, the many young people in Apollo Mission Control did not shy from complexity or difficulty. Gene Kranz was in the 30s then, many were in their 20s.

  3. Stephen says:

    So I’m wondering what the other commenters here would make of the new Blueprint visual scripting system for Unreal 4.. It supports functions, classes, interfaces and inheritance, and is extensible and capable of doing almost everything that the underlying C++ code can. Visual scripting doesn’t *have* to be some simplistic crippled crutch (I don’t know about this particular product above, though, just making the point it isn’t automatically that way as a result of using the visual paradigm).
    There’s also something to be said for the speed with which you can lay down an idea in a system like this. If you can blitz your way through writing code at the speed of thought, good for you; I think that a system like this is the equivalent of jotting something down in a notebook. Not to mention for visual learners, physically ‘seeing’ code flow is an effective way for them to visualise what is going on.
    Re the point about coding being ‘scary’ – its a matter of framing. I get a lot of students who find code intimidating, and the representation of programming in western culture tends to emphasise it’s difficulty and the ‘otherness’ of those who can code, which doesn’t help.
    Systems like this are a godsend as an educational tool. You still learn control flow and logic either way, but there is definitely less front-loading on things like includes, compiler options, etc, with this sort of thing. That reduces the barrier to entry. I still can’t see how that’s bad. Just because I started with assembly and worked my way up the levels of abstraction doesn’t automatically mean that that’s the best or only way to learn.

    Not being able to see the generated code is a valid criticism of these sorts of systems; its one thing I know the Unreal developers are going to address with their work. But there’s an assumption in that, too- that we would be using this system to be trying to migrate onto more complex code. What if I don’t care about the code, and simply want to get my avr-powered art installation running as simply and quickly as possible?

    There’s also a certain perjorative tone about this sort of thing. If we are going to bemoan the fact people aren’t entering STEM fields, perhaps it’s time to look at how we introduce the basics? Even assuming that the point about the system not being sufficient in the long run is valid, is starting with something like this then transitioning onto code somehow bad? Or are we more concerned with making people hit their head against the wall of low-level programming as a starting point, simply because ‘that’s how I did it’, seeing as that reinforces the perceived difficulty of programming and, in turn, the elitism of programmers?

    • Jan says:

      Stephen, I am very familiar with the UE4 blueprint system – I am developing for/with it at work.

      That is a very different beast compared the Embrio system – it is an extension language, while you can program a lot in it, you won’t go about making some sort of crazy AI or something really complex in that. Code with a lot of looping and branching looks like an enormous messy spaghetti in it. Forget about more complex data structures. Etc. Those things don’t matter so much in UE4, because you have a programmer write the complicated part in C++ and expose that to the blueprints for the designers to use. However, when doing embedded development, those things are pretty much deal breakers.

      Or are we more concerned with making people hit their head against the wall of low-level programming as a starting point, simply because ‘that’s how I did it’, seeing as that reinforces the perceived difficulty of programming and, in turn, the elitism of programmers?

      Oh puhleeaze … Not again this “programmer’s elitism” and “save the kids that want to program but can’t because they are scared of code” bullshit.

      Sorry, but if your goal is to teach programming, then do everyone a service and don’t start with embedded development first. Or do you think that if you wave this magic graphic point&click IDE wand and make the textual code disappear, the embedded idiosyncrasies like having to learn what a clock is or that you actually must set whether a pin is going to be input or output or tristate or that it is a really bad idea to drive a pin low while another is connected to it while set high will somehow disappear too? None of that is related to writing code and none of that is addressed by the clicky graphic neither.

      If you want to teach (or learn) programming, take something like Scratch, Alice, Logo or even the Lego Mindstorms and get the basic concepts in place first in a safe and simple environment on a computer, without the risk of the magic smoke escaping and disappointment because you are at the same time trying to learn programming, electronics and what not.

      Once you get beyond that and understand the concepts, I can guarantee you that you (or your students) won’t have any issues handling something like Python or Lua or even Javascript. Once comfortable and understanding the link between the abstract (algorithm) and concrete (the code or its visual representation), there is no problem anymore – the rest is just experience that has to be gained by doing it. However, when you are that far, you really don’t need any crutches like Embrio anymore. Writing code isn’t hard, programming is – once you learn to program, you will be able to write code in pretty much any language. Experience speaking here, I was teaching basics of programming in Python/C/C++ for 4 years, to complete newbies that have never written a line of code before.

      The problem of people not entering STEM has literally zero to do with writing code but everything with the twisted perception of this stuff not being cool and being hard because of requiring math. When did you last time see an engineer or a mathematician on telly that wasn’t portrayed as some silly/creepy weirdo? Compare that with the image of rich lawyers, businessmen or artists. Still wondering why all the cool kids want to be lawyers, managers, literature/art majors but nobody wants to go study math or computer science? What has that to do with writing code? 10 year old kids can handle writing Arduino code no problem, kids are hacking Minecraft in Python on Raspberry Pis no problem, etc.

      Code is not a problem, problem is how we are teaching computer science. We are replacing learning MS Word and PowerPoint with “coding” – which often means writing stupid web pages and rote learning of some computer language (I have seen students memorizing Kernighan & Ritchie book on C …). That is both useless and harmful. No wonder that after that experience the pupils don’t want to see any of that any more.

      • Jan says:

        Still on the teaching of programming part – in my experience, the hardest part was not really visualizing of the code flow – that is actually fairly easy (top down, left to right), most students get that right away.

        What is tricky to learn is the abstract process of modelling – “If I want to keep track of a battery state of a robot, how do I represent that in a computer?” “If I need the robot to approach an object, how do I do that?” This is the hardest part to grasp for the students, how to decompose an (often obvious issue for a human) into the elementary steps the computer/robot can perform.

        Whether or not you have graphical blocks or text code doesn’t matter so much here. The blocks tend to encourage more trial and error instead of a systematic approach, because it is fast to try.

        I had my students do one class with Lego Mindstorms and its Lab View graphic environment to explain the basic concepts of an algorithm, loop, branching, etc. Then we have moved on to Python and making simple games in that. C/C++ came later. The point was that we wanted the students to be able to solve real world problems. If you give them only toy tools, they will be only able to solve toy problems.

        definitely less front-loading on things like includes, compiler options, etc, with this sort of thing. That reduces the barrier to entry. I still can’t see how that’s bad. Just because I started with assembly and worked my way up the levels of abstraction doesn’t automatically mean that that’s the best or only way to learn.

        Stuff like #includes and compiler options – that shouldn’t even come into play at this point – if you have started to teach programming with a C-like language, you have lost already.

        What if I don’t care about the code, and simply want to get my avr-powered art installation running as simply and quickly as possible?

        By all means, more power to you. Lot of people use Wiring, Pd or Max/MSP too. Just don’t try to do some serious programming using these …

      • Stephen says:

        Nice to see another UE4 user. Gamedev or archviz/simulation? I teach gamedev but am an engine contributor in my spare time.

        Anyway, I appreciate your response as it perhaps gives me the chance to better clarify my intentions.

        I guess I wasn’t specifically responding with regards to embedded development (given the context of this discussion I should probably have made that clearer). As a result when I was talking about teaching programming I was referring to teaching it, using visual scripting systems, within the context of game development instead.

        I do, however, think that people can be rather dogmatic in their insistence that people a) must start learning by learning a low-level language and b) people who use highly abstracted languages or libraries, or non-traditional development environments, are ‘no true [programmer]’, as it were, regardless of whether we are talking embedded or any other sort of software development.

        If Embrio lacks a lot of the organisational features that Blueprint has, and from your comments it does indeed seem to be lacking that functionality, then I can certainly see the point that you’d outgrow it and code written with it would become unmanageable with more than a little complexity to the program; however some of the comments above appeared to be taking umbrage with the visual paradigm itself, and the context of high-level abstraction, rather than the fact that this specific application doesn’t implement it well. On going back and re-reading your own comments, you weren’t among them, though.

        The institution I work for teaches both Blueprint and Playmaker (Unity), alongside classes in C# and C++; I see design students who struggle to understand concepts such as control flow of code, or object models, gain an almost intuitive understanding with the assistance of both those systems. Some students then turn that knowledge back onto an understanding of code, but others continue to implement complex games using the visual paradigm, at times demonstrating greater understanding of principles than those using a more traditional approach.
        In that context I was seeing what I percieved to be the general criticism of a visual approach with some dismay.

        I think you and I are in agreement with the cultural representation of programming, and computers/technology in general. Generational attitudes to technology can to some extent be correlated with the way popular culture represents it, and that has shaped the perception that coding is difficult. Those perceptions are no less strong in their influence on some beginners, for being incorrect and ill informed, though. Given we can’t effectively change the way culture wants to represent those things (‘engineers are uncool’/’math and programming is hard’ etc), tools like these help to reframe the discourse of what programming *is* in a way that can partially mitigate it, even if we have technical arguments for how those systems don’t scale to complexity well. The trial and error approach, experimentation, is something else we try to instill as a self-directed learning strategy, too – of course it needs to be combined with knowledge taught in a systematic way, but encouraging students to ‘try it and see’ in an environment where the time investment is minimised, and the consequences lowered, helps them to explore further on their own without fear.

        In combination with the way those things are represented, though, hearing members of the field make the assertion, that making first steps in programming (of any sort) more accessible is ‘hand holding’ in a negative sense, is likely to scare some people away, and the term ‘crutch’, as some use it, implies something negative about the people who take advantage of these sorts of systems to scaffold their knowledge, too. To some extent such discourse perpetuates the cultural misconceptions we’ve both referred to already, in a way that at times is used for the self-aggrandizement of the people expressing it.

      • Max says:

        Initially I saw this thread when it was three comments long and I decided I best stayed away but tell you what, I just about had it with “proper programmers” righteously bashing visual approaches day in and day out. Obviously one does need to learn to “program” in the sense of acquiring the concepts of conditional branching, loops, and the rest of the building blocks one can use to create more complex algorithms with; no-one is arguing against the need for that. However, currently (as has always been so far) “programming” consists of 1% of actual thinking up ways to complete a task and 99% of banging one’s head against utter bullshit like what magic utterances do I need to type onto a text file to appease the Syntax Gods before I get to see a bloody loop run, or why do I get a bogus warning when the actual problem is a missing semicolon or closing brace twenty lines above the one generating the error, or why I have to write “&int_var” and “&float_var” but simply “string_var” and “struct_var” to pass them along by reference and what is the precedence of “&*this->that”, or why can I easily install a required ubiquitous lib on the (allegedly current LTS) Ubuntu 14.04.2 but see its “-dev” counterpart impossible to install (hint: they fucked it up – it works fine in both 14.04.1 and 14.10, but you can kiss 24 hours of your life bye-bye), or why aclocal just doesn’t see gtk’s m4 macros even though you followed step-by-step instructions trying to cobble together a working build environment out of a mingw msys kit form one source, a mingw-w64 compiler suite from another and an all-in-one gtk package from a third, or why is the math lib a standard lib but not one that is included by default, so your program that compiled fine so far suddenly doesn’t anymore until you add “-lm”, or why can’t I simply stop execution of my program at will with gdb when ctrl-c just doesn’t work, and so on ad nauseam – I can keep this up for the rest of the year if you really want me to. THAT is what programming currently consists of – an endless wasteland of pointless frustration and obscure trivia that has nothing to do with solving whatever you wanted to, peppered with itty-bitty islands of actual problem-solving (and hopefully some satisfaction).

        To be very clear – I’m not saying that Embrio (or Scratch or the Arduino IDE etc.) magically solve all that – but it is my firm belief that right up until all one needs to be able to get a machine to perform a task is the clear understanding of the method to be used and nothing else, “programming” hasn’t reached even the bloody stone age yet – and visual languages make at least a token effort to (and succeed spectacularly better at) trying to remove the barrier of all that useless semantic baggage from the process. Yes, in time you can grow amazingly proficient with arcane tools if you use them (and only them) all your life, day in and day out – but nobody should need to, life’s too short for that crap. The issue worthy of my attention is how to get that car to drive itself, and definitely not what the 1001 command-line options of the linker are. The sooner we manage to kill “proper programming” with extreme prejudice, the better – current visual languages may not be quite what will be used in 500 years, but the current wall’o’text write-me-a-novel-then-pray sure as hell won’t be it either.

      • KH says:

        You’re hilarious Max, the entire first paragraph has very little to do with embedded programming. Do tell us something that is more _directly_ related to embedded programming…

        As for the second para, getting one’s coding intent across with special tools have gone very far in some areas like DSP, but it’s not realistic to expect this can be solved for every type of app. For example, file I/O code can look nice, oh until you need to handle a dozen error cases. What do you do in the visual case then? Also different apps work best with different coding styles, so visual will need different styles too. Vastly different perhaps — how to visually do program theorem proofing, for instance?

        Your rant about compiling tools seems to be related mainly to freely-available stuff. In this context we are missing a whole segment who pay for their tools. I’m sure you can get better stuff if you pay for high-quality tools. Often if you pay, you get end-user service too. Did you pay for the gcc compiler in Ubuntu? I must also point out that development on PCs is different from embedded: Since they are always chasing new features and new apps, they can’t engineer a perfect compiler for you to play with. Don’t paint everything with the same brush.

        As for Embrio, professionals already have their LabVIEW, it’s a safe brand like IBM was, good for CYA. Competing with that will take enormous competence, effort and time. Good luck to Embrio.

      • HK, you seem to be under the assumption that if you are doing visual programming for part of your application, you are doing visual programming for all of your application. Visual is good for some things, and not for others. No one is trying to claim that it is good for everything, but that seems to be what you are arguing against. To claim visual programming doesn’t have it’s place is silly I think (especially with so much hostility…), especially with what I’m trying to do with Embrio which is have an easy yet powerful visual architecture for the big picture, that lets you write code where code is needed.

      • KH says:

        I’m skeptical. I’m critical about certain things. In the last posting above for example, I’m critical about Max’s rant about compiler usage because it is like wanting everything from a tool that, given resource constraints, isn’t set up for users like him. Avionics software dev I’m sure would sprout every conceivable tool visual or otherwise to augment written code, but we simply cannot extend this scenario to hobbyist embedded dev in a simplistic manner.

        Anyway, given that you have quickly pulled back from “no coding necessary” and now you’re talking “powerful visual architecture for the big picture” let’s just pretend (a) I was hand-waving from an armchair and (b) your plans are in the state of flux and leave it at that. If you want my current view in the shortest form, it’s like how I view most Kickstarter thingies: I’ll happily let the market decide whether your widget is successful or otherwise. Happy coding! ;-)

  4. rumburack says:

    What is tricky to learn is the abstract process of modelling

    Yes. Yes. And Yes.

    They are Ultra fast in copying something from the web. Build a Ultrasonic Distance Measurement Thingy? Grab some code somewhere, some wires, hit “Run” and Voila.

    But understanding blocks, scope, different data types… Boring. And consequently all hell breaks lose if they have to do something themselves.

  5. Jan says:

    Hello Stephen,

    Nice to see another UE4 user. Gamedev or archviz/simulation? I teach gamedev but am an engine contributor in my spare time.

    Simulation. I used to teach programming (among other things) at a Uni before, but now I am in the industry.

    I do, however, think that people can be rather dogmatic in their insistence that people a) must start learning by learning a low-level language and b) people who use highly abstracted languages or libraries, or non-traditional development environments, are ‘no true [programmer]’, as it were, regardless of whether we are talking embedded or any other sort of software development.

    That’s true, but I think nobody has said nor implied anything like that in this discussion. My objections are primarily over the problems of the paradigm itself, not whether or not someone is a “true programmer” or that someone is not a programmer because they don’t program in assembly/C/whatever. That is just silly.

    The institution I work for teaches both Blueprint and Playmaker (Unity), alongside classes in C# and C++; I see design students who struggle to understand concepts such as control flow of code, or object models, gain an almost intuitive understanding with the assistance of both those systems. Some students then turn that knowledge back onto an understanding of code, but others continue to implement complex games using the visual paradigm, at times demonstrating greater understanding of principles than those using a more traditional approach.
    In that context I was seeing what I percieved to be the general criticism of a visual approach with some dismay.

    I think our differences come because of our different backgrounds then. If your students were never required to go on and actually use programming to solve real world problems later where they need to be able to integrate with other tools and systems, I am sure it was working for you. I don’t mean this in a negative sense – an art or design student is certainly not expected to become a software engineer and the visual tools can help them extend their skills into another area.

    On the other hand, I was teaching students that had as an objective making games, implementing basic computer vision, computer graphics and virtual reality in later semesters. If all that they have seen was a graphical language (in our case mostly Max/MSP), they were hopelessly unprepared for the task that was awaiting them later. If they were taught programming using Max, 99% of them was not capable of making the step to a textual language, because they were not capable of problem abstraction – they were used to juggling blocks on the screen until it was “doing something”.

    Suddenly they had to implement something like fuzzy logic for a monster in a game or a game tree search for tic-tac-toe opponent and they were completely lost where to even begin. Not to mention that most game engines don’t have any sort of visual tools and the tools they knew couldn’t do the task (you can’t really make much of a game in Max/MSP). This was causing immense problems (we had to teach them the basics of programming while learning the unfamiliar tools, the semester subject and them making a project) until Max/MSP was relegated to where it works (acoustics, perception experiments and what not) and programming started to be taught using tools that can be actually used later on as well.

    Most of the fighting and resistance we had when trying to make this change was actually not from the students (they have seen that the tools and that style of teaching is not helping them) but from some of the teachers, especially those with liberal arts/humanities backgrounds (i.e. non-engineers/programmers with often no programming knowledge/background) making many of the same arguments about the “lower barrier to entry”, “programmer’s elitism”, “visual being easier”, “accessibility to non-engineers” etc. Unfortunately, that teaching was completely unaligned with the learning objectives that were imposed, leading to problems when students had move from “talking about programming” to actually doing it.

  6. I would love to see whether the clowns pushing any of these “visual” languages, such as LabView or this have tried to actually build *and maintain* any significant codebase in them.

    Yikes. I guess I am a clown. I build and maintain large and significant industrial software codebases everyday using a general purpose visual programming language. The language is Prograph and compared to the other languages I know and have used, including C#, C++, C, Objective-C, Python, Perl, and so on, it is the most productive language and development environment for me. No “pushing”, just my experience. The key is not just the visual aspect of the code but the unique interactive mode of development where you get the IDE to create code for you. I used Prograph years ago to program PIC microprocessors but have not applied it to Arduino yet and now it looks like I won’t need to. I look forward to seeing Embrio evolve and progress and applaud the effort. We need more visual approaches to software development.

  7. If anyone is interested I just posted a new version of the software, with better functionality for writing Arduino code right into a visual node. There’s also a quick video about it.

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Recent Comments

  • Peter: Yet another Sunday!
  • Jack: Random comment from KM6MEE. Thanks!
  • KH: A lot of projects that we make will never be cheaper than commodity hardware. It's a choice that each of us will have to make...
  • Drone: @Cyk says: "Well, this is an application that I’d solve with an Android smartphone" BAD idea Cyk: Android Smartphone = Spy on Me Google!
  • Cyk: Well, this is an application that I'd solve with an Android smartphone. Used Moto G phones can be found on Ebay for ~€30, and thanks...