Gazz wrote:It's just that <1% of the customer base is going to attempt and pull through with anything as complex as in your picture.

Probably accurate. The content consumers always far outnumber the content creators.

The value of this feature does go up if program creators are able to distribute their code for use by other players, though.

FriendlyFire wrote: I wasn't at all attracted by Notch's 0x10c specifically because of how programming was central to the ordeal and would've required a lot of time and effort to run even basic systems (that and how it was apparently hip and trendy to replicate an old CPU and get you coding in Assembly... yeah, no fucking way).

I like you. Welcome!

FriendlyFire wrote: With that out of the way, the only other issue I have is one of readability. Just your Fibonacci examples are not particularly readable at a glance, yet they take a fair amount of space and aren't even complicated in practice. I'm not sure larger programs would be manageable with this sort of setup.

I kind of agree with this, but not entirely. I think a language like this could be an excellent first programming experience for a lot of people.
When a program becomes too large, it's time to make functions. Being able to graphically debug your program would help too. (Manually execute it with certain parameters and see the game draw the line of how it flows through the program.)

FriendlyFire wrote: That is... unless you change your paradigm. I think this sort of layout is terribly unsuitable to imperative programming. Have you looked at creating this sort of system with a functional language instead? I've always felt that a language like Haskell or Erlang (heck, even Prolog) could work very well graphically. Functional languages usually have very small functional groups which combine together to form programs, as opposed to declarative programming with lots of sequential instructions in relatively large functions. I think this would work better with the node system, since you'd have more branching and smaller branches as opposed to extremely long lines with the occasional split. As a bonus, I think you'd be teaching a lot of people a different way to look at code

Note that I'm not adamant that this is THE right way to go, merely that exploring the possibility could be intriguing.

I'm not familiar with any of those languages, so I can't really comment on this.

Cornflakes_91 wrote:Im missing array-type variables (or at least efficient ways of accessing them)

Besides of that i like that proposal, it ties very much in with my Custom UI Parts idea.

But im not sure if it is feasible inside the scope of LT...

This discussion reminds me a lot of something I saw in a game called Capitalism, by Trevor Chan. Pictures can say it best:
Specifically what I wanted to point out is the lower right 9 square grid. What you have here, happens to be a retail store. However, factories also have 9 squares. The key here is that all stores/factories, no matter what they are, are 9 blocks and can be configured to produce whatever you need by plopping in different modules and linking them to the various other modules. Here is a factory example making leather wallets, belts, and purses:
A factory could be configured to produce only leather belts. Or, to be more cost efficient, can be configured to produce three products at one location. As you can see, this seems to be a pretty brilliant way to add a high degree of user customization, while keeping a universal structure by which everything works. Or, in other words, to create an array, you plop down an array object into the grid and you can define the object with name/value pairs:
Looking back at the diagrams on the original post, maybe Trevor Chans system is what could be adapted, and this is what you are talking about with "Custom UI parts". As a factory/store owner, you know something is properly configured when the colored progress meters start filtering their inputs to the next module in the supply chain, and your finished product appears in the bar across the top. In essence, that is all the "debugging" you need.

bump because the new scripting language would only need a GUI implementation for this suggestion to work

I just watched LT Update #14 where he discusses the matter transfer beam. Specifically how the color of the beam was an indicator of storage capacity. Similarly then, those links in the 9 square grid could be color indicators of operating efficiency or capacity?

The way efficiency of manufacturing is represented in the Capitalism game is the number 1-9 in the upper right of each block. Capacity is the brown bar at the bottom of each block. In the case of leather belts; the inputs for steel and leather has little, or no brown bar, and their level number is low. That means, very few inputs are being purchased and need to be in brown bar storage. This makes sense, when you look at the somewhat efficient level 4 manufacturing unit of the belt. It has a full brown bar. It's capacity is full so it can't make any more belts and store them.

Either the price of my belts is too high, demand is too low. Whatever the problem, not enough belts are being sold per day and they've piled up, causing the manufacturing to stop. Therefore, this tells me I have to do some other trickery, like run an advertising campaign, sell to a different market, etc... Something to get the belts flying off the store shelves at the retail location. When belts get sold at retail, it pulls belts from the manufacturing brown bar, manufacturing ramps up, more inputs will be purchased, and the efficiency of the input units will also climb. It's a pretty amazing system I think, telling you a lot of info. Once you know what all those bars and number mean, they determine a course of action you need to take with consumers.