191–200 of 325 posts
You can program FPGAs in 2D with schematic entry. It is a huge time sink for anything non-trivial which is why few bother with it these days.
Earlier quoted context omitted.
> then why does everyone sketch a picture when trying to convey an idea? Does everyone do that? I think I very rarely do. When I need to convey an idea on a whiteboard, it's still almost completely text, with a few extra symbols like directional arrows that I think are still effectively just symbolic written language. Literally the only time I can remember sketching a picture to convey an idea is while playing Pictio…
Sometimes they do. In my view the most prominent example is documentation for installing computer hardware and software on Windows computers. The instructions will be a series of pictures, with circles and arrows, and a paragraph on the back of each one (sic). This goes on for page after page. And when the OS is updated and the dialogs all change a bit, the documentation becomes confusing or even obsolete. In contras…
Earlier quoted context omitted.
then why does everyone sketch a picture when trying to convey an idea? text is obviously useful but so is visual information. the complete dismissal of visual programming by text-based programmers is often infuriating. visual programming can provide an immediate indication of structure and dataflow, something that text-based languages struggle with. in my mind, the best case scenario is some sort of hybrid, where vis…
> then why does everyone sketch a picture when trying to convey an idea? Does everyone do that? I think I very rarely do. When I need to convey an idea on a whiteboard, it's still almost completely text, with a few extra symbols like directional arrows that I think are still effectively just symbolic written language. Literally the only time I can remember sketching a picture to convey an idea is while playing Pictio…
Earlier quoted context omitted.
So do you use text files for storage or a database? Is your company's accounting system in Word or Oracle? Are programs text, like a novel, or is it data? And to find out, would you query Moby Dick? Not really -- at least that's not how it's meant to be consumed. You read it from beginning to end. Would you read your program from beginning to end or would you query it? You query it, exclusively. I submit that program…
> Is your company's accounting system in Word or Oracle? Accounting uses numbers, which in this context is text. If you replace a spreadsheet with a graph, your accountants will murder you.
Ha! Nice try. You program in a text file. You don't get to somehow call that a spreadsheet just to make your argument sound better.
My whole point is that we need to turn that free text into a spreadsheet (from which graphs can be produced) and "your accountants will thank you".
"Text is the most socially useful communication technology. It works well in 1:1, 1:N, and M:N modes. It can be indexed and searched efficiently, even by hand. It can be translated. It can be produced and consumed at variable speeds. It is asynchronous. It can be compared, diffed, clustered, corrected, summarized and filtered algorithmically. It permits multiparty editing. It permits branching conversations, lurking,…
I do, however, think programming languages could benefit from more visual augmentation. A program, over time, takes on more complexity than a programmer can hold in his mind, and eventually, the program's design will elude him. A disconnect appears between the text he types in the moment and the original design of the program. The sum total of the program's code no longer resembles the problems at hand.
Here, I think, visual tools are underutilized. Not as code crafting tools, but as tools for reflection. Reflection on dependency trees, deviation in style, orphaned code, the ability to visualize how and where data might flow in unexpected ways, etc. Webpack's stats.json comes to mind for dependency tracing. Statically typed languages obviously have a leg up here.
Picture says it all: http://thedailywtf.com/articles/Labview-Spaghetti :)
view-source:https//www.google.com/
Earlier quoted context omitted.
> UI creation best handled by a WYSIWYG editor, a business process is best modeled as a flowchart I disagree with those two. UI creation has generally evolved away from WYSIWYG, composing a UI with code is a much better approach and is now nearly the universal way of doing it. For the business process, the flow chart only works as an extremely high level overview, the implementation is always done in something like c…
> composing a UI with code is a much better approach and is now nearly the universal way of doing it Why is it a better approach? Universal does not always mean better. Javascript was built in 10 days and it's now universal. > the flow chart only works as an extremely high level overview, the implementation is always done in something like code I agree here. The core point I am trying to make is that one size doesn't…
Easier to diff, easier to copy paste, easier to upgrade and easier to extend. In the 90's we had both approaches and it was the code based (Qt, GTK) and declarative (html, xaml) systems that (mostly) won.
If I'm working with win32 or winforms then I love the UI designer, but that's because they come with an awful API, for anything else I'll take the code approach.
I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Managers also tend to like the concept as it would allow them to bypass the pesky code monkeys and just feed their drawings to the computer. For my master's thesis, some 15 years ago, I programmed a syst…
Except there is a successful visual programming tool and it probably runs a large chunk of software in your car. It's called Matlab Simulink: https://mathworks.com/help/simulink/examples/anti-windup-con... Obvious lectures from this: 1) Don't be silly and copy a text based language into visual blocks. Nobody wants to drag&drop the components of a while loop or click a box to enter a variable name. If you have variabl…
A few remarks off the the top off my head:
1) Visually, it reminds me of electrical diagrams, perhaps taking it one or two steps up the ladder of abstraction. I can see how it might be an appealing notation for someone trained in electrical engineering, which may explain its usage in cars. It's really interesting how different "cultures" find different solutions to similar problems.
2) Still, and this may be unfair since I only glanced over it for a few minutes, it strikes me as more of a niche thing than as something that I'd describe as a general purpose language. It seems fixed at a certain level of abstraction. Probably just the right level of abstraction for configuring your car firmware, but impractical for authoring a complex piece of desktop software.
Maybe the future will prove me wrong :)
I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Managers also tend to like the concept as it would allow them to bypass the pesky code monkeys and just feed their drawings to the computer. For my master's thesis, some 15 years ago, I programmed a syst…
Some good points. But I think your view has become too negative, perhaps due to your experiences. Or at least I see more hope for visual programming. :) > I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Perhaps the intutition is right, but the problem…
And we should definitely keep researching stuff, even things which seem like a long shot. We'll almost always learn something useful in the process.
The future will tell I guess.. :)