8 ms·
If by "easy UI" you mean a WYSIWYG UI editor, those exist for most serious development of applications, such as for Windows, iOS, and Android, though they still
by brucephillips 9y ago
If by "easy UI" you mean a WYSIWYG UI editor, those exist for most serious development of applications, such as for Windows, iOS, and Android, though they still aren't the norm in web for some reason.
But if by "easy UI" you mean the visual programming language, or the graphical DDL, then I'm skeptical it has any value to programmers. No programmer I know would want to use a visual programming language at all, even with an option to fall into a full text-based programming language.
- lamlam 9y agoSeems like this would be a great way to teach kids, no?
- estraschnov 9y agoWe think so (and in fact wrote this https://blog.bubble.is/improving-computer-education-less-code-more-programming-b626cc13b2bb https://blog.bubble.is/improving-computer-education-less-cod...). We’ve seen a few high schools use Bubble already, but haven’t had time to push for a more systematic approach (providing content, etc.)
- foopod 9y ago> No programmer I know would want to use a visual programming language at all, even with an option to fall into a full text-based programming language. This is something that a lot of game and graphics programmers are doing already. UE4 uses Blueprints[0] now, with the ability for programmers to drop into C++ for more control. I also think that having multiple ways to interact with programming languages is awesome from an accessibility perspective too. [0] https://docs.unrealengine.com/latest/INT/Engine/Blueprints/ https://docs.unrealengine.com/latest/INT/Engine/Blueprints/
- davedx 9y agoYep. Also see Unity's animation controller system. It's only web developers who scoff at tools that improve productivity...
- whodidthis 9y agoThey don't scoff at them. It's just that Dreamweaver etc. WYSIWYG editors they might have tried produce bad and wasteful code.
- Sir_Substance 9y ago>UE4 uses Blueprints[0] now, with the ability for programmers to drop into C++ for more control. Yep, and they produce things which look like this: https://forums.unrealengine.com/filedata/fetch?id=1137264&d=1407499475 https://forums.unrealengine.com/filedata/fetch?id=1137264&d=... That's an A* pathfinding algorithm, it looks like this in code: https://rosettacode.org/wiki/A*_search_algorithm#Python https://rosettacode.org/wiki/A*_search_algorithm#Python On top of that, blueprints are stored in a binary format which can't be diffed, which means it can't be version controlled properly. I'm not sure blueprints would be my go-to example of not-terrible visual programming.
- Moter8 9y agoFor that complicated stuff, or essential things like well, pathfinding, you could just use C++ for it. There's no need to have everything in Blueprint.
- dkersten 9y agoSince its UE4, you probably should have linked the C++ code for A* since that's the alternative for most UE4 games these days. As a professional programmer, I find the code (both in Python and C++) to be quite clean and clear, but in my experience most production code is not that nice. Also, while it looks clean and clear, actually understanding the code is not that easy for me. The Blueprints screenshot is too low resolution for me to compare to see if that's any easier to understand or not. My point is that the textual format isn't necessarily easier and if it is, its largely because we've spent many years reading and writing code like that and presumably very little time reading and writing visual code. Of course we would be more fluent in textual languages! A few years back, I used Max/MSP and Max4Live for a little while and I found it a liberating experience. Max has some, IMHO, rather deep problems which prevent it from being a realistic replacement for a "real" programming language[1], but it also had a bunch of things that made it great. First of all, I realised that the reason that most of the code you see online is a spaghetti-code mess is that most of it was written by people who did not have any software engineering training -- artists and musicians -- and therefore they did not learn the principles that we use (and are just as important even in textual languages) like encapsulation, abstraction, good naming, good factoring, single responsibility and so on. Without these things, code is a horrible unreadable mess regardless of if it is text or pictures. The target audience of Max (and the non-programmer designers that often use Blueprints) are not professional programmers with these principles ingrained, so their code doesn't look great, but it would look like that in text too[2]. However, these people, despite their messy code, manage to do great things! I've seen some write-only mess of Max code that generated awesome music and visuals and I've seen some write-only mess of Blueprints code that a game designer made to test out some gameplay ideas. In that respect, I think they've both been very successful. Another thing I really liked about Max is experimentally developing a piece of code: throwing down a rough outline of what I wanted and then experimentally working towards a solution. One thing that Max allowed me to do that made this super streamlined is to not name things until I knew what they actually were. In text, you often end up with placeholder names. In visual languages, you have some unlabelled boxes or lines. Similarly, the debugging experience of being able to watch values flow through lines was pretty fantastic, as was the interactive development experience that Max provides. Finally, some algorithms are super clear in Max that are not so clear in text, but highly mathematical code does typically look and read a lot better in text. For the record, I have not used Blueprints, but I have used a number of other visual languages: mainly Max and Flowstone/synthmaker, but also some mini-languages embedded in other tools (visual material/shader creation tools are popular in both game engines and 3d modelling tools). [1] Max has quite limited datatypes. At least at the time, you could not have lists of lists and there wasn't really any other container data structures. That really limited what you could do (or at least, made the code a lot messier than it needed to be). I suppose the target audience doesn't need a hash map of lists of sets, but as a programmer, I really missed these things. I have a list of stuff somewhere that, if Max had these, it would be my ideal programming environment. [2] That's if they would write it in text at all. I feel, at least for the musicians I know, they would simply look for other tools if they had to learn textual programming. I think one part of the appeal of visual for some of these people is that it tricks them into learning to program without them necessarily realising it, but if they were asked to learn a textual language they would make excuses about not being programmers. I've seen this happen.
- imnotlost 9y agoBlueprint sucks balls, it's super slow at runtime, it's slow to create logic, and it makes your game code unmaintainable and almost impossible to reason about. Not to mention you can't diff changes. PlayMaker for Unity has the same problems. Friends don't let friends use tools like that.
- grandchild 9y ago> No programmer I know would want to use a visual programming language at all, even with an option to fall into a full text-based programming language. I started with C and then turned to VVVV [0] for a while (now using Python). VVVV enabled me to do a lot of media-related things, that I would have had a hard time doing otherwise. It still has a special place in my heart :) [0] http://vvvv.org http://vvvv.org
- _mhr_ 9y agoWhich Python libraries do use for media-related things?
- grandchild 9y agoI do less media-related things these days. If I would, I'd go back to VVVV. (Or something like that, only for Linux)
- adrianratnapala 9y agoI've often wondered about this. The only graphical language I used ("G", in it's LabView incarnation) was terrible. But the basic idea: data-flowing through visible pipes is valuable. For one thing, functional programming shows that movement-of-data is a viable programming model. Secondly it's a great way to trace causality, helping with those debugging sessions you ask "how did this thing come to hold the value that it holds".
- DonaldFisk 9y agoIt should not be assumed that all visual dataflow languages are similar. They're as varied as textual imperative languages. I'm developing my own dataflow language. Before I began, I had already programmed in many different languages and even designed some of my own languages and dialects. I came to several conclusions about how visual dataflow should be done, which are different from the approach taken in LabVIEW and other visual dataflow languages such as Prograph, Max, and vvvv. (1) You should only be able to connect vertices (i.e. functions) when their argument/value types are compatible. This allows you to drag an edge in the right general direction and it will find what to connect to, and also means you can develop a powerful type system with type inference built into the editor. This makes the language safe, but why stop at Hindley-Milner? You can add units (metres, flight levels, dollars, etc.) to real number types. You can give the language dependent types to make it even safer. This would eliminate many errors inherent in developing in other languages. And with a good enough type system, you don't need object orientation. (2) You can keep the language design simple. You don't need special constructs for things like iteration and conditionals. All you need are vertices (where processing is done), edges (along which values flow), constant values, and enclosures/lambdas. (3) Iteration can often be abstracted away, by having filters operating on streams of data instead of single data items. It might be worth adding an even higher level, with bidirectional flow between processes or agents. (4) You can define new types by connecting existing types, just like new functions can be defined by connecting existing functions. (5) Version control and project management can also be done graphically. I encountered, and solved, some little-known problems associated with dataflow. My language isn't yet ready for release. (There's only one of me, not a large team.) I've begun work on dependent types. I need to develop a non-trivial application, for which I have a few ideas. The language also needs a compiler. I'll add version control and project management when there's any commercial interest. Documentation (which I need to update) is at http://web.onetel.com/~hibou/fmj/FMJ.html The papers on the site describe obsolete versions of the language but are still worth reading. The tutorials are more up to date.
- deleted 9y ago[deleted]
- omnibrain 9y ago> No programmer I know would want to use a visual programming language at all, even with an option to fall into a full text-based programming language. Here! But perhaps not as in typical visual programming tools. When I programmed ABAP which is traditionally heavy on methods/functions with lots of in and out parameters I always wished for the possibility to just drag some lines between parameters I want to map without having to declare and use intermedia variables.
- wruza 9y agoIt is cool to hear this from fellow business-app developer. Half-proves my hypothesis that ideas just fly in the air once you get deeply in the field. From regular developer point of view, I would like to operate blocks that merge/sort/filter datasets (dataflows), visually presented almost the same way they are in conceptual electronic blueprints, where output pin arrays are connected to input pin arrays, both having different names, but wires themselves unnamed. Current flow is not much different from datasets flow.
- daotoad 9y agoSomething like this maybe? https://www.perl.com/pub/2005/06/23/sprog.html https://www.perl.com/pub/2005/06/23/sprog.html
- wruza 9y agoActually, the most popular (if not the only viable) business platform in my country has GUI for heavily modified / application-server backed SQL dialect and everyone is using it, rarely going down to the source to write a complex logical expression or copy things if it seems faster than clicking them. Not that more than half the logic goes into these queries, but it is definitely used. That is possible because the schema and migrations (and forms) are available, edited and maintained by the IDE, also via point-click and property bars. If that was not true, the cheap and quick high-level business programmer market would have a hard time no doubt. In fact, this text field is too small to explain how different it is from “regular” software development, but you can get the idea from PythonicDelphiVisualAccountingORMIDE fusion. Back when we worked in the area, we could do 3-6 clients per day each, solving every task in a less than couple of hours, including conversation, problem analysis, coding, testing (manual, ofc) and receiving cash.
- xaedes 9y agoI use visual programming all the time. On my whiteboard. The task to convert that into code is trivial. Only manual labour. If I could stay on the whiteboard with my pen and compile parts of my program from there, that would be awesome. Btw: I tried some "Smart" Whiteboards, but they are all just bad quality. Real whiteboards are still superior for whatever you do with whiteboarsd.
- icebraining 9y agoAre your drawings precise enough that someone else could keep working on them without ever talking to you?
- xaedes 9y agoYour point being, that a secondary information channel is necessary because the whiteboard drawing itself isn't complete? I guess a lot of times formal errors and the like will happen on whiteboard. So no, the drawings probably aren't precise enough. The process needs to be a dialog. Similar to the interaction you have with your compiler: You provide stuff. "Computer says no" (or tells you what is missing/etc) You alter your stuff and give it back to your tool. That loop repeats. Something similar will be necessary for "whiteboard programming". I guess it is not as trivial to convert drawings to code as I stated. But it still a tedious task that should be automated as much as possible.
- coldtea 9y ago>No programmer I know would want to use a visual programming language at all, even with an option to fall into a full text-based programming language. You'd be surprised. The biggest programming language in actual use is Excel -- which is a case of a visual programming language (turing complete at that), even if it has cells in a grid as opposed to some flow diagram. And lots of people are programming with visual languages inside tools like compositing pipelines, musical environments like Max/MSP, CAD and 3D packages, business logic definition apps and so on -- with the most popular case perhaps being visual game engines.
- baldfat 9y ago> The biggest programming language in actual use is Excel Which has cost companies and investors billions and is the most accident prone. http://www.zdnet.com/article/excel-errors-microsofts-spreadsheet-may-be-hazardous-to-your-health/ http://www.zdnet.com/article/excel-errors-microsofts-spreads... No Version control no way to audit your code. These also come with visual programs.
- DonaldFisk 9y agoAll mainstream version control systems (e.g. cvs, perforce, git) are designed for text but otherwise language agnostic. They are unsuited to visual languages which don't have a textual equivalent. Existing visual languages might not have good version control, but you certainly can provide it. See http://austinhenley.com/pubs/Henley2016VLHCC_Yestercode.pdf http://austinhenley.com/pubs/Henley2016VLHCC_Yestercode.pdf
- coldtea 9y ago>Which has cost companies and investors billions and is the most accident prone. Since it handles untold trillions (almost every company processes their financial data through Excel at multiple points) the "billions" it might have cost is a drop in the bucket. There's a reason why it's used nonetheless. >No Version control no way to audit your code. These also come with visual programs. There's nothing about visual programs that say "no version control" (and of course auditing the code is even easier with visual programs). You either add visual-nodes aware version control, or with a text serialization and back, you use git or whatever.