Out of curiosity, why do you have this as one of the first things people read on your site:
"Pintask promise: we will always keep the service running. And if anybody tries to shut it down, we will open-source it."
1,083 karma · joined August 24, 2009
"Pintask promise: we will always keep the service running. And if anybody tries to shut it down, we will open-source it."
A lot of 3d modeling software provides frameworks where you hook things up instead of coding out solutions (Foundry Modo, Eyeon Fusion, Dynamo are a few). These are very domain specific and not designed to work as general purpose languages/frameworks.
We are working on some ideas for a general purpose compose-able framework and language that uses messages with behavior as the abstraction for communication between sub-systems (http://blog.interfacevision.com/design/design-composition-ba...).
Rote approaches to solving problems are great when the problem is very well defined and repeatable (need to fill an order for a coke and two fries). However, as soon as the mapping changes even slightly, Rote learning[1] and, in my opinion, Rote programming don't work so well.
Even if every tool ever required to implement a software solution (algorithms/approaches/etc.) was available we still need to map a given problem to one or more solutions. This is why I wrote "Writing a program very rarely has the exact same context by which a rote learner can map a solution to."
When I lectured, students could "get" what tools were available to them. If I asked them to describe a sorted list, they could in great detail. However, when given a generic problem, it was a lot harder for them to select from the tools available to them ("Oh, so to speed up this programing, I could use a sorted list"). That is the critical thinking part.
[1] "Umm, I've already told the register that you are giving me 10 dollars so you will need to give me that instead of $10.50". - This happened to me and is a big signal that the person had done rote learning their whole life.
It sounds like you are saying, and I'm not disagreeing with you, that the act of speaking required coding.
That is, speaking is taking input from the senses and memory, converting that input into a natural language (coding/encoding) through thought and saying the final thought out loud.
How does this help in understanding the differences between typing out syntax, manipulating symbols, expression using natural language or AI using it's own coding approaches?
Rote learning is a process of memorization that maps from an exact context to a specific answer ( 3 * 3 = 9).
Writing a program very rarely has the exact same context by which a rote learner can map a solution to. There may be aspects of a program that can be mapped to a specific solution but I really feel this will never be the case for an individual coming up with a complete solution to a unique, never solved before, problem.
Critical thinking is required to come up with a solution to a unique, never solved before, problem.
Enabling people to become critical thinkers is a much bigger problem than just programming: programming will always require critical thinking.
Making programming a computer easier is a difficult problem to solve but very solvable as long as we assume that programmers are critical thinkers.
Ya, it should be something like "Programming for non-coders". We used to say we would "program our VCRs". Somehow programming has become synonymous with coding but, as you pointed out, using Excel is programming.
This is a bottleneck but one that exists even without programming.
In my opinion, the biggest bottlenecks are two fold. Software frameworks are coded to be coded against and the abstractions we use to communicate between sub-systems in programming languages require us to code (parameterized sub-routines).
Software frameworks that are composition centric (you hook up parts instead of calling parameterized sub-routines) make programming a lot easier. You don't even need to code against composite centric frameworks: you can just hook things up using general purpose VPLs.
Parameterized sub-routines lead to way too much specialization of interface making software frameworks both difficult to use and not composition centric. This is why we have to code against our software frameworks. I also feel that parameterized sub-routines are the reason why "there has been no progress since the 1970s".
"It (Visual Thinking) is common in approximately 60%–65% of the general population." - http://en.wikipedia.org/wiki/Visual_thinking
http://en.wikipedia.org/wiki/Autism_spectrum
An amazing lady: Temple Grandin. (https://www.youtube.com/watch?v=fn_9f5x0f1Q) (http://www.grandin.com/inc/visual.thinking.html)
I happen to lean towards visual thinking. I can see and run systems in my head. When I see a mathematical equation I understand, such as f=ma, I feel momentum and see acceleration of shapes in my head. If I can't form that mental picture, I can't do the math. It sucks because even though I can do all of that in my head, I can't remember your name. This is just me. People don't think the same way.
Now, let's considering the situation where source code is the only way to program a computer. This leads to a self-fulfilling prophecy where a majority of the programmers are a certain types of thinker. Sure, people can think using different approaches (as you pointed out: "but it takes some effort to call forth images and it definitely interrupts my ability to think through something"), but it isn't easy for them. It takes extra effort.
> paradigm is separable from notation
I guess I may be conflating them because I see paradigm as driving notation and/or notation can drive paradigms. But perhaps this is a result of how I understand things.
Thank you for taking the time to look through them.
I've never suggested any such thing. In fact, I hinted at just the opposite when I wrote
"The flaw is to assume there is only one mental model that Visual Programming Languages should operate under: say only workflows for example (a mistake all VPLs I've seen have done)."
I wrote a blog post on VPL - Snapshots (https://news.ycombinator.com/item?id=7274674). The pattern I noticed on these VPLs (of which there are close to a hundred in that list now) is that they all attempted to use a single mental model (some are flow, some are spatial, some mathematical, etc.). None of them support different mental models (say flow based when defining business process and mathematical when defining equations).
The flaw is assuming a single mental model can be used to most efficiently describe all real world systems. Given a real world system, there may be one or more approaches used to efficiently describe that real world system in a computing device. That mental model could be textual, it could be visual or it could be both.
Taking the position that no VPL(s) exist that could better describe a particular real world system better than a textual language is standing on loose ground. Perhaps a general purpose domain agnostic VPL doesn't exist (yet), but VPLs shine for some domain specific solutions (gaming engines for example).
> Are you seriously suggesting that there might be a better way for us to communicate and express ourselves concisely?
I'm suggesting that to assume otherwise is limiting our chances of growing Information Technology as a community. I'm suggesting that if we "get it right" then our programming abstractions would be equally useful and descriptive in both a textual and visual language formats.
Interpreted languages (JIT) re-interpret the same source code every time they are run (though they don't have to).
What about monkey patching (http://en.wikipedia.org/wiki/Monkey_patch)? An example usage is altering behavior (the source code) based on running the code in a testing environment -vs- production (as one example).
How about dependency injection? How about lambda expressions?
What about best known practices like favor composition over inheritance? If we hard code a solution using inheritance that is input but if we build out a solution using composition that is a configuration?
These are all tools available to programmers that provide ways of changing behavior at the source code level even though that behavior may not change very often.
This is starting to look like a real gray area to me: input -vs- configuration.
I guess we can try and distinguish between the types of input a system consumes (based on the static nature of the input) but I don't know how useful that is as an abstraction.
To me, this sounds like someone in the literary field of the arts telling an artist or musician that those fields of the arts are not directly useful.
Music and art? Those visual (and aural) embellishments are not directly useful.
There was a great HN post (https://news.ycombinator.com/item?id=7543691) on visually stunning math concepts. What you are implying is that coding out a mathematical equation as opposed to representing it using actual equations (http://i.livescience.com/images/i/000/036/119/original/minim...) is a visual embellishment that is not directly useful?
> Functional VPLs have the same abstraction/scaling up problems as OO VPLs.
This could be a problem with VPLs or it could be a sign of some root cause problem(s) with how we code today. Perhaps, there are better programming abstractions/methodologies that work equally well as words (source code) and as VPLs.
Messages don't need to know what messages they can respond to as all messages have the same behavioral interface (the "makeItSo" property). Where messages expect certain informational properties (information interface) then, ya, the message would need to check if the message passed to it contains the information it requires (such as a UX layout engine that is waiting for UxControl messages).
If you have some time, here are some examples:
An example using addition:
message Add (
left 5
right 6
)
message Add (
left Subtract ( left 5 right 6 )
right 6
)
message Add (
left FromFieldGet ( name "someForm" field "left" )
right FromFieldGet ( name "someForm" field "right" )
)
We could code the usage of our message like this:
float result = message.asFloat; // the "makeItSo" as a float primitive
int result = message.asInt; // the "makeItSo" as an integer primitive
string result = message.asString; // the "makeItSo" as a string primitive
message FormFieldSet (
name "someForm"
field "result"
source RunAsFloat (
part Add (
left FromFieldGet ( name "someForm" field "left" )
right FromFieldGet ( name "someForm" field "right" )
)
)
)
message Button (
action FormFieldSet (
name "someForm"
field "result"
source RunAsFloat (
part Add (
left FromFieldGet ( name "someForm" field "left" )
right FromFieldGet ( name "someForm" field "right" )
)
)
)
// properties specific to the layout of a ux element on a form
)
Each message knows nothing about what behavior the messages composed in the properties of the message (100% decoupled) supports.
A message oriented language doesn't (can't) have constructs like for loops, switches, if/then/else, etc. in it as those aren't messages if they are integrated into the language. Instead, these are also viewed as messages (first class citizens).
A for each statement is also a message:
message ForEach (
start FromFieldGet ( name "someForm" field "start" )
stop FromFieldGet ( name "someForm" field "stop" )
action ...
)
If you look at Obj-C, it is really message passing implemented using traditional parameterized subroutines. Smalltalk is a lot more true to it's own nature but they still use methods as an abstraction for passing information between systems (For example, they will refer to #do as method as opposed to a message).
I think if Alan Kay was forced to implement Smalltalk by focusing 100% on messages (because he was told he couldn't use parameterized subroutines) we would have had a much different world today. In programming, mental models created through abstractions is everything.
Every object has the exact same behavioral interface. The exact same behavioral interface means there is no specialization: every message looks the same. We can compose programs (behavior) by hooking up objects/messages as opposed to coding them. This is because we have 100% encapsulation[2]. We need to know nothing about the internal working of an object since it has no parameterized subroutines.
The abstraction for passing information between sub-systems are these messages (every object is a message) as opposed to parameterized subroutines.
[1] We could call it message-oriented programming (not to be confused with message-oriented software/frameworks).
[2] Even a single parameterized method leaks some of the internal workings of an object and leads to specialization of the objects interface. This also leads to tightly coupled software systems.
The flaw is to assume there is only one mental model that Visual Programming Languages should operate under: say only workflows for example (a mistake all VPLs I've seen have done). This is like assuming that there should only be object-oriented programming when there are other methodologies we use as programmers to form mental models such as declarative programming, functional programming, structured programming, etc.
It doesn't make much sense to code out mathematical equations using flow charts.
A VPL which supports multiple mental models is able to best represent behavior based on specific business domains. The right tool for the right job.
Isn't source code basically a configuration file for the compiler/interpreter?
> because ultimately the config format can never be expressive enough to solve all the problems
And if so, I don't think this statement is quite true. Source code is expressive enough.
Configuration files give us flexibility but not expressiveness. Source code, as it exists today, gives us expressiveness but not flexibility[1].
This disparity should be a big red flag that we are doing something really wrong.
This disparity, in my opinion, is caused by the abstraction we use to communicate information between systems within source code: parameterized sub-routines.
A programming language that doesn't use parameterized sub-routines is basically a configuration file. This gives us both expressiveness and flexibility.
[1] Flexibility is within the context of config-vs-source code and ops post. Programming languages are very flexible when you know them.
That being said.
Classifying things using inheritance leads to a software architecture that is difficult to change. This is especially the case if you follow the principal of don't break interface.
In the real world, people can build out classification systems and easily add in edge cases when we find new ways things can be classified. In software, that could lead to a complete change in the software architecture.
It could be that in our society (USA), people would be so willing to invent software without patents because the patent system itself has created an environment by which people can be successful from being so open. The intention of the patent system worked.
A lot of societies are very closed with regards to sharing information.
Purists would realize that Scrum was defined to be a self reflecting, self improving system. Scrum allows people to alter scrum to meet their needs.
> Scrum deliberately asks the team not to look too far ahead
This is not true. The product owner can put as much stuff on the backlog as they like and the team should know about it. Scrum does ask the team to not spend a lot of time estimating out stories that are months down the road (so very loose estimates are ok).
> Scrum forces that the plan cannot change during the Sprint. This way they know where they stand during the Sprint.
This is true but not totally true. Scrum requires the product owner to "stand back" during a sprint. But, at any time, the product owner can declare the sprint un-productive and it restarts. How does the team know they aren't adding value if the product owner can't stop the sprint?
> For a game to be "potentially shippable" after every Sprint (as Scrum requires) the certification requirements
See above where scrum allows you to alter the "rules" of scrum to meet the needs of the users. Scrum is not written in stone.
If I have money does that mean I am assured that the goods required to fulfill my basic needs exist and can be purchased by that money?
Sheet music, source code, mathematical equations, graphs, etc. are examples of tools we use make it easier to form mental models.
> It would take a while to learn to efficiently read and style visual code just like it does with text based code.
This is why domain specific VPLs work so well: because they allow people work within a mental model they are already familiar with.
Students are often given the digital slides which they use to study off of for finals.
The act of writing/taking notes does help some in knowledge retention. Note taking doesn't happen when students have access to the slides.
But, really, power points aren't the issue with higher education (or education in general).
The purpose of classes are to enable learning. This seems to be best done through student involvement. Lecturing really isn't a good way to get students involved.
The ROI is, among other things, customer loyalty.
Relations are easily persisted because they only have fields meaning they are easy to persist (store).
Objects are not easily persisted because they have methods meaning you are not always assured that the object is in a safe persist-able state (unless they are value objects).