biocomputation

I wanted to add: I skimmed your paper and slides. Your work is very, very interesting and well thought out. I'll take a deeper look when I'm not so tired.

One important thing: in your slides you write that data flow is underpinned by graph theory.

You are absolutely correct that data flow diagrams (whether a directed graph, directed acyclic graph, etc.) are underpinned by graph theory.

But the critical issues of visual programming are an algebraic problem, not a problem of graph theory. If it were just a graph problem, then you'd maybe be able to write a tool that allowed you to diagram an abstract syntax tree and you'd be done.

When I say the problem space is algebraic, I mean the problem space of computation ultimately involves sets of operators and operands that define an algebra, and the boundaries of this algebra determine what kinds of problems your data flow language can solve.

I've found abstract algebra (the notions of identity, commutativity, associativity, and closure) to be particularly helpful in breaking these problems down. I've already discussed closure in my longer response to you, but the axioms of identity, inverses, and commutativity are very useful for building strategies to handle type conversions in visual programming.

> What if the input is the right type, but doesn't have the right count for the expression?

Let's say you have type T. T stores one or more pictures. Let's say you have a vertex in the vertex-edge graph that wants an input of type T, but it also wants a T that stores a specific number of pictures.

You can ensure basic type safety by requiring an input T for the vertex, but you cannot ensure expression safety since T satisfies the type safety requirement, but not the requirements of the expression represented by the vertex.

In your initial remarks, you mentioned type safety as a relatively easy thing to do, but you neglected to mention expression safety, which is equally important.

That a vertex wants T is trivial. That the underlying expression wants a T with very specific properties is decidedly non-trivial.

Additional remarks:

>> You should only be able to connect vertices (i.e. functions) when their argument/value types are compatible.

This also doesn't handle type conversion, which can be exceedingly complicated in visual programming. Should casting be done by vertices? Should you allow implicit type conversions at the vertices? Should the visual programmer be able to choose? I only ask because it is incredibly tedious and frustrating to work with data flow computation tools that say they make things easier, but then have all these super strict requirements about what can be plugged into a particular vertex. Strictness MURDERS expressiveness, and programmers LOVE text because it's super fucking expressive!

>> You can keep the language design simple. You don't need special constructs for things like iteration and conditionals.

Yes, ideally, you can keep things simple, but you will need to address things like iteration, recursion, and conditionals. Here's why: the REALLY hard part about visual programming is determining how to strike the right balance between the 50,000 foot view and the microscopic view. Many programmers complain (rightly) about visual programming because they feel stuck at the 50,000 foot view and it's incredibly frustrating. On the other hand, doing iteration and recursion with visual programming tools is often very painful.

I'll write a bit more about why.

To this point, you could make everything work with functions -a 50,000 foot view- but this quickly becomes very inconvenient because it makes it incredibly tedious to solve many types of problems. You'll be forever wrapping things up and trying to decide on the right function boundaries or how large (or small) to make a particular chunk of computation.

So then you go ahead and do iteration and recursion. Now your simple vertex-edge design might need a stack, or at the very least, it might need to understand that parts of its computations aren't going to be directly represented by the data flow graph. Now we run into some interesting problems that we can explore using notions from abstract algebra.

A data flow graph works best when every element of computation is represented directly in the graph. But if we're using iteration and recursion (using them to prevent us from being inconveniently locked in to a 50,000 foot view of our problem space) then our data flow graph is no longer closed. Problems arise because important (critical) algebraic axioms are no longer satisfied.

By closed, I mean that there are elements of computation that are outside the set of data flow nodes (here, the word 'set' refers to the data flow nodes from a set-theoretic perspective). The initial conditions of a for() loop (the initialization expression, condition expression, and loop expression) are represented in the data flow graph, but there aren't any data flow nodes for any subsequent iterations. Since this is the case, how would the user work with them? What about iteration that doesn't use for() loops? Those are much easier, but it doesn't solve the incredibly difficult problems that arise when the data flow graph does not contain all the elements of computation.

With our loop situation, we have to look at a very common use case with respect to loops. Often in a loop you'll do some work, but you might also write a value to an unrelated variable or object that you're going to use later. Right? You might initialize something at a particular point in a loop assuming a particular condition is true or false or if the loop counter is a certain value. Since all those loop iterations -elements of computation- are not in the graph, how would you allow a programmer to capture a value during loop execution? This might seem like a nitpick or corner case, but it certainly is not, and these kinds of shortcomings are exactly what programmers mean when they say they don't like visual programming.

These are some of the most seriously difficult parts of representing computation with data flow graphs.

*

I hope you'll post on HN when you have something complete!

Type safety isn't nearly as simple as you think when it comes to visual programming.

There are lots of expressions/functions that need more than "Is the input the right 'type'?" What if the input is the right type, but doesn't have the right count for the expression? How do you deal with that? There are ways of course, but it's not so simple to figure out an elegant, scalable solution.

<< And with a good enough type system, you don't need object orientation.

This might be true, but object orientation is a great way to have a good enough type system.

<< Version control and project management can also be done graphically.

Yes, but it doesn't make it better. For example, in many applications you use a stream of commands and operations in the GUI to get a job done. Operations in the GUI might include things like selections, etc. In visual programming, you might convert that stream of application commands to a set of nodes. It's simple enough at first, but it turns out that things like selections -even selecting a row or two of data- are very, very tedious to do with a visual programming tool (when compared to just doing it in a GUI). What often happens is that you end up duplicating work you'd do in a more standard application by adding dialogs that allow the user to select the data using a standard GUI process and then capture their selection in the node that stores the operation. It's a bit redundant, and it doesn't get around the fact that you're still using a standard GUI to deliver a nice user experience.

There's also another issue with visual programming using vertices and edges.

When you write code, you might declare a variable. Then later on in the code, you refer to that variable. In a vertex-edge model, there needs to be a connection between the variable declaration and anywhere the variable is used.

A vertex-edge model can get ugly and become 'hard to follow' quite rapidly. You have all these inconvenient locations for things, and it can be difficult to try and comprehend a vertex-edge model for some types of code / processes / problems.

Some things are definitely better in a vertex-edge model of computation, but a vertex-edge model is not always more user friendly or more productive for many types of work.

Source: have worked on very popular visual programming tools. I love visual programming for some problems, but I am aware of the many, many, many pitfalls in this approach.

Totally agree.

Amazon's problem is that it has a very large surface area. To competitors, that can be a feature or a bug.

<< funding companies which employ foreigners in their home countries.

Those foreign companies should benefit their foreign founders and local economies. Not every economic benefit needs to accrue to the US.

>> Hired as junior dev for super cheap, got a lot of great mentoring at 3 different, then learned enough to keep progressing on my own.

Yes, and I'm saying that there should be a similar path for American citizens who want to get into tech. There is more than enough money in tech to hire and train American workers.

We're talking about companies with a combined market value that is more than the GDP of Russia.

My comment should have been clearer. By 'train' I mean train applicants who are somewhat qualified, but not fully qualified.

There are 2+ decades of anecdotes about poorly qualified programmers from India and China arriving here as H1Bs. The poorly trained Americans should be getting these jobs instead.

My comment should have been clearer. By 'train' I mean train applicants who are somewhat qualified, but not fully qualified.

There are 2+ decades of anecdotes about poorly qualified programmers from India and China arriving here as H1Bs. The poorly trained Americans should be getting these jobs instead.

My comment should have been clearer. By 'train' I mean train applicants who are somewhat qualified, but not fully qualified.

There are 2+ decades of anecdotes about poorly qualified programmers from India and China arriving here as H1Bs. The poorly trained Americans should be getting these jobs instead.

It would be better if the jobs the created were performed by the many qualified American citizens. The 'lack of qualified Americans' is a total lie.

This is, and has always been, about labor arbitrage, plain and simple.

I always ask the same question about huge American tech companies. They have almost unfathomable amounts of cash, but complain about the lack of qualified American talent. If there really is a shortage of qualified American talent, then American tech companies should use some of the cash to train American citizens.

H1B and similar really are about labor arbitrage. It's amazing that anyone thinks the best paid jobs in America should go to hundreds of thousands of foreign nationals. (There are hundreds of thousands of H1B workers in America right now doing jobs that Americans are imminently qualified to perform.)

Not to mention, non-profits are exempt from the annual cap on H1B. This includes virtually all hospitals and universities. If Democrats are serious about the middle class, then they really should do something about this.

The comments are for discussing HN submissions. As written, the article is yet another data dump on CNNs. There are a lot of these on the web already, and I don't think this explanation is better than what already exists.

I stand by my comments.

> You on the other hand didn't give any better alternatives on your "rant".

I don't have to provide better alternatives. Note that my response did provide suggestions on how to improve the article.

I actually don't think this is a good explanation at all. I'm not saying it's badly written, just that it's not a good explanation for the stated purpose (serving as an intuitive explanation).

To this point, the article is certainly NOT intuitive if you don't already understand image convolution. The explanation is also very long and rambling. While I understand the author has made an effort, I don't think the article really presents the subject matter in a new way: I can learn all of this elsewhere. This is a common problem when people write about complex subject matter without fully understanding the knowledge gap between teacher and audience.

If I were the author, I might try to read up on technical communication and spend some time figuring out how to correctly simply something. As it stands, this article using the typical strategy of information hiding to simplify the subject matter. The problem is that information hiding doesn't doesn't work very well unless it is expertly done. I do like the animation, but again, it only serves to show how image convolution works, and doesn't actually teach us anything about a CNN.

I would suggest the author break the document into three separate sections, the first being very simple (maybe start with the part that says 'images are just matrices') and then add more details in each section. The final section would have a lot of detail. That way you counteract the information blindness that occurs from simplification by providing the information later.

Otherwise, this article is really more of a data dump than an intuitive explanation, and since it doesn't really teach us anything we can't learn elsewhere, I don't see what it contributes.

A cleaner explanation, expertly prepared, could really elevate the effort that went into this.

This made me laugh!

Neat, but I don't think this is going to help them sell more hardware.

I'd write something here, but I'm afraid to get sued.

I always find these articles interesting, especially the idea that most psychopaths aren't particularly dangerous. If we look at mental illnesses as a whole, I feel like untreated depression and bipolar disorder are FAR more costly for American society.

Also, I think it's somewhat dreadful that the tech industry seems to elevate/celebrate psychopathic traits such as ignoring rules, impulsiveness, and lack of empathy. I'm pretty sure that are people with psychopathic tendencies at the top of the ladder of some of the giants.

<< But it's meant to be a useful introduction, not a novel work.

Yes, except it's really a copy/paste job from learnopengl.com and other sources. It's actually not a useful introduction since it just parrots stuff that is already available on other sites.

More and more I'm noticing "blogs" and "articles" that feel like repackaged content from other sites. This article seems like a regurgitation of information from learnopengl.com, and as such it doesn't feel noteworthy or even interesting.

I'm all for cool OpenGL stuff, but there are much better examples of novel graphics stuff on places like shadertoy.com or https://experiments.withgoogle.com/chrome?tag=WebGL.

I love Sublime.

I'm not sure what to say about the belief some people have that 'we need releases twice a month' for a stable, high-performance product. I don't want or need product releases twice a month unless there's a good reason.

I feel like the regular releases crowd is mostly cargo cult driven by a desire to emulate the big web companies who are constantly - and often infuriatingly - tweaking their products for whatever reason.

From what I can see, this desire/need for constant tweaks arises mostly because web companies tend to ship very buggy products, and because there seems to be this belief that a company is going out of business if their web page that doesn't change often enough.

<< Information wants to be free. People should stop fighting it!

That's why you routinely publish your bank account, social insurance, and credit card details online, right?

No one should be forced to become a computer programmer just to satisfy some notion that companies should be 50% men and 50% women. No one should be forced to become a nurse just to satisfy some other notion that there should be equal numbers of men and women in nursing.

It's also not wrong to say 'maybe we should try to make our company more representative of society'.

>> But if the difference is due to expressed preference, its fine and we should all chill out.

The problem is that systemic prejudice causes long-term harm to human society. Women whom make less simply because of their gender have access to fewer opportunities. So do their children. They retire with less. It goes on and on...

For many people this issue isn't something that can be summed up as simply as perhaps you would like. It has real, long term consequences.

>> At the risk of sounding sexist, I will say that conflating race and sex as being roughly the same level of difference is a little bit intellectually dishonest. I'm not going to sit here and argue about what those differences are, but sex hormones most certainly affect behavior and emotions far more than skin pigments.

It is just a simple fact that the 'biological differences' argument has been used to justify great evils like slavery, eugenics, and sexism. Pointing out that 'biological differences' is a suspicious argument, and for good reasons, is not the same as conflating race and sex.

>> I also appreciate you sharing your story, but I personally find it a bit uncomfortable that these sorts of posts need to be qualified ("As a gay man..."). While I understand you were trying to support the point you were making, this sort of thing feeds into the notion that some opinions occupy a privileged position within our society, which feeds such "screeds" as this. It's almost hypocritical in a way, because I imagine that the anger and "otherness" that oppressed or minority groups feel is not unlike what the author of such a rant is feeling. Basically when it comes to cultural discourse, you're wrong, evil, the enemy, or ignored.

As a gay man, I have had real financial consequences (and other consequences) in my life as a result of millennia of other people's opinions about something I don't feel like I can change.

I feel like there is a reasonable and direct parallel between that and my expression of empathy toward women who experience real financial consequences (and other consequences) as the result of millennia of other people's opinions about something they also can't change.

>> because I imagine that the anger and "otherness" that oppressed or minority groups feel is not unlike what the author of such a rant is feeling.

The author could have chosen a better argument. As it is, the biological differences argument is fraught with peril. I'm sorry if the author of the rant is experiencing a feeling of alienation and otherness - it's terrible when anyone is oppressed, including men.

But it's important to remember, that, for most of recorded history, the oppressor of most men has been other men. Not women.

Amazing. Thank you for writing this.

>> The problem is that they do it in the extreme. They want to achieve 50% of male and 50% and currently that distribution is not real, there are much more men that women in technology. So they have a positive discrimination for women to get a position even when there is a man that fits better, so they can achieve the 50/50.

Yes, but women are 50% of our society. Why would it be wrong to try and make a company represent society? The world is absolutely full of utterly brilliant women.

First you say this:

>> for that sexism play A role, not the ONLY role in creating the gender discrepancy

Then you say this:

>> Yet of all the women I've known most weren't driven to excel to the same level of most men I've known.

I'll give you the benefit of the doubt in that I'm going to assume that it wasn't your intention to make a disturbingly sexist remark in a discussion about sexism.

You can replace women with African-American, and what you wrote sounds an awful lot like the racist drivel that came out of the South for 200 years. If anything, the author of the memo's attempts to argue that there is some biological basis for discrimination only serve to weaken his position. Furthermore, this 'biological differences basis' for discrimination eventually leads us to eugenics if taken to its illogical extreme. And yes, people have taken it that far in the not so recent past.

In the cases where what you wrote is even partially true, that some women (appear on the surface) to be less ambitious and less driven than men, did you ever stop to ask yourself why?

I've worked in tech my entire career, and I've witnessed appalling sexism. I have watched with my own eyes while women suffered humiliations like being told things like "no one invites you to meetings because you can't keep anything secret". Then there are things like code reviews. At work we recently had to institute a 'no abusive code review' policy because a small cadre of the men were using the code review process to hammer several of the few female engineers we've managed to somehow convince to come work for us. Like most places, our workplace policies are required largely due to behavior that was originated by men.

It seems like it's awfully easy to forget that women are half our species! How can anyone in their right mind think that sexism, unconscious or otherwise, is okay? How can anyone think that it's because 'women are less driven to succeed'? How can anyone think this when half their DNA comes from a man and the other half from a woman?

As a gay man (a gender/sexual minority), I can actually relate to how awful it feels to be treated like a second class citizen simply because of something that I do not feel like I can change (my sexual orientation). I'm not sure how much money it has cost me, but at the very least it has cost me the difference in filing single vs. filing jointly for the first 17 years of my marriage. Women pay similar costs when they're paid less over the course of their career, and/or when they're denied promotions for 'being ambitious'.

The attitude that underlies your comment -that you could actually believe that what you wrote is true and somehow justifies unequal treatment- is utterly, totally, and exactly why we need the programs the author of the now infamous memo argues against.

Cool site. C++ graphics programmer here. I would like to add that knowing one thing extremely well - even a fairly small thing - can have amazing results in interviews. I can write just about anything, on command, in GLSL.

This has gotten me more interview offers and job offers than I can count, and it really didn't take me all that long to learn.

I hate to promote memorization, but honestly, it works. Some people argue that memorization isn't the same as learning, and it's not. But it definitely helps you learn and increases understanding.

This 'article' starts out with the following generalization:

>> Most people a few months after taking up programming will reach a certain point where they feel they are the best at what they do.

I don't think this is the least bit true. I think the opposite is true. After a few months, there will be a small cohort who believe they are well on their way to mastery. I'm not sure that 'most' people feel this way after a few months of programming.

These 'lite' articles are starting to infect both Reddit and HN. I'm all for short pieces, but really, this is like buying a bag of chips at 7-11: it's all air and no chips.

>> If what is lawful differs from what is most conducive to human flourishing, it is the law that should be changed.

If we're talking about laws being conducive to human flourishing, then the law is perfect as is, and in fact, should have even more teeth to make it easier to enforce.

The current law is designed for the exact purpose of human flourishing. Specifically, the flourishing of ALL the citizens of California and visitors thereto.

The law, as is, prioritizes the flourishing of millions of people over the flourishing of a very few extremely wealthy individuals.

This is a textbook example of a good law.

>> isomorphic argument

>> Public beaches are a good thing, but it's wasteful to ban ownership of all 840 miles of California coastline. Some people want private beaches, even if the law doesn't allow for it. They'll lock gates, block roads, and otherwise shirk the law to get what they want. The state then must then expend significant resources discovering and sanctioning these people.

>> A better solution would be for the state to tax private beaches. That would collect significant revenue from people like Khosla while still allowing only a small fraction of the coast to be privately-owned.

A better solution would be to change the law so the fine for blocking access is computed relative to net worth, and to allow for collection of all court costs related to enforcement and collection.

That way the state could fine Khosla $3,000,000 a day for breaking the law, plus make him pay the bill for the legal actions required to collect the money. Failure to pay the money would result in foreclosure of his property.

People like Khosla need to be reminded that they are just like the rest of us.