ericHosick

> majority screaming "no, that's not programming"

I think this has something to do with one of Clarke's Three Laws (http://en.wikipedia.org/wiki/Clarke's_three_laws).

> When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.

I talk and think a lot about democratization of software development.

People I talk with who really want to program but couldn't get past coding really like the idea of visual programming environments where they don't have to deal with the compiler/interpreter.

When I talk with people who are experienced, they feel there is no advantage to programming any other way than writing code.

From my experience, we have not gone too far in improving the development of software for many many decades and Bret Victor does a good job of pointing this out. I think the way we code now, and specifically how we build out software frameworks, is flawed.

We engineer software frameworks that contain both mechanism and business "objects" when software frameworks should only contain mechanism.

Software frameworks should be coded to be used by non-coders: not by other coders.

Really, a domain agnostic visual language will be hard to develop when it is representative of how we code now.

I'm looking and it is hard to find a good example. Something like this maybe? http://www.mactech.com/articles/mactech/Vol.03/03.10/HyperCa...

If you really get to thinking, programming is all about abstraction. We talk about abstract concepts like functional programming, object oriented programming, structured programming, objects, functions, methods, inheritance, etc. But, in the end, it's all just playing around with stack pointers, instructions and malloc.

As Permit points out here (https://news.ycombinator.com/item?id=7274956), a large part of a programmers job is to build a "mental model of their program".

We abstract things and come up with constructs to represent these abstractions to make it easier for us to program a computer: to improve on our mental model.

So, we come up with different programming languages and label them by their approach. This is a functional programming language, this one is declarative, this one is procedural and this one is visual.

My 2 cents.

I think very domain specific visual programming environments work well: music, 3d modeling, etc.

However, for the ones that try to be domain agnostic, they don't seem to work so well.

Any you would recommend?

Added self. It was hard to find a good screenshot though.

I would really like to chat with you about code connect and get your thoughts. My email address is in the post.

Ya. My Bad. I've added a better screen shot.

Added.

Thank you. :-)

> If you can program you can code, if you can code you can program.

If you consider people who use scratch (http://scratch.mit.edu/) as coders, then I would agree with you.

But, to me, it doesn't look like they are coding. It looks like programming using something other than coding.

> Why do you think that it's important to distinguish between the two?

It is important because programming doesn't always involve coding.

It is important because language can limit or expand our thinking and definitions play a role in that.

I think it is important to strive for moving away from coding as the primary means of programming a computer so we can democratize software development. So, we should not redefine the definition of programming to be "coding a computer".

> since it's not done on a regular basis

I don't think this is a very good litmus test.

> usually is called "configuring", or "defining workflow" but not "programming"

We used to say "program a VCR".

The word is even defined as "the action or process of writing computer programs." There is no mention of coding as being a required aspect of the programming process.

I think it is important to distinguish between the two.

It is possible to program a computer without coding. Currently, the tools to do this are very domain specific.

I think, in the future, there will be domain agnostic development tools that will let people program software without the need to write code.

Also a best known practice:

http://en.wikipedia.org/wiki/Composition_over_inheritance

It seems like almost all professions have a body of knowledge. Software Engineering doesn't.

Imagine getting open heart surgery, your chest is open, and doctors start arguing over the best methodology to do it.

> rapid-prototyping works best for me

> provide environment where clients would feel their input is steering project

> others working on a project would like clear direction

What tools would you/do you use?

"Ocean tides flow through the Golden Gate four times a day -- twice coming in and twice going out. The quantity of salt water in motion between high and low tides averages 390 billion gallons." or about 1.5 billion cubic meters per day.

I was also surprised not seeing Better Touch Tool there. It is a great program.

For example, I've mapped switching between tabs to TipTap left and TipTap right for any software that has tabs (Chrome, FireFox, Terminal, TextMate, etc.).

Design patterns are just that: common patterns that we see occurring within our designs. Just in case you don't know about it, the usage of Design Patterns within computer science were influenced by Christopher Alexander (http://en.wikipedia.org/wiki/Christopher_Alexander). See http://en.wikipedia.org/wiki/A_Pattern_Language.

Design patterns exist within all programming methodologies including functional programming, structured programming, etc. In some cases, the pattern is incorporated within the methodology, some within a specific language, some are incorporated within the framework and others are used at the domain level.

Just because a design pattern has become so ubiquitous we don't even know we are using it doesn't mean the pattern does not exist. The iterator pattern has been weaved into languages for both functional and object oriented programming. Java has implemented it at the framework level. Maybe it should not have been done there.

In all cases, this really has nothing to do with shortcoming of OOP (or any programming methodology for that matter). It has to do with allowing us to recognize common patterns of design within software.

> Did you include a study of the Mythical Man Month?

Yes. But not in the above described BIS class. It was in another class in the CIS program.

In my opinion, writing software requires two "primary" skills.

A) A student needs to be able to map real world systems to a computing device. This requires a lot of critical thinking and is basically the process of automating a real world problem.

B) A student needs to be able to code out the problems they have solved above.

Where it gets difficult is that students are usually taught how to code before they are taught how to do that mapping from the real world "thinking" to computer world "thinking". I feel their internal model of programming becomes tainted with concepts like scope, functions, methods, parameters, pointers, lists, arrays, data structures, inheritance, composition and so on. All useful tools, but hard to mentally picture without understanding why the exist.

