ericHosick

It seems like they've done all of this at a surprisingly low cost.

1 million assembly hours at 370 million project cost = 370 Euros/hour (assembly + management overhead costs).

but only because he admitted he knew little about the subject matter...

The root cause problem is entities that have a monopoly on defining what is initiation of violence.

This incentives the criminalization of non-violent acts which provide both financial and political advantages.

This is cool because one of the most difficult things to do in these types of systems is represent context of a program at any given time: especially when most programs maintain their context using the stack (plus quite a few other abstractions depending on the programming methodology).

Using a spreadsheet as your "context" is one way to solve this problem.

I sometimes think (maybe hope) that the purpose of sending Voyager into deep space is to, some day, give someone an excuse to make a quick detour to pick it up and bring it home.

I'm a US citizen (ông Tây) who lived in Saigon (legally) for ~12 years (2001-13) and spent time in Ha Noi and all I can say is that Saigon and Ha Noi are really different.

It seemed that people who loved Ha Noi did not care for Saigon and visa versa.

You seem to be in the Ha Noi group.

Saigon is a worthy place to visit full of people from different parts of Vietnam and around the world. It is culturally unique.

To put this in perspective, as of 11/2014, the aggregated computing power of the top 500 supercomputers is 308.9 Petaflops (http://www.top500.org/).

It would be really helpful when presenting at Events.

A lot of events record the presenters screen and the presenter but expect the presenter to stand in one spot so they don't need a cameraman.

So, it does not work very well to point at a screen when presenting.

Line numbers are really helpful when presenting code at an event, in a meeting, etc.

The distance between geosynchronous orbit and low earth orbit is huge. One is ~22,236 miles and the other is 99 miles to 2,000 miles.

Would you have time to chat, perhaps an hour, on language design? Email address is on my blog which is in my ycom bio.

> because the road is no longer predictable

It will never be fully predictable: people make mistakes. It is always safer and better to assume that someone will do something unpredictable like run a red light. It could even be because of mechanical error.

When riding motorcycles in ~~Asia~~ some asian countries (did it for 6 years), you assume that people will run the red light. It happens, during rush hour, 100% of the time.

So, you drive appropriately and it is safer because of that.

Edit: changed Asia to some asian countries. I didn't want to be specific but ended up being to general which was wrong.

You could stick it in /dist/index.js.

You could also make /dist/index.min.js.

> The criticism about allowing routes to repeat in the express array shows that even after doing all this work, the Netflix team still doesn’t understand how express works.

Wouldn't a better solution, in this context, be to aggregate values under the same key?

People seem to greatly undervalue the importance of aligning incentives with desired outcomes.

How similar is this to Flow Based Programming by Paul Morrison?

> Critical thinking and problem solving do not require programming with control flow

Ya bad choice of words. Control flow requires critical thinking and problem solving (but critical thinking and problem solving is not always about control flow).

Hmm. Though, I guess if you go way deep, every decision we make is based on two or more options.

> These people are certainly capable of critical thinking, abstraction, problem solving etc.

Ya. But the way they think critically, their internal mental model, might be totally different than how you are I think. So, we all may come to the exact same conclusion. Just through a very different thought process using different abstractions to represent that critical thinking.

Ok, I see what you are saying now. I really agree that there is no difference really between programs and databases. It really is "how should we model, query and update our data."

So, ya, the question is "How do you pass information between sub-routines". Databases aren't expected to do much data manipulation between sub-routines. Programs are just wow so many ways to do it.

Thank you for taking the time to have this discussion.

> 'Visual language' is a very overloaded term and

All great points and I agree with them.

> Pretty much the only hierarchical example that comes to mind is Scratch.

I tend to lean towards Sean's post: https://news.ycombinator.com/item?id=8468838.

> non-local scope and control flow

I read you are going for an "Excel" type approach. I thought you were doing this to deal with non-local scope. I hope so because I think it is a good idea.

> are also pretty hard to represent and understand

Control flow is also really hard to represent but I don't think it is because of any aspect of the visual representation or core technology. You can remove coding from programming but you can't remove critical thinking and problem solving from programming: which is basically what programming is.

Control flow is critical thinking and problem solving. That is why when you "presented our prototype to a small number of non-programmers and sat back to watch the magic. To our horror, not a single one of them could figure out what the simple example program did or how it worked."

It is because there are inherent mental models that we use as tools to solve problems and think critically. People need to be given a visual representation of control flow in a way they are familiar with. I'm guessing you guys have done an amazing job (I've seen light table).

Frankly, I have a lot of experience in this space. I've spent ~5 to 6 years studying it and building out tools. I recognize a lot of the pains you are going through because I've been there. I would be more than happy to chat with you about it. I am totally stoked about Eve and would like to help.

> understanding code so it makes sense to default to visualisations that optimise for the latter.

I may be totally reading this wrong but you should not default visualisations to represent a given program. In my opinion, this is a mistake that all VPLish type things have made (as you said, it is a totally overloaded word). You can easily represent a given small part of a program in any domain you like: using the same underlying program. It could look like a mathematical equation to a mathematician, textual code to a programmer or process flow abstractions to someone in logistics.

This is one of the great strengths of hierarchical type programming languages: the same code can be represented using multiple visual abstractions tailored to the user.

This is why I totally agree with this statement "The environment should be optimised for the way that people use it, not the way that we think it should be used."

but think you should reconsider this "We should observe users and collect data to discover common actions and workflows." There are no common actions or assumptions you can make when going visual because there are so many different ways people approach solving a problem.

Programmers are only kind of aligned because we all go through this grinder that requires us to fight with compilers and figure out error messages and deal with syntax and so on. So, we all kinda mentally solve problems in the same way (and by kinda, it isn't like close but a lot closer than say an accountant and a painter solve their problems).

I hope this isn't too long winded but I really do have a lot of knowledge in this space.

> but it does have hierarchy defined by callee/caller relationships. If you have any kind of hierarchy at all in your program execution (even if its just rules being used to for other rules...), you can leverage that as a "scope."

This is so true. You can take advantage of having access to a "parent" to change context. It allows you to re-use your code by just accessing information from your parent. It does lead to some coupling (it limits what types of parents you can have) but it does let you re-use code.

And hay Sean!

> You can't parametrise a function using only global scoping. So then we ended up with both a stack and this global table lookup thing.

Exactly. So, just write your functions so they don't use parameters (expect for persistence of the program). In fact, you can bypass functions all together. It also makes it a lot easier define and visually represent behavior.

> Another reason we weren't really satisfied with any of the hierarchical models because they required making lots of choices about ordering in the hierarchy that weren't really relevant to the actual problem being solved.

Hmm. Interesting. Could you give some examples? I would think that the hierarchy would be built out organically as you build out your program. Unless the hierarchy is actually just data that the program manipulates. Then, I could see it as an issue. But if the hierarchy is your program it should just grow organically.

> We don't have a solid plan for handling reuse but we haven't actually felt the pain yet

From a hierarchical standpoint, re-use (I'm guessing code re-use) is really about being able to change context by moving or executing part of your hierarchy (since a program is just a hierarchical composition of objects) in another part of your hierarchy. This is a little more difficult but can be done implementing another scoping mechanism.

The way we do scoping now is to rely on the programming language which is basically the stack.

But we can implement our own scoping mechanisms based on the domain we are developing a program in.

For example, Eve mentioned that they were looking at a sort of "Excel" spreadsheet type visual language.

The scoping mechanism of spreadsheets are a sheet with row/column. So, I would create objects that are able to quickly pull from a row/column and push into a row/column. For example, somewhere in their hierarchy they had an algorithm that required access to a cursor.

Since it is a spreadsheet we can have our global active spreadsheet which, somewhere, contains the cursor. We know it is there because we put it there.

Somewhere deep in the bowels of the data hierarchy we have this line of code to get a cursor:

    var cursorCurrent = global.curSpread[34,65];

because our scoping mechanism is based on an excel spreadsheet and not the one "forced" on us by the programming language: usually a stack.

There is no need to push that current cursor down the function calling train and, in the end, it is probably faster because we are doing a simple cell lookup.

The context of the discussion is the representation of state within an executing program.

Xml database, key-value-store, relational databases, csv files, etc. are all ways of persisting.

These are very different disciplines with very different problems being solved.

They are going for a visual language, and visual languages are inherently hierarchal. The goal is to easily represent context of any part of a program in a visual way.

Trying to map source-code that stores a lot of it's context on the stack is really hard to visually represent. Trying to represent the stack in a visual way makes for a icky looking visual language.

However, if you can keep all of the context/state of your program in one area and it is hierarchal... Then, you can build great visual representations of your program because, really, you are displaying a data-structure (your program becomes a data-structure). So, all the cool things you can do visually representing data-structures, you can do with your actual program.

>Passing cursors quickly became tedious when trying to change code. If a function suddenly needed access to IO the cursor had to be passed down through every function above it in the callstack.

This is the function-calling train issue and what happens if you try to make a sort of quasi homoiconic language ("Hierarchical organisation of data complects the data itself with the common access paths.") and attempt a push-pull approach to programming (you push the data down into the hierarchy) with traditional data scoping through parameters.

The bad is not the hierarchical organization of data. That is the correct direction.

The bad is trying to use a traditional scoping approach to what is effectively a homoiconic type language. Homoiconic type systems need a different scoping approach.

I tried the Language Identification service (http://ibmlaser.mybluemix.net/liddemo.html), put in Vietnamese from wikipedia and "en-US" returned.

I did sign up. Note that in incognito mode, I have access to that link. I am guessing others do too.

Ya. Exactly. I like that term.

"JavaScript can be the native format of your data"

I don't think developers appreciate how amazing this feature is in a language.

Code should be a data-structure giving you all the benefits of data-structures including persistence.

I think a majority of people (80/20 rule or even 90/10 in this case) have great intentions. Don't read into what I said as not having "faith".

Good intentions don't yield desired results: especially when people have very little understanding of the consequences of their actions.

An attitude? This stuff seems to happen again and again throughout history. Me asking this may bring root cause problems to the conversation too.

You would think the world view of a large number of people would have changed considering things like the cold war with the U.S.S.R, Iran-Contra, Bay-of-Tonkin, etc. If it had, mass surveillance would be a lot more prevalent in every day communication.