This guy (Neil Fraser) wrote https://github.com/lqc/google-diff-match-patch right before joining Google, which is an incredibly useful foundational library for realtime synchronized text editing. He was very influential in open source work on realtime sync until going to work at Google, when he just sort of disappeared.
Blockly has been a reasonably widely-used open-source contribution, especially given that it's mostly a one-person project (the last time I checked, but that was a few yrs ago).
"My biggest contribution so far at Google has been Blockly."
Nice - https://developers.google.com/blockly/ no real fan of google, but the tools and code churned out by individuals there is pretty interesting. This I will play with.
Blockly is awesome and often overlooked. It realises the idea of a real time scripting language, and should really be the thing devs reach for over flowcharts when they decide to implement a visual programming environment.
I saw the exact same app circa 1996 sans the web stuff. Our professor was trying to force this on us because it was his big research idea. It's not overlooked, just a really old idea that didn't pan out 20 years ago.
"it looks horrible and cluttered and wouldn't like to look at a complex version of this over flowcharts"
You are right.
It looks horrible and cluttered and could be made better. Though visuals and design aside, the idea is sound. There is a real barrier b/w textual/visual in software. You don't see this in other physical disciplines like EE.
It would be interesting to have a better (easier to read, standardised etc.) version of these flow charts. Not impossible and possibly easier to trace, explain and see alternatives/improvements in design.
There have been very many attempts. Scratch is a pre-cursor to Blockly[0] Code.org has an in-house build on top of Blockly[1] and then there are mobile apps like Hopscotch & Tynker based on Scratch[2][3]. There's also full-fledged game engines like Stencyl[4] based on Scratch as well. To be totally honest, the whole paradigm looks cluttered and illegible to me, and I've been researching learn-to-code environments for quite some time.
I'm not so sure "it could be made better".
That's not to say I think it's a lost cause: I think it works great for short, 5-10 line programs. Once programs grow larger it becomes very hard to reason with, like with most VPLs.
Just for the record I have to add snap to this list, which is the only one that worked with my kid. It's like a much cleaner alternative to scratch, as a single JavaScript page designed to world offline too (which I've found to be a requirement for a distraction free environment).
"That's not to say I think it's a lost cause: I think it works great for short, 5-10 line programs. Once programs grow larger it becomes very hard to reason with, like with most VPLs."
Interesting comments. I'm not sure about the failure on larger programs. The idea of these visual languages is to allow different learning styles and a quicker way to absorb the program details into your head. The best understood programs are the ones we can hold in our heads.
Yet it isn't too hard a visual problem to show complex situations graphically. You do this with scale. EEs manage to show complex logic in circuit diagrams (and other diagrams for states) so I see no reason why more complex programs cannot be shown graphically. (cf: background in technical graphics/cartography/gis/programming).
The biggest limitation is the way programmers think. They convert textual code and parse it in their head. Aside from logic diagrams, flow charts (and others) I don't think 4GL programs have really taken off because the source code is the most efficient way to write, read and show software.
When it comes to graphics programmers don't natively grok graphics as they do text and shun such tools. I've noticed that I have to switch modes of thinking text when programming, then graphical for other things. It's a hard thing to do and the precision of programming breaks my ability to visualise and draw.
The scaling idea is simple. You have blocks of code that are represented as Blocky. As you look at more aspects of the program, you scale out and see a smaller scale view of the code represented visually. You do this with maps all the time. The complexity of the data is orders of magnitudes of the landscape is more complex with respect to software. You zoom in and out of the landscape as needed to understand, measure or picture the lay of the land.
The key thing I get from this is the union of primarily textual programmers to people wishing to visually understand has a shallow overlap.
I've done a lot of research into other VPLs as well, and in theory, all of these ideas are sound.
Unfortunately, it seems like VPLs only work well for well-defined domains (say, a VPL for shaders, a VPL for compositing, a VPL for EE, a VPL for business logic)
Once you try to go general, and add "zooming in" and "zooming out" mappings, the number of ways that people would prefer to visualize each becomes exponentially more complex to display/interact with; so much so that then simply using text seems like a general-enough solution.
I'm still hopeful that a general purpose VPL could exist and work for 'real' programs, but so far my search has come up empty.
A good reference list to look at for existing VPLs:
"Once you try to go general, and add "zooming in" and "zooming out" mappings, the number of ways that people would prefer to visualise each becomes exponentially more complex to display/interact with; so much so that then simply using text seems like a general-enough solution."
Thanks for this insight. Agree with "text is good-enough". The link is like a list of approaches not to take. IFTTT, minecraft and openmusic appear to do the job.
The problem I'm thinking of is creating geometry using a combination of GUI manipulation -> geometry ->code to allow tweaking for n00bs, straight code -> geometry with GUI manipulation. These examples really help.
I missed/mis-understood this bit. I think of the visual side as another slice of how code is constructed/works/understood. I've limited experience of VCL (windstorms) and thought it was terribly clunky, got out an editor and used text.
Visual coding has a place in geometric construction. This has to do with feedback maybe less so on understanding code.
From the about page: One of the limitations of Scratch as a language for computer science education is that its lists are not first class, so you can’t have a list of lists. Making lists first class is enough of an extension to Scratch to allow the creation of any other data structures (trees, heaps, hash tables, dictionaries, and so on) in user-defined Snap! code, implemented as lists of lists. via https://snap.berkeley.edu/about.html
Something I thought about while looking at this: How come the code is made "material", but the variables and "objects" of the code are still abstract/just named? Have anybody thought about how to make the data objects more real as well?
The 'flow' is "materialized" [using your terminology] since everyday intuitions accessible to anyone can serve as guide for 'assembling' an algorithm. For objects, we are talking structure, mostly. If you require that higher level of (semantic) expressiveness it seems at odds with using something like this. We can manifest a object (or structure) as a (say) box, with slots. But if you are doing that, shouldn't you just upgrade to Python?
As someone with a few years in the industry who's currently volunteering to help teach high school kids coding for the first time -- you have no idea how easily code confuses newbies.
Take even the smallest snippet:
while (Count <= 3) {
To you or me, this is pretty obvious. I've had kids ask me questions I'd never have thought of because I know this stuff already:
* What do the parentheses mean?
* What is Count, is it a Javascript thing?
* Is Count being set to 3? (<= looks like an arrow, not necessarily less than or equal to)
* What is that squiggle? (meaning the '{')
* Is this a program?
I'm with you, the Blockly stuff is hardly legible to me. But to kids learning this for the first time, I can tell you from first hand experience the color/shape/block aspect makes a huge difference.
First, they need to understand that a for-loop instantiates a variable (i). Then they need to understand that the next step is a limit: i < something. And then they need to understand that i++ means increment i every time that the below code is run.
Nevermind that it makes more sense to go: i = 0, i = I + 1, i < something, that's how it works.
Of course if they don't get that, they may not be cut out for programming. But its far from intuitive.
I recognized his site for being the source of one of the most inspiring posts on the potential for what CS education could be: https://neil.fraser.name/news/2013/03/16/
"""The CS teacher was excited and promised to teach Blockly the next day. But there was another issue compromising the class. Due to a lack of funds, the school could not afford two CS teachers, so half the school was unable to take CS. I asked what a teacher's salary was. $100 per month. So I went to an ATM and bought them a second teacher for the next year."""
Someone had built an open source graphical Perl code generator that used blocks very similar to this. Looking back in your blog you used to be a heavy Perl programmer. Was it you that did that? Where's that original project, iirc it used to be on sf or something.
My first real paying gig was for a local Pennsylvania company who distributed pBasic boards and merkur sets. They used an open source Perl IDE that allowed 3-5 graders to program the bot visually.
I didn't know Perl and was still in high school, but was able to make some great contributions (to the company version). Taught me how to manage very small amounts of memory. I owe the original author a thanks for making such a solidly coded tool.
Correct me if I'm wrong. Here of all places on the internet, an article with the title of "Ten Years at X" is expected to encapsulate some kind of intellectually rigorous narrative about the passing and the meaning of those 10 years to both the author and the organization. Or are we to assume that such standards no longer exist in order to receive upvotes on HN?
Clearly, you are wrong. People up-vote articles they find interesting based on the criteria of their own choosing. You can't expect every HN reader to share your own particular standards for what an article "should" be.
Amazing to work for 10 years at one place. The only place that comes close is working for my own company back in the later 80s, early 90's. Who stays with one employer anymore these days?
Google will keep anyone talented that's 'producing stuff', they have massive surpluses of cash.
I think a lot of people would love to work at Google for a long time so long as they fit in the culture. Who wouldn't want to work on fun stuff that the word is using?
And a high, stable income is the next most valuable thing after stock options in a high flying company :)
What are the alternatives? A startup wherein you will likely lose your job? Oracle? Cisco? Probably not nearly as interesting.
Alt career choice? Might cut their salary in half ...
Maybe a different way to frame it: why would they leave?
I wouldn't even like to work at Google, but I have no trouble understanding why people would park there for a long while :)
Kudos to them for providing a place for so many talented folks to create cool things.
Well, the people who stay with one employer aren't going to be writing an endless supply of blog posts on how they've been "moving around all the time and you should to." They tend to just do their job at their job instead of trying to convince the whole world that they're experienced and hirable.
The title of the article is very misleading. I would have loved to read how Google changed on the inside over the last 10 years. Or maybe even how the author changed. Instead, we get some spam about some tool that is neat.
I can't tell if you're parodying HN here. This is from someone's blog and is a personal reflection on his most important work of the past 10 years. Do you expect everyone to be an historian?
I expect an article titled "Ten years at Google" to talk about someone's experience at Google over the last 10 years, not a project that started in the last 5. If that's "being a historian", tell me why that's bad.
There's nothing bad about being a historian nor is there anything bad about writing about your most significant project in ten years. Both are aligned with the title.
Really? I found it quite refreshing. I'm tired of reading articles about people's experiences at so-and-so company for so-and-so years. Anyone working there for 10+ years can write about that.
It's awesome that Neil did something he's proud of and shared it on his personal blog. Good for him.
I'd like to see some articles like that, too though I have heard stories a few times from a few old timers I've met at company events, I couldn't hope to summarize them nor could I legally, I'm sure. There's not, imho, a massive difference in the company over the 5 years I've been there (albeit in a 'remote' office), but the people who have been there over a decade definitely saw a different kind of company.
The robot moving aspect of blockly reminds me of one of the awesome Dr. brain game (1994)[1], is there other kid-friendly games like this those 2 were inspired from?
Heh. As a programmer that types a lot, obviously, I find it really annoying when my nails get any length on them at all - especially the index and middle fingers, it feels horrible whenever your nails hit the keys before your actual fingertips.
I tend to keep a second pair of nail scissors at the office, as I can't even bear it until the end of the day (this often happens on a Monday).
Accordingly, I always find it kind of amazing / bizarre to see long nails on any other coworkers / software developer types.
I used to work with someone who not only typed with incredibly long fingernails, but he used to bore holes in them and connect them together with little chains.