I look at learning to code before learning to critically solve problems like learning all about a motorcycle without understanding it's purpose: to move you from one location to another. Sometimes, students have ah-ha moments and they would be like "Oh, now I see why we are learning about motorcycles. It is because we've learned about these roads things and we can use the motorcycles to move us from here to there using these road things we learned in a prior chapter".

Where it gets even more difficult is that students are often expected to learn how to think critically to do that mapping thing (A) and at the same time learn to code (B).

In my opinion, the optimal way to learn how to program would be to teach the critical thinking aspects and associated tools in A and then teach implementation (programming) in B (then alternate) with about a two week gap. One class on A, then two weeks later a class on B, then two weeks later a class on A.

This is an iterative approach to learning that allows students to master concepts in software development and then apply those new skill by programming (by coding or other means) solutions in a computing device.

> What's the point of learning UML and Design Patterns? (Especially, if you can't program?)

It was for the BIS program (http://www.rmit.edu.au/programs/bp138). You can get an idea of the program for graduates.

I look at coding as a way of programming but not all programming needs to be done by writing code. There are other ways to program a computing device: a.k.a alter the behavior of a program.

> What were students supposed to be able to accomplish that they couldn't do before?

I don't recall the ILO's (Intended Learning Outcomes) of the class but I do recall one was being able to apply Design Patterns in their analysis and design.

I'm not saying I agree with people designing software systems without also having an ability to code but I do think people can think critically about solving problems using tools like UML without having to code out the solution.

I do agree that there is really nothing to show that you've done: program wise. On the other hand, the students did learn a lot about critical thinking which, I feel, is a great start to programming.

This was also for a BIS degree (not a CS degree) which focused on the "business" side of information science: so most students weren't interested in coding (though I felt this was not to their advantage).

Really, it was a bit the fault of administration for placing the class in the first semester of the degree when students had not taken any programming classes yet.

Just a story.

I was lecturing a class on UML and Design Patterns to students who had never coded before (basically UML).

The class textbook, lecture notes and lecture slides I was given had a lot of coding examples.

During the 12 week class, I wrote a book on Object Oriented Modeling (staying two chapters ahead for the students) that had almost no source code.

It was a challenge to explain OOM, UML and Design Patterns to students who had no prior coding experience.

I do feel it is totally possible to teach people how to "program" without knowing how to code.

We've been working on a programming language that is based on composition. This basically leads to a hybrid data structure (not necessarily tree-structured).

Here is an example (write out 1 2 4 8 16 32 on different lines):

   Application (
     using Library ( name "Vision.Console" )
     action ForEach (
       items 1 2 4 8 16 32
       action WriteLine ( text CurrentItem () )
     )
   )

Parts are upper case and properties are lower case. Each Part is a class 1 contained within a given framework.

Tests and behavior should be defined before the code.

I recommend you comment out all code, write the tests and then un-comment the code line by line.

This not only tests the code, but tests the tests and assures that you are covering the edge cases the code contains already.

The logistics behind keeping track of 100+ students a trimester can become daunting. Most tools available to teachers are wanton.

Then throw in classes with 600+ students requiring multiple teachers. Trying to align fairness (rubrics), plagiarism (tools like Turn-it-in) and the uniqueness of teaching style is difficult.

We'll, I think it is more about teachers being overloaded with the minutiae of data that causes them to lose focus of the bigger picture (education). Actually, in my opinion, education has lost focus on the bigger picture of education and may have never really had it.

Ya. I saw that and it was awesome.

> api`s for systems that negotiate a communication protocol dynamically

I think the first step is to find a very easy way to describe communication between sub-routines/processes. Once people can hook things up and compose the interaction of software with foreign/unknown systems (all in real time while the software is running) then we can get systems to start doing it dynamically (run on sentence but ya).

> Wow, you can change the brightness of the sun to meet a requirement?

Sure, why not? sun.brightness = sun.brightness * 2.0f;

In fact, a lot of games play with physics to get cool behavior. I can adjust the "constant" G in my game to be something other than 9.8 m/s to make it interesting.

One moment the G vector may be down and then suddenly it flips up. Why not?

Http is a protocol we use to communicate between systems, that is true, but not the parts of software. For example, to print "Hello World" on the screen, we use a sub-routine like WriteLine. The standard we use to communicate between software sub-systems, in this case, is a function with parameters. So, WriteLine ("Hello World") pushes the text "Hello World" into the sub-routine WriteLine.

Parameters are, for basically all languages, the means by which information is communicated between sub-systems.

The thing is, it is really hard to standardize the communication between sub-systems because sub-routines can vary widely in how they are defined (the possible combination of parameters and types is quite high). In fact, you can end up with thousands of different sub-routines: even in the same program. Each one unique and thus "non-standard".

This is the problem we need to crack. How do we create frameworks that don't lead to thousands of specialized interfaces: each one making the framework that much harder to use.

> create an industry standard plugin protocol.

I feel that Software Engineering/Science is lacking a body of knowledge: something which is basically required in other professional industries (architecture, medical, physics, electrical engineering), etc.

Software Engineering/Science is at a disadvantage because there is no limitation placed on us by nature: an EE can't simply change the brightness of the sun to meet a requirement. We can.

To create an industry standard plugin is really saying we need to create a common way to communicate information between systems and sub-systems in software. I feel we have not really figured out the best way to do this yet. Our industry is still young.

I've put a lot of thought (about 6 years now) into a way to standardization communication between software systems and even parts of software. It's a hard problem to crack.

> common protocol between user environment and code transformer

I feel that once we crack the problem of communication between software parts, this will come naturally.