3 ms·

No matter how powerful and expressive your language is, it still breaks down into lines of code to achieve something. I'm not trying to claim some complete, gr

by fuzzix 13y ago

No matter how powerful and expressive your language is, it still breaks down into lines of code to achieve something. I'm not trying to claim some complete, graphically represented program will have as many operations (or boxes) as the equivalent C code. It won't, however, require less cognitive overhead than crafting the program in the language of your choice without making most of your choices for you (and in the process becoming much less powerful, not general purpose at all). edit When a computer is smart enough to derive intent, then a picture will be worth a thousand words. Until then...

nightski 13y ago
It is actually getting damn close with modern dependently typed languages (regarding deriving intent). I believe this is what many graphical languages lack, a sophisticated type system guiding the user. Instead they like to emulate statement based languages with cute but not very abstract or reusable boxes. Also the fact it boils down to code is not true at all. It all comes down to an AST. Text based representation of computer languages is rather archaic when you think about it. I mean, look at IDEs. So many handle code transformations for the user because of how tedious the work is. Not only that, but in order to perform these translations it is transforming the code into an intermediate form it can work in, performing the specified transformations, and then transforming it back to the textual output. It is crazy.
- fuzzix 13y ago
  > It is actually getting damn close with modern dependently typed languages (regarding deriving intent). I believe this is what many graphical languages lack, a sophisticated type system guiding the user. Well, you've gone over my head, but given me plenty of reading material. Thanks. > Instead they like to emulate statement based languages with cute but not very abstract or reusable boxes. Indeed, though they're rarely cute. > Text based representation of computer languages is rather archaic when you think about it. As a workaday sort of guy, it's not really. The code I'm writing at the moment is built on so many abstractions of the underlying storage, the atoms of functionality on the processor and other realities, that I am able to fairly naturally "think in" the language. My run-time makes decisions about sorting, searching, filtering, iterating and so on for me. The typing and context assumptions it makes, the terse nature of it (without golfing) - the attempt to divine my intent without so many words spilled, means I never feel like I'm doing busy work - the boiler-plating, the exception trapping and so on. Someone else's implementation of any given task I need to perform is probably a single command away from being available to me. I may have twisted my imagination to its will, but we get on well now. I don't find it tedious and don't find I need an IDE or related tools to count the pennies. Do you have a vision for a "next gen" (not quite Star Trek Next Generation - "Computer, extrapolate" level) programming paradigm? Are we talking an overhaul of computer architecture or will there always be some clever person writing our C for us? Abstractions all the way down... Also, an AST for some given procedural code, when represented graphically, might look (superficially) like a Jackson Structured Programming diagram, which would have been created by hand... Maybe text is the wrong tool :)

by fuzzix 13y ago

nightski 13y ago

It is actually getting damn close with modern dependently typed languages (regarding deriving intent). I believe this is what many graphical languages lack, a sophisticated type system guiding the user. Instead they like to emulate statement based languages with cute but not very abstract or reusable boxes. Also the fact it boils down to code is not true at all. It all comes down to an AST. Text based representation of computer languages is rather archaic when you think about it. I mean, look at IDEs. So many handle code transformations for the user because of how tedious the work is. Not only that, but in order to perform these translations it is transforming the code into an intermediate form it can work in, performing the specified transformations, and then transforming it back to the textual output. It is crazy.

fuzzix 13y ago
> It is actually getting damn close with modern dependently typed languages (regarding deriving intent). I believe this is what many graphical languages lack, a sophisticated type system guiding the user. Well, you've gone over my head, but given me plenty of reading material. Thanks. > Instead they like to emulate statement based languages with cute but not very abstract or reusable boxes. Indeed, though they're rarely cute. > Text based representation of computer languages is rather archaic when you think about it. As a workaday sort of guy, it's not really. The code I'm writing at the moment is built on so many abstractions of the underlying storage, the atoms of functionality on the processor and other realities, that I am able to fairly naturally "think in" the language. My run-time makes decisions about sorting, searching, filtering, iterating and so on for me. The typing and context assumptions it makes, the terse nature of it (without golfing) - the attempt to divine my intent without so many words spilled, means I never feel like I'm doing busy work - the boiler-plating, the exception trapping and so on. Someone else's implementation of any given task I need to perform is probably a single command away from being available to me. I may have twisted my imagination to its will, but we get on well now. I don't find it tedious and don't find I need an IDE or related tools to count the pennies. Do you have a vision for a "next gen" (not quite Star Trek Next Generation - "Computer, extrapolate" level) programming paradigm? Are we talking an overhaul of computer architecture or will there always be some clever person writing our C for us? Abstractions all the way down... Also, an AST for some given procedural code, when represented graphically, might look (superficially) like a Jackson Structured Programming diagram, which would have been created by hand... Maybe text is the wrong tool :)