6 ms·

Why isn't there a general purpose visual programming language?

12 points by AlfredTwo 16y ago

Jun8 16y ago
What would be the point of this? Sure, you can come up with a more general purpose visual esolang (http://en.wikipedia.org/wiki/Esoteric_programming_language http://en.wikipedia.org/wiki/Esoteric_programming_language) but how would this match the efficiency of programming in, say, C? This would be meaningful only when the visual element adds some value. One such place I can think of would be a video/image query language, e.g. for querying Flickr, that allows users to create complicated queries from image primitives.
- andrewtj 16y ago
  What would be the point of this? I think many seasoned programmers forget that for the non-programmer, syntax is a sizeable impediment to getting a working program and so I'd imagine removing syntax as a source of errors would open up programming to more people. Sure, you can come up with a more general purpose visual esolang (http://en.wikipedia.org/wiki/Esoteric_programming_language http://en.wikipedia.org/wiki/Esoteric_programming_language) but how would this match the efficiency of programming in, say, C? I don't think this comparison makes sense — how can you compare the efficiency of a programming environment to that of a programming language?
  - Jun8 16y ago
    An analogy with natural languages may be useful: there are no languages without syntax, i.e. no completely visual (ideographic) ones, except for simplistic signage domains, e.g. signs in airports, traffic signs, etc. The reason for this is: if you push aside syntax, there is very little expressive power left in a language. The prog lang space mirrors this behavior well, I think: you have very specialized languages, like kudo, but developing a visual language with enough expressive power to be general is very hard, not to say impossible. I didn't understand your point about a "programming environment"
    - andrewtj 16y ago
      The comparison you asked for is that of an apple and an orange. I think you may have also misunderstood my comment on syntax — I wrote "removing syntax as a source of errors" not "remove syntax".
      - extension 16y ago
        But then aren't you just replacing syntax errors with "why can't I attach this visual thingy to that visual thingy"? Either way, they the essence of what they need to learn is the same: translate their ideas into a weird language. I'm not convinced that fitting shapes together is more helpful in that regard than a parser with good error messages and an IDE that does syntax coloring and code completion.
        andrewtj 16y ago
        But then aren't you just replacing syntax errors with "why can't I attach this visual thingy to that visual thingy"? Yes — the idea being to replace syntax and/or logic errors with just logic errors. Either way, they the essence of what they need to learn is the same: translate their ideas into a weird language. I'm not convinced that fitting shapes together is more helpful in that regard than a parser with good error messages and an IDE that does syntax coloring and code completion. I seem to be the only one for whom the words "visual programming" don't conjure an image of weird shapes and diagrams — but I've already said that http://news.ycombinator.com/item?id=1496529 http://news.ycombinator.com/item?id=1496529
  - barrkel 16y ago
    Many non-programmers get around this by relying on learning by example, most notably by copy-and-paste code, with minor adjustments of the parameters, in a kind of cargo cult style. But even this is more awkward with visual languages; it's far harder to e.g. do web searches, ask for help on forums, etc.
    - andrewtj 16y ago
      I don't think visual necessarily implies non-textual. I remember once seeing an old terminal app used by an airline that would allow you to escape the bounds of the input area if you used the arrow keys. You could literally type anywhere on the terminal which as you'd expect, effectively trashed the session till it was reset. The analogy I'd draw is that programming in most editors is like that terminal app, you can do anything even if it's totally illogical and breaks horribly. When I read the question posed at the end of the article, the image that came to mind wasn't a pointy-clicky diagram monstrosity but more of an Intellisense with a tight input guard and strong visual delineation of blocks; a Python with even tighter structural rules rather than a UML on steroids.
- pcarmichael 16y ago
  I work on a graphical (dataflow) programming language called LabVIEW. It is primarily used by scientists and engineers for measurement and automation, but is also useful for general purpose problems. The code looks similar to a circuit diagram, where nodes are wired together to form your functions. Various constructs are available, be it loops, conditionals (case structures), etc. It is a very different programming model that takes some getting used to - if you try to program as a C programmer in LabVIEW you'll have poorly written code and will be grossly inefficient to boot. But if you understand the paradigm and use it to its maximum benefit you'll can be very efficient. Asking if it matches the efficiency of C is a difficult question as it ultimately depends on what type of problem you are trying to solve. For instance, if you're looking at performance-critical low-level bit-banging code, I'd choose C over LabVIEW. But if it involves data acquisition, analysis, and display, I'd choose LabVIEW over C. Each language has its own domain that it excels at where its efficiency (and expressiveness) peaks.
  - barrkel 16y ago
    Spreadsheets are also arguably dataflow languages, albeit with single values rather than continuous or streams of discrete values (though this changes when you're using a Solve function, or playing around with scenarios). But they benefit from not being programmed in a visual way - i.e. the expressions are normally textual, even if they are marked up (e.g. referenced cells highlighted) to aid understanding. That is, dataflow orientation is distinct from being visual. I implemented a dataflow-like language for UI binding in a web framework once upon a time, and it worked very well. Changes to domain objects in business rules were reflected on the web front end without explicit effort on the programmer's behalf, other than binding expressions associated with the front end's control layout description. The update responses to front end requests (e.g. button click events) were communicated via minimal AJAX, because the binding knew only to send an update when a calculated value actually changed. But having had all this experience, I would still not recommend using a graphical language for it except for UI control positioning.
metamemetics 16y ago
VVVV is probably the closest you'll get: http://vvvv.org/tiki-index.php?page=Tutorial+Hello+World http://vvvv.org/tiki-index.php?page=Tutorial+Hello+World
- dzuc 16y ago
  Also interesting in this space (audio/visual/performance) is Pure Data: http://puredata.info/ http://puredata.info/
johngunderman 16y ago
Visual programming languages are great as a teaching tool, but I fail to see how they would be useful as a general purpose programming language. There is no need to be filled.
- silentOpen 16y ago
  I believe that a visual programming environment or state visualizer for concurrency will be essential for a next generation programming language. The need to be filled is the need for representing many dimensions of computation simultaneously. It's 2020 and you've just written a program to run on 1024 machines with 1024 cores each. How do you reason about that?
  - barrkel 16y ago
    How do you visualize a subspace delimited as segments in 1024 axes? Visualization doesn't scale in this way. You need to focus on the small, and have strong and reliable guarantees about those fundamental particles; combined with a safe and reliable way to compose those particles, and combinations, and so forth. You need proofs, and easy ways of asserting that certain properties are true, with help from the machine such that it can tell you - for certain - whether your assertion is true or not for all possible numbers of threads. Now dataflow programming languages, which are often visual, are naturally parallelizable in the same way functional languages are, but this is not related to their visual implementation.
    - silentOpen 16y ago
      You certainly don't make each processor or core a dimension if that is what you are suggesting. The small is type systemic. Machine proofs show that you have written your typable logic correctly. This is still not at the level of concurrency or machine assistance to which I am referring. You are getting closer with dataflow programming languages. Pipeline and compute farm visualization, spatial/resource quota policies and control, and process calculi equivalences proven across visual/spatial refactorings is what is needed. Of course you can do all of this with a linear byte array. Of course you can get more dimensions with names and references. Unfortunately, these methods are very specific and very technical and, despite their accuracy, are relatively devoid of meaning at-a-glance. In the future, a domain expert will work with a programmer to build an application which the domain expert will then operate and monitor. This is not possible without heavy use of graphical interfaces and visual representations. This is not possible without an advanced type system and an easily constructible syntax for DSLs and DSL graphical front-ends. Perhaps you wouldn't classify this as a "visual programming language" as most of the programming itself is not done via virtual objects and connections. However, visual system tools will become increasingly important as programming moves from implementation to specification and control.
mechanical_fish 16y ago
Because they're awful? The author doesn't mention LabVIEW, perhaps because he is not a scientist. LabVIEW is a visual programming language -- you construct software by connecting little icons together with wires. LabVIEW has been around for decades and is a big success. Lots of science labs use LabVIEW, because (a) it's a National Instruments product and interfaces perfectly with National Instruments interface cards -- which have been the industry leaders for years; (b) it has drivers for every instrument ever; (c) the visual paradigm does work great for GUI design and layout. (Which shouldn't surprise anyone who has used XCode or Visual Studio.) Scientists love the ability to throw together a chart recorder application in ten minutes, and then wire it up to everything else in the lab, and LabVIEW works great for that particular use case. Unfortunately, as you go beyond the most basic of computations or out of the environment's sweet spot -- in other words, as you try to use it as a general-purpose programming language -- LabVIEW just gets more and more painful. It has its own special vocabulary, semantics, and design patterns that are unlike everything else you've seen. Every time you want to define a subroutine you need to create a little icon for it, and define its arguments in terms of little panes on the icon. That's slow and painful and limiting; it makes writing Java in Notepad feel like luxury. But you have to stay disciplined and keep defining those subroutines, or your code will literally turn into spaghetti. Oh, the horrors I have seen. It's particularly awful if the code sprawls over more than one screen. You can't effectively print out the code. It's hard to blog and hard to quote snippets from. To refactor you have to manually rearrange icons; there's a lot of time wasted laying things out. There's no way to use version control or create a patch. There's no search-and-replace. Think of emacs. Now think of Notepad. Now think of something that is less useful than Notepad, to the same degree that Notepad is less useful than emacs. That's a visual programming language.
- pcarmichael 16y ago
  (Disclaimer: I work on LabVIEW.) For refactoring and layout, there is a diagram cleanup tool that will automatically re-layout your diagram for you with just a button press. It does a pretty good job IMO, and really changes the way you code. Also, version control is supported, and allows for graphical diff and merge. While there is no search-and-replace, there is a search function. (Search/replace has quite a different meaning when you're dealing with graphs rather than text.)
noahlt 16y ago
I am convinced that this is because the primary input method for PCs is the keyboard, so user input is primarily text. Perhaps a visual programming language will emerge on the iPad, or some other platform where primary user input is graphical rather than textual.
- Qz 16y ago
  Primary input for coding on PCs may be the keyboard. Doesn't need to stay that way.
d0m 16y ago
Let's one statement = a 100x100 images.. Now, imagine 1 million line of code.
- nooneelse 16y ago
  That mapping seems to undervalue the expressive power of pictures, which is commonly taken to be: 1 picture = 1000 words.
jerf 16y ago
You always see the same basic demo when people show visual languages. Here is your homework. Pull up the source code to the program you most like to use. Take an average-sized function in it. Break it up into a Lisp-like syntax tree. If you have fewer than about a hundred nodes, you are probably cheating; get a bigger function. (The purpose of my asking you to get an average sized function is not to minimize the problems, it is so you can actually complete this task.) Draw this tree on a piece of paper using any visual syntax you like. If you've still managed to dodge enlightenment, repeat one layer down on all functions your function calls. If you happen to ascribe to the "one method = one line" school of OO design, then this is mandatory, and you have to complete the transitive closure of your call graph. Complexity can not be removed, only moved around. If it took you less than five minutes, you are now assigned to take the largest function in the source code. You will attain enlightenment. If you still don't believe me, grab a literal pen and a literal piece of paper and literally, in real life, conduct this exercise until you do believe me. The human mind is quite skilled in handwaving to itself; the paper will not permit that.
mishkinf 16y ago
java studio for sun tried to do this but sun was a failure of a company and didnt succeed in staying in alive. i have dabbled in creating a visual programming language for c#. i have a lot of code written. contact me. http://www.thedirtydeveloper.com http://www.thedirtydeveloper.com
gmlk 16y ago
So SmallTalk and Self are not visual enough? http://www.smalltalk.org/ http://www.smalltalk.org/ also http://www.squeak.org/ http://www.squeak.org/ http://selflanguage.org/ http://selflanguage.org/
dirtyaura 16y ago
I have said this argument in HN before, but let me repeat. There's strong evidence that evolution of human language and ability to think with abstract concepts are related. Programming is all about abstractions. It might be even harmful to move to mainly visual programming paradigm. Visualization certainly help in certain subdomains, for example state machines, but, as said, there might be even biological bias in favor for text-based programming languages.
neilk 16y ago
The idea of visual programming is that we'll make the syntax easier for people by using colors and shapes and connecting things together in 2D. To me that seems misguided. When it comes to parsing a stream of text into concepts, humans have hardware acceleration. You're doing it right now, effortlessly. Visual formatting cues can help, but only at a pretty crude level, compared to our sophisticated understanding of language and grammar. Furthermore programming requires that you extend the notation every time you use it. This implies that programming can only be represented well with combinations of symbols, of which the example par excellence is text.
scottw 16y ago
For the same reason we still use text to communicate: iconography is insufficiently rich to express the degree of complexity required to abstract, describe, and solve hard problems.

12 points by AlfredTwo 16y ago

Jun8 16y ago

What would be the point of this? Sure, you can come up with a more general purpose visual esolang (http://en.wikipedia.org/wiki/Esoteric_programming_language http://en.wikipedia.org/wiki/Esoteric_programming_language) but how would this match the efficiency of programming in, say, C? This would be meaningful only when the visual element adds some value. One such place I can think of would be a video/image query language, e.g. for querying Flickr, that allows users to create complicated queries from image primitives.

andrewtj 16y ago
What would be the point of this? I think many seasoned programmers forget that for the non-programmer, syntax is a sizeable impediment to getting a working program and so I'd imagine removing syntax as a source of errors would open up programming to more people. Sure, you can come up with a more general purpose visual esolang (http://en.wikipedia.org/wiki/Esoteric_programming_language http://en.wikipedia.org/wiki/Esoteric_programming_language) but how would this match the efficiency of programming in, say, C? I don't think this comparison makes sense — how can you compare the efficiency of a programming environment to that of a programming language?
- Jun8 16y ago
  An analogy with natural languages may be useful: there are no languages without syntax, i.e. no completely visual (ideographic) ones, except for simplistic signage domains, e.g. signs in airports, traffic signs, etc. The reason for this is: if you push aside syntax, there is very little expressive power left in a language. The prog lang space mirrors this behavior well, I think: you have very specialized languages, like kudo, but developing a visual language with enough expressive power to be general is very hard, not to say impossible. I didn't understand your point about a "programming environment"
  - andrewtj 16y ago
    The comparison you asked for is that of an apple and an orange. I think you may have also misunderstood my comment on syntax — I wrote "removing syntax as a source of errors" not "remove syntax".
    - extension 16y ago
      But then aren't you just replacing syntax errors with "why can't I attach this visual thingy to that visual thingy"? Either way, they the essence of what they need to learn is the same: translate their ideas into a weird language. I'm not convinced that fitting shapes together is more helpful in that regard than a parser with good error messages and an IDE that does syntax coloring and code completion.
      - andrewtj 16y ago
        But then aren't you just replacing syntax errors with "why can't I attach this visual thingy to that visual thingy"? Yes — the idea being to replace syntax and/or logic errors with just logic errors. Either way, they the essence of what they need to learn is the same: translate their ideas into a weird language. I'm not convinced that fitting shapes together is more helpful in that regard than a parser with good error messages and an IDE that does syntax coloring and code completion. I seem to be the only one for whom the words "visual programming" don't conjure an image of weird shapes and diagrams — but I've already said that http://news.ycombinator.com/item?id=1496529 http://news.ycombinator.com/item?id=1496529
- barrkel 16y ago
  Many non-programmers get around this by relying on learning by example, most notably by copy-and-paste code, with minor adjustments of the parameters, in a kind of cargo cult style. But even this is more awkward with visual languages; it's far harder to e.g. do web searches, ask for help on forums, etc.
  - andrewtj 16y ago
    I don't think visual necessarily implies non-textual. I remember once seeing an old terminal app used by an airline that would allow you to escape the bounds of the input area if you used the arrow keys. You could literally type anywhere on the terminal which as you'd expect, effectively trashed the session till it was reset. The analogy I'd draw is that programming in most editors is like that terminal app, you can do anything even if it's totally illogical and breaks horribly. When I read the question posed at the end of the article, the image that came to mind wasn't a pointy-clicky diagram monstrosity but more of an Intellisense with a tight input guard and strong visual delineation of blocks; a Python with even tighter structural rules rather than a UML on steroids.
pcarmichael 16y ago
I work on a graphical (dataflow) programming language called LabVIEW. It is primarily used by scientists and engineers for measurement and automation, but is also useful for general purpose problems. The code looks similar to a circuit diagram, where nodes are wired together to form your functions. Various constructs are available, be it loops, conditionals (case structures), etc. It is a very different programming model that takes some getting used to - if you try to program as a C programmer in LabVIEW you'll have poorly written code and will be grossly inefficient to boot. But if you understand the paradigm and use it to its maximum benefit you'll can be very efficient. Asking if it matches the efficiency of C is a difficult question as it ultimately depends on what type of problem you are trying to solve. For instance, if you're looking at performance-critical low-level bit-banging code, I'd choose C over LabVIEW. But if it involves data acquisition, analysis, and display, I'd choose LabVIEW over C. Each language has its own domain that it excels at where its efficiency (and expressiveness) peaks.
- barrkel 16y ago
  Spreadsheets are also arguably dataflow languages, albeit with single values rather than continuous or streams of discrete values (though this changes when you're using a Solve function, or playing around with scenarios). But they benefit from not being programmed in a visual way - i.e. the expressions are normally textual, even if they are marked up (e.g. referenced cells highlighted) to aid understanding. That is, dataflow orientation is distinct from being visual. I implemented a dataflow-like language for UI binding in a web framework once upon a time, and it worked very well. Changes to domain objects in business rules were reflected on the web front end without explicit effort on the programmer's behalf, other than binding expressions associated with the front end's control layout description. The update responses to front end requests (e.g. button click events) were communicated via minimal AJAX, because the binding knew only to send an update when a calculated value actually changed. But having had all this experience, I would still not recommend using a graphical language for it except for UI control positioning.

metamemetics 16y ago

VVVV is probably the closest you'll get: http://vvvv.org/tiki-index.php?page=Tutorial+Hello+World http://vvvv.org/tiki-index.php?page=Tutorial+Hello+World

dzuc 16y ago
Also interesting in this space (audio/visual/performance) is Pure Data: http://puredata.info/ http://puredata.info/

johngunderman 16y ago

Visual programming languages are great as a teaching tool, but I fail to see how they would be useful as a general purpose programming language. There is no need to be filled.

silentOpen 16y ago
I believe that a visual programming environment or state visualizer for concurrency will be essential for a next generation programming language. The need to be filled is the need for representing many dimensions of computation simultaneously. It's 2020 and you've just written a program to run on 1024 machines with 1024 cores each. How do you reason about that?
- barrkel 16y ago
  How do you visualize a subspace delimited as segments in 1024 axes? Visualization doesn't scale in this way. You need to focus on the small, and have strong and reliable guarantees about those fundamental particles; combined with a safe and reliable way to compose those particles, and combinations, and so forth. You need proofs, and easy ways of asserting that certain properties are true, with help from the machine such that it can tell you - for certain - whether your assertion is true or not for all possible numbers of threads. Now dataflow programming languages, which are often visual, are naturally parallelizable in the same way functional languages are, but this is not related to their visual implementation.
  - silentOpen 16y ago
    You certainly don't make each processor or core a dimension if that is what you are suggesting. The small is type systemic. Machine proofs show that you have written your typable logic correctly. This is still not at the level of concurrency or machine assistance to which I am referring. You are getting closer with dataflow programming languages. Pipeline and compute farm visualization, spatial/resource quota policies and control, and process calculi equivalences proven across visual/spatial refactorings is what is needed. Of course you can do all of this with a linear byte array. Of course you can get more dimensions with names and references. Unfortunately, these methods are very specific and very technical and, despite their accuracy, are relatively devoid of meaning at-a-glance. In the future, a domain expert will work with a programmer to build an application which the domain expert will then operate and monitor. This is not possible without heavy use of graphical interfaces and visual representations. This is not possible without an advanced type system and an easily constructible syntax for DSLs and DSL graphical front-ends. Perhaps you wouldn't classify this as a "visual programming language" as most of the programming itself is not done via virtual objects and connections. However, visual system tools will become increasingly important as programming moves from implementation to specification and control.

mechanical_fish 16y ago

Because they're awful? The author doesn't mention LabVIEW, perhaps because he is not a scientist. LabVIEW is a visual programming language -- you construct software by connecting little icons together with wires. LabVIEW has been around for decades and is a big success. Lots of science labs use LabVIEW, because (a) it's a National Instruments product and interfaces perfectly with National Instruments interface cards -- which have been the industry leaders for years; (b) it has drivers for every instrument ever; (c) the visual paradigm does work great for GUI design and layout. (Which shouldn't surprise anyone who has used XCode or Visual Studio.) Scientists love the ability to throw together a chart recorder application in ten minutes, and then wire it up to everything else in the lab, and LabVIEW works great for that particular use case. Unfortunately, as you go beyond the most basic of computations or out of the environment's sweet spot -- in other words, as you try to use it as a general-purpose programming language -- LabVIEW just gets more and more painful. It has its own special vocabulary, semantics, and design patterns that are unlike everything else you've seen. Every time you want to define a subroutine you need to create a little icon for it, and define its arguments in terms of little panes on the icon. That's slow and painful and limiting; it makes writing Java in Notepad feel like luxury. But you have to stay disciplined and keep defining those subroutines, or your code will literally turn into spaghetti. Oh, the horrors I have seen. It's particularly awful if the code sprawls over more than one screen. You can't effectively print out the code. It's hard to blog and hard to quote snippets from. To refactor you have to manually rearrange icons; there's a lot of time wasted laying things out. There's no way to use version control or create a patch. There's no search-and-replace. Think of emacs. Now think of Notepad. Now think of something that is less useful than Notepad, to the same degree that Notepad is less useful than emacs. That's a visual programming language.

pcarmichael 16y ago
(Disclaimer: I work on LabVIEW.) For refactoring and layout, there is a diagram cleanup tool that will automatically re-layout your diagram for you with just a button press. It does a pretty good job IMO, and really changes the way you code. Also, version control is supported, and allows for graphical diff and merge. While there is no search-and-replace, there is a search function. (Search/replace has quite a different meaning when you're dealing with graphs rather than text.)

noahlt 16y ago

I am convinced that this is because the primary input method for PCs is the keyboard, so user input is primarily text. Perhaps a visual programming language will emerge on the iPad, or some other platform where primary user input is graphical rather than textual.

Qz 16y ago
Primary input for coding on PCs may be the keyboard. Doesn't need to stay that way.

d0m 16y ago

Let's one statement = a 100x100 images.. Now, imagine 1 million line of code.

nooneelse 16y ago
That mapping seems to undervalue the expressive power of pictures, which is commonly taken to be: 1 picture = 1000 words.

jerf 16y ago

You always see the same basic demo when people show visual languages. Here is your homework. Pull up the source code to the program you most like to use. Take an average-sized function in it. Break it up into a Lisp-like syntax tree. If you have fewer than about a hundred nodes, you are probably cheating; get a bigger function. (The purpose of my asking you to get an average sized function is not to minimize the problems, it is so you can actually complete this task.) Draw this tree on a piece of paper using any visual syntax you like. If you've still managed to dodge enlightenment, repeat one layer down on all functions your function calls. If you happen to ascribe to the "one method = one line" school of OO design, then this is mandatory, and you have to complete the transitive closure of your call graph. Complexity can not be removed, only moved around. If it took you less than five minutes, you are now assigned to take the largest function in the source code. You will attain enlightenment. If you still don't believe me, grab a literal pen and a literal piece of paper and literally, in real life, conduct this exercise until you do believe me. The human mind is quite skilled in handwaving to itself; the paper will not permit that.

mishkinf 16y ago

java studio for sun tried to do this but sun was a failure of a company and didnt succeed in staying in alive. i have dabbled in creating a visual programming language for c#. i have a lot of code written. contact me. http://www.thedirtydeveloper.com http://www.thedirtydeveloper.com

gmlk 16y ago

So SmallTalk and Self are not visual enough? http://www.smalltalk.org/ http://www.smalltalk.org/ also http://www.squeak.org/ http://www.squeak.org/ http://selflanguage.org/ http://selflanguage.org/

dirtyaura 16y ago

I have said this argument in HN before, but let me repeat. There's strong evidence that evolution of human language and ability to think with abstract concepts are related. Programming is all about abstractions. It might be even harmful to move to mainly visual programming paradigm. Visualization certainly help in certain subdomains, for example state machines, but, as said, there might be even biological bias in favor for text-based programming languages.

neilk 16y ago

The idea of visual programming is that we'll make the syntax easier for people by using colors and shapes and connecting things together in 2D. To me that seems misguided. When it comes to parsing a stream of text into concepts, humans have hardware acceleration. You're doing it right now, effortlessly. Visual formatting cues can help, but only at a pretty crude level, compared to our sophisticated understanding of language and grammar. Furthermore programming requires that you extend the notation every time you use it. This implies that programming can only be represented well with combinations of symbols, of which the example par excellence is text.

scottw 16y ago

For the same reason we still use text to communicate: iconography is insufficiently rich to express the degree of complexity required to abstract, describe, and solve hard problems.