Text Is Keeping Kids from Coding - <AUTHOR> https://medium.com/@dannyyaroslavski/text-is-keeping-kids-from-coding-b70988dd7541 <comment><USER5> I actually don't know any great coders that learned to code through these kinds of games. They might move the programming-is-interesting gradient, but I don't think the hard part about learning to code is the text.

The hard part about coding is the problems that aren't in the code. Doing research, setting up environments, understanding platforms, dealing with crashes, dealing with crappy tools, debugging, understanding other people's code. None of this is taught by isolated sandbox games like this. Sandbox games might teach some very useful analytical skills, but it's pretty far from coding.

The only thing you really need to get kids coding is to give them the tools needed to do interesting naughty things. Many of the programmers I know learned to code at an early age by hacking games to cheat against their friends. Reading text was never, ever a problem, but the disillusionment of finding out that coding doesn't involve pretty foolproof user interfaces might have been.

<comment><USER6> I'm not calling myself great, but my initial introduction to programming was a Logo robot at the age of 6 or 7 in the 80s, so I'm not sure I agree with you. A turtle shaped robot we could get to draw things. All primary schools at that time usually had a BBC Micro in each class too.

Perhaps it was just a British thing. After that it was some BASIC on spectrums, some BASIC on Acorn Archimedes, then some random OO language on Amiga that I've never really been able to track down what it was called.

And I wasn't even that keen on programming, I was just exposed enough and wanted to build better games than my friends at lunch or on our graphical calculators. I remember running out of memory on my graphing calculator trying to get a working version of poker (which I now realize was wildly more ambitious than the versions of blackjack we all made).

A lot of programmers of my age will remember the turtle with fondness.

I guess all of those were incredibly simple to setup to start programming (for the spectrum it would go straight to the command line), but then again these days so's pressing F12 on a web browser to get a working command line.

<comment><USER7> My first steps I did with Robot Karol (which uses Karel as a programming language): [https://en.wikipedia.org/wiki/Karel_(programming_language)](https://en.wikipedia.org/wiki/Karel_\(programming_language\))

Fun times, I could sit there for hours trying to figure out how to build shapes like pyramids: [http://www.wschellenberger.de/informatik/inf_robotkarol/inf_...](http://www.wschellenberger.de/informatik/inf_robotkarol/inf_karol_baut_pyramide.html)

</comment></comment></comment><comment><USER8> I started my professional life as a stockbroker and I remember my mentor saying "Money Magazine does not exist to advise individuals to make great trading decisions, it exists to sell copies of Money Magazine."

I've since applied this logic fairly universally and I'm going to apply it here: SpriteBox does not exist to teach kids to be great coders, it exists to sell copies of SpriteBox.

The challenge of text undoubtedly is a blocker to the sales of SpriteBox.

I do not believe that it is a blocker to a kid becoming a great coder.

Coding absolutely requires a high level of comfort with abstraction. It requires the ability to mentally model abstractions, maintain relationships between abstractions, and make a (sorta) concrete reality of those abstractions.

Coders must be able to make intuitive mental leaps based on disparate and distributed data. Often the solutions that coders come up with are based on little bits and pieces of the puzzle based on SO answers, documentation, blog posts, example code found on github, etc. The solutions to tough problems are rarely found in a single neat all-explaining resource.

So... if a kid is having trouble with text I would candidly posit that the kid may not have the ability to deal with abstraction that coding requires. Not a problem for the industry as there are already enough coders who have this issue, but it creates a sales problem for SpriteBox.

EDIT: typo, clarity

<comment><USER9> As someone who's grown up with computers, I think the biggest difference I see between "technical" and "non-technical" people is a willingness to try things out and not be put off by intimidating new things. If you are willing to explore you will eventually figure it out, but if you are afraid you'll never get anywhere.

</comment></comment><comment><USER10> I learned to code when I was 9 years old. It was in text. No one helped me. I found a couple books with my parents computer, 'Introduction to BASIC' and understood that if I learned what was in the book, I could make the computer do what I wanted.

I don't know programming was supposed to be hard. I didn't know some adults did it as a job. I just knew that if I learned what was in the books, I could do stuff. So I started reading, and I never ran into anything that was beyond my grasp. I do recall reading one part that said a person who did not draw a flowchart before writing a program was either a genius or a fool and resolved to be a genius (hey I was 9). Not even refusing to create flowcharts prevented me.

I feel in love the day I wrote: 10 PRINT "I LOVE YOU MOM" 20 GOTO 10 And filled the screen then called my mom into the room to look at it.

Text is not keeping kids from coding. Adults are. Adults making kids think it's difficult, adults standing in the way and shuttering them into unnecessarily dumbed down environments, standing over their shoulder and making sure they don't do anything inappropriate, etc. But more than anything, adults filling kids free time and never giving them the opportunity to just sit down, have a quiet few hours, and figure things out.

<comment><USER11> "we got responses that estimated ages 9, 10 and up- "

The point is text looks too complex for younger kids. 5 year old won't sit down for a few hours and figure out things. He will just get bored.

<comment><USER12> Other than sales of this app, why is it necessary for 5 year olds to be programming?

<comment><AUTHOR> People lie on a spectrum of ability. An app that works with 5 year olds that have a knack for programming will work well with 8 year olds who may not. Striving for an app that's approachable at any age is the real goal.

</comment></comment></comment></comment><comment><USER13> I'm the dad of an 11 year old boy and a 8 year old girl.

Text IS scary, because it's nontrivial. There's a reason schools start with the ABCs and spend the first four years of school teaching kids to read. And even then we don't stop there: middle school focuses on grammar, and high school focuses on creating long-form content.

Programming is similar: it's non trivial to stand up a knowledge base to be a programmer.

I think the big difference is that most programming classes start in high school or college, well after we've mastered text in general.

But that doesn't mean it can't be done. The key is to start small: don't expect novel-sized programs, expect words and sentences, and make those words and sentences FUN.

For example, my son has had a TON of fun with the micro:bit [1], and it's scratch based system, and Swift playgrounds. [1]

[1] [http://microbit.org/](http://microbit.org/)

[2] [https://developer.apple.com/swift/playgrounds/](https://developer.apple.com/swift/playgrounds/)

</comment><comment><USER14> I dont understand why elementary school kids need to code at all. Most of the developers my age didn't even see a computer until high school or college and they're great developers.

A great preparation they should learn some math or ideally be having fun with their friends, running around outside or perhaps art or something creative.

<comment><USER15> I feel like this needs to be higher up. While of course any parent would want their child to meet and exceed any academic standards you or the school system set, childhood is the only time in your life where you're relatively free to make mistakes with friends and relationships, and that's how you learn to be a better person.

It's a lot more difficult to learn that later in life than programming, in my opinion as someone who didn't start coding until he was in his early 20's but still struggles with relationships because of a unrelated, intense academic focus as a child.

</comment></comment><comment><USER16> Your text notation was:

      move(.up)

What does the `.` do? Why can't it just be:

      move(up)

What purpose do the parentheses have? Are they essential or optional?

Why not:

      move up

Ok, you wanted it to be like a "real" language, I guess? Look at Logo and Basic. They largely eschewed punctuation (not entirely) for text and newlines and meaningful names:

      pen down
      forward 100
      right 90
      forward 50
      pen up

<comment><AUTHOR> OP here.

So yes, we could have gone the "move up" route. In fact, we did at one point! Even then though, icons were far and away less intimidating.

The problem is, real programming languages don't eschew punctuation, Logo included (once you include loops and such). AND our primary goal was to get kids familiar with reading real looking code (in this case, Swift).

The last option would be to start with "move up"s, and then introduce punctuation later... but then players would get confused as to why punctuation, unneeded before, suddenly becomes required?

Finding the middle ground of jumping from icons to textual code (with punctuation) resolved all of these issues best.

And yes, we've read Mindstorms ;)

<comment><USER16> Fair enough. I still disagree with your conclusion. _Text_ isn't keeping kids from coding, throwing them at _Swift_ 's text (in your case) was. A simpler and more forgiving syntax, or a UI (a very capable IDE in this case) that walks them through the syntax (showing them only the valid options at any given point) since you chose a relatively complex syntax would also have helped. You achieved that via pictographs transition via pictographs, which ought to be effective (you won't be changing the rules of the game on them, from their perspective, just the notation used).

Pictographs are useful, and effective. I won't deny that. But kids can, and have, learned to code with textual languages when those languages were more effectively chosen and developed for the task of teaching kids. It's unreasonable to make such a strong claim.

We could make the same claim about math and kids (Notation is Keeping Kids from Mathing!), and it would be superficially true, if you started kids off with a notation like geometric algebra (bi-vectors, tri-vectors, multi- vectors, oh my!), instead of arithmetic.

<comment><AUTHOR> The point I want to stress is that text _is_ keeping kids from coding. Like I said, even with punctuation-less text, the game was deemed difficult. Simpler and forgiving syntax simply would not help. The IDE in the game is actually extremely forgiving and could just as well walk players through the syntax, but interest levels then drop off. This is the difference between in theory and in practice.

Yes there are kids that had no problem with text or without text. Of course kids can and have learned to code with textual languages. Same with math.

The main idea here is that you can get an _even larger_ population of kids doing math and coding, and engaging, by adopting pictographs first. As demonstrated in DragonBox. As seen in our own testing.

</comment></comment></comment></comment><comment><USER17> Why is is this a problem?

\- Numbers are keeping kids from learning math. \- Text is keeping kids from reading. \- Too many words are keeping kids from listening to lectures.

I don't understand why people find it difficult to just teach a kid how to do something rather than wait for some miracle solution.

<comment><USER18> I offer my miracle solution: text is a bunch of tiny pictures.

<comment><USER19> Text started as tiny pictures. Trouble is, there's an unbounded amount of things you need pictures for. The great thing about phonetically-based writing is that a tractably small number of symbols can combine in a natural way to express anything.

</comment></comment></comment><comment><USER20> I took a break from teaching for a year, to be a 3D graphic artist, using Cinema 4D. The software had a drag and drop, node based, coding environment called Xpresso, that I became quite adept at using. I can remember showing it to my programmer brother, and he told me if I liked using Xpresso I should try a proper language. I dismissed him, saying that typing text held no appeal for me.

A couple of years later, and I was back teaching ICT and the curriculum was being axed, in favour of Computer Science, so I decided to teach myself a little Python, and ended up being a secondary CS teacher in a fairly elite school.

What strikes me now, is at no point did I make a connection between the graphical language I was using back then and the text based languages I would go on to use later. In hindsight it seems obvious that if I enjoyed controlling pixels on a screen with blocks, I would probably enjoy doing it with text. It's anecdotal, but it has turned out to be true.

In my professional capacity as an educator, I have seen how engaged young students can be with graphical languages such as Scratch, and how those same students eventually want the power and control of more powerful languages. These types of games don't teach _everyone_ how to code, but they do awaken a desire to control and manipulate computers, in people who might otherwise never have realised this ambition.

For people who say that the hard part of programming is "not in the text", watch a seven year old try to control a turtle in Scratch and then watch them try to do the same thing in Python. Typing speed is a major factor, as is understanding the importance of case and white space. Not to mention the symbol nightmare of commas, full stops, colons, semi-colons, single and double quotes, hyphens, underscores, equals and double-equals, square braces, curly braces, angle braces, and parenthesis.

<comment><USER21> You might be interested in the Luna programming language/dev environment. It's designed to have a 1:1 correspondence between the visual, node-based environment and the written forms of the code. I haven't been able to try it yet since it's still in closed alpha, but it looks very intriguing! Given your experience with a similar visual language and later interest in more conventional programming, you could make a good case for getting into the alpha. There's a signup form on their site (one for the alpha and one for their newsletter, depending on your level of interest).

[http://www.luna-lang.org/](http://www.luna-lang.org/)

Last HN discussion: [https://news.ycombinator.com/item?id=14612680](https://news.ycombinator.com/item?id=14612680)

</comment></comment><comment><USER22> > We showed the above to playtesters (kids and parents) who told > us what we > didn't want to hear: the game looks complicated.

That's because real programming _is complicated_.

Software systems, with billions or even trillions of switch points, are the most complex things humans have ever built, by far.

We have tried mightily, for many, many decades, to make programming simpler and more accessible. The problem: instructing a computer precisely and unambiguously what to do means you have to precisely and unambiguously specify...what to do! There's no getting around it, just like there's no way (yet) to write a novel without choosing words and pushing letter keys.

The graphic approaches quickly get tedious beyond toy examples. Graphs are fine for telling your Lego robot what to do, but with the Web and app store overflowing with cool apps, the bar for grabbing and keeping a would-be programmer's attention is now quite high.

My bet: non-programmers will "program" at scale when where's a fundamentally new computing model. Machine learning & deep learning are the most promising for this, I think: instead of telling the machine precisely _what_ to do (and how), you show examples of the behavior you want and give feedback when it's wrong.

<comment><USER23> > The graphic approaches quickly get tedious beyond toy examples.

The things I have seen created in LabVIEW would absolutely astound you - <USER2> just in their complexity, but in the fact that they work at all (for various values of "work"), and that someone somewhere out there is able to maintain them without going insane.

/then again, maybe there are more insane LabVIEW developers than I know...

</comment></comment><comment><USER24> Text is scary. They had the same barrier transition from picture books to books without pictures. It takes kindergarten where the set up of school give them the perception that they had no choice but to embrace the initial difficulty opened the door of wonder for them.

I don't see much difference teaching them programming with a real programming language. They have to be forced to embrace it first.

<comment><USER25> Well, to be fair programming is (currently, at least) an optional skill competing with soccer, guitar, and video games for mind space. Reading is the lowest bar for practically everything in modern life so there's more tolerance for sub-optimal teaching since we all are willing to hold feet to fire. Until coding is as ubiquitous as reading, we're going to have to do better.

</comment></comment><comment><USER26> I wonder if it isn't the text that's putting parents off, but the specific lesser used symbols like parentheses and the such. For that same reason I believe parents think that math is hard in comparison to writing, due to the large amount of domain specific iconography. I also wonder what effect leetspeak might have on bridging that gap, even though it's probably not the best solution.

<comment><USER27> That's a good point, and one reason I enjoyed BASIC and its dialects so much. Which is easier to explain to a new programmer:

For i = 1 to 10

Or

For (i = 1; i <= 10; i++)

Once you understand how things work, translating that knowledge to another language and adding on concepts is relatively easy.

<comment><USER28> This is an interesting example, because back then when I learned BASIC (around age 7 on a Vtech Precomputer 1000 [1]), I couldn't understand why the for loop was called "for". Why am I doing this "for i"? How does "i" benefit from this? I didn't know the mathematical idiom "blabla for a value of i equals 10".

I was also strangely afraid of the word INTEGER, which I read as INTER-EGER. "Integer" has no meaning to a kid, it's just called a number (as opposed to a dot-number or a fraction).

On the other hand, I never had problems with the fact that is was using text.

[1]: [http://www.vintagecomputing.com/index.php/archives/324/324](http://www.vintagecomputing.com/index.php/archives/324/324)

<comment><USER29> i read all the Asterix comics pronouncing Julus Kazar ;-)

Then repeated at post-grad chemistry when first asking a question out loud about Orger Electrons (Auger - more like Aubergine, prior to lectures introducing them) - prof was non-plussed... Reading and talking huh ;-)

</comment></comment></comment></comment><comment><USER30> I don't know for US, but here, in France, children start to really learn to read at school after preschool, around 6-7 yo. Some succeed, some have difficulties to achieve.

Of course they start learning concepts in preschool, but it's not an obligation to put your kids in preschool (most parents do, but you don't have to)

So isn't it a problem with text, reading, words... than a specific code problem ?

As a parent, I'm going to teach coding to my kids, starting next year, they'll be 8 yo. I'll start with scratch then probably some python. And I'm lucky my kids are both fluent readers. But I'll still start with scratch.

<comment><USER31> The problem isn't reading ability, it's the rigid structure of words that confuses them (this happens at any age range). What is or isn't allowed? Grammar rules are invisible at the end of the day and to be honest what does 'move(.left)' signify? Even after 15 years as a programmer I find this grammar confusing, is it shorthand for 'this.left'? shorthand for an enum? I'm even wondering if this grammar is even useful, if it doesn't look anything like languages in commercial use.

Using icons makes a lot more sense, as they are immediately recognizable pictures that come with the expectation of no structure to learn, and it looks like from the article they just simply put one icon after another in a list.

</comment></comment><comment><USER32> I routinely send large text files to people around me, I noticed many people just refuse to read pure text.

So I convert the text to pdf and add some flavor, pictures etc. Then people read it.

edit: by "large" I mean, by my standards, ridiculously small, like 300 to 3000 words top, but people are scared by simple text.

<comment><USER18> It could be a layout thing too. White space magically helps sometimes.

</comment></comment><comment><USER33> Lack of human factors knowledge in people who write software tools is keeping kids from coding. And adults, for that matter. There's a huge amount of incidental complexity and fragility that we just tolerate.

I mean, how does move(.up) look like plain English? What's wrong with "move up"? Are we really so blind as to not realise that any normal person looking at that is going to get the strong impression they don't know what the hell is going on? Hell, _I_ don't know what's going on. What's with the period? What happens if I don't type it? Fragile and incidentally complex.

Now to be fair there are intrinsic differences between typing in a blank text box and dragging and dropping icons. You can type anything in a text box, while icons present a limited selection. This hurts discoverability, which is why the author saw better results when they gradually swapped out the icons for text. Dragging and dropping is an atomic transaction which can be cancelled with good feedback if the user attempts something invalid; this is not quite so easy with typing, because valid code must be reached through invalid states on a letter-by-letter basis.

But proper coding in a Turing-complete sense (which none of the games seem to offer) involves defining your own symbols and wrestling with abstract notions like iteration that lend themselves increasingly badly to representation in sprite form. Scratch is a good example of a system that attempts to use the best of both worlds - its building blocks are text-based, but selectable from a limited number, atomically placed, and statically checked to practically preclude syntax errors. Text itself isn't intrinsically bad.

Lastly - it's a shame the industry moved on from BASIC. Programming was never more accessible than when the average personal computer booted to a REPL of a standardized, easy-to-use language.

</comment><comment><USER34> The title makes me cringe a little. It implies the text-based nature of most programming languages is a problem, even THE problem. It is, if you're trying to simply get young kids to use <insert language here>, vs get them to use said languages to interesting problems.

The problem as I see it is that parents across the country are trying to prepare their children for a job landscape which may change radically between now and when they graduate high school by getting them while they're young and attempting to introduce them to coding as early as 3. Not programming, not learning how to solve problems with an algorithmic mindset. Coding. As in getting them comfortable with slinging around functions that build a website using magic.

Really, we should be teaching them to do the thing that we're trying to do with programming languages in the first place, which is solve problems with an algorithmic mindset. I think SpriteBox gets it, kinda, where it falls short is that in the end they're still hung up by the whole "let's teach kids how to code" trap and gradually replace the icons with text and do this weird thing where icons are indented because text-based code is indented. In the end kids know how these languages work, and how to do simple things with them, but they've learned all of this within the context of what looks like a platforming game. Extending this to the act of creating something is different.

If you really want to teach kids how to program, create an environment that teaches them how to build and create something cool using a few simple and easy to understand rules. Allow them to experiment with the rules to see what happens. Make it so that the upper threshold for how you can bend the rules, combine rules, etc, is to all concerned essentially non-existent. Enable and reward creativity, which is something a lot of "coding" games and toys and whatever simply don't do. They enable and reward you to help a cute robot walk in a damn line.

<comment><USER35> My gateway drugs into programming were AutoIt ([https://www.autoitscript.com/site/autoit/](https://www.autoitscript.com/site/autoit/)) and Ren'Py ([https://renpy.org/](https://renpy.org/)).

AutoIt lets you control the mouse, simulate keyboard input and so on. It was pretty fun as a kid to make a "can't press this button" game and watch others try to beat it. There wer also bindings to various Windows APIs, which I used to build GUI solvers for my math homework.

Ren'Py is a framework for creating visual novels, and I made one that mocked the vocabulary tests by having each choice be a pun on bastardized French or a running gag in my French class. I think pretty much everyone in that class played it at some point.

My point being, there are tools out there with a special-purpose scripting language used by content creators who might themselves not be expert programmers, and I if you let kids play around with that they will probably build something they find fun without anyone telling them to do so.

</comment></comment><comment><USER36> I have a halfway decent solution to this problem.

Currently, I'm working on a web-based game development language. Essentially, I would like to create a simple programming language, like BASIC, Lua, or others, and provide built-in libraries for 2D game making.

Much of my formative programming experience was using using Blitz Basic, a game language. As a teenager, I was able to use it to create games easily.

With all of the visual and graphical game development kits available today, I feel that it has become more difficult to learn programming in the way that I did. Providing a programming-based offering is the only solution, I think.

When constructing functions and loops to coordinate and move or draw sprites, I think it becomes much easier to think about the logic of a computer program and how that knowledge can be practical.

<comment><USER37> I think this is an amazing idea! I played with Basic and Visual Basic when I was younger and it taught me all about logic loops, basic data structures, etc. Putting that type of playground on the web sounds interesting. Have you started yet?

<comment><USER36> I'm working on porting the language VM to asynchronous JavaScript. The language that I'm using is one that I've shared with HN before, although I've made major changes and added some nice features.

Here is the Duck source code: [https://github.com/gregtour/duck- lang/tree/duck2](https://github.com/gregtour/duck-lang/tree/duck2) The documentation reflects the original version, but duck2.cfg shows the new grammar and the /js folder shows the current progress.

I have a mockup of the interface here as well: [http://brainplex.net/gamepad/](http://brainplex.net/gamepad/)

One big issue is finding time.

</comment></comment></comment><comment><USER38> Text didn't prevent me to learn Timex 2068 Basic and Z80 Assembly at the age of 10.

What I would concede is that we had fun books to learn from, like these ones for the Atari [http://www.atariarchives.org/](http://www.atariarchives.org/).

</comment><comment><USER39> Scratch is another solution for this problem

[https://scratch.mit.edu/](https://scratch.mit.edu/)

<comment><USER40> I don't think it is - after learning how to build things in Scratch, one still has to transition to a language with different syntax which is text-only. What was presented in this submission might just be the solution that helps reduce the anxiety of transitioning from icons to programming languages with text- based source code.

<comment><USER41> Scratch is intended for older children who already have a certain level of literacy. There is another product, ScratchJr, for younger children that uses an icon-based UI: [http://scratchjr.org/](http://scratchjr.org/)

The transition path between them is indeed what you described.

</comment></comment></comment><comment><USER42> There's a discussion of this on the Bootstrap blog: [http://www.bootstrapworld.org/blog/blocks/Block-Getting- Star...](http://www.bootstrapworld.org/blog/blocks/Block-Getting- Started.shtml). (That's Bootstrap, the teach-scheme-to-middle-school-children project, not Bootstrap the JS library.) They've tried it both ways. I'll quote their bullet points:

        > Things we love about blocks

        > 1. Blocks lower the barrier for entry
        > 2. Less frustration
        > 3. Useful hints
        > 4. Visual reinforcement of structure

        > Things we don't love about blocks

        > 1. Penalizes fast typers
        > 2. Higher demand on short-term memory
        > 3. Small space of visual cues
        > 4. Poor Accessibility

They go into detail on each of these.

</comment><comment><USER43> Context: they're working on something aimed at children no older than 8.

<comment><USER44> Why do children under 8 need to know how to code? They don't even have simple things like cause and effect established in their brain until they're about 11. I.e. "if it's raining outside I should wear a rain coat or I'll get wet". Nor do they have much logical reasoning capability. That's also why they don't get sarcasm.

Edit: paper on pre-adolescent and adolescent brain development, especially as it relates to cause and effect and abstract reasoning: [http://www.sciencedirect.com/science/article/pii/S1878929314...](http://www.sciencedirect.com/science/article/pii/S1878929314000516)

<comment><USER45> You have a really weird idea of what an 11 year old is capable of.

<comment><USER46> Prefrontal cortex is still developing in 11 year olds which means they're not great at understanding consequences of actions or making complex future plans.

<comment><USER47> But most of them are certainly capable of making the evaluation used as an example above.

<comment><USER36> Not to be the "prodigy" kid, but I began game programming at 10 years old because I wanted to know how games worked. I tried to buy a Visual Basic 5 book from Borders before my parents gave me "Beginning Programming for Dummies" instead.

Not sure why these people don't believe that Boy Scouts and Girl Scouts can't tell the weather.

</comment></comment></comment></comment></comment></comment><comment><USER48> Good article. I hope this article inspires more people to come up with clever solutions that help bridge the gap with kids and coding. It's easy for most of us to discount the barriers of syntax because it's so familiar to us, but try to remember this: People consistently fail PEDMAS tests online. That's a trivial syntax.

I like their approach to transitioning from an icon/diagram approach to a text approach. It highlights that text and iconic/diagram representations don't have to be a false dichotomy. These two ideas can complement each other if done carefully.

If there's one thing I'd love for every person who aspires to create a visual development environment is this: Visual representations should be used to enhance and project program structure, not to replace text altogether. Much in the same way that the CoffeeScript --> JavaScript translation page illuminates the language, I believe we should be projecting our text languages into various clear visual representations.

Having been made to suffer through a few Enterprise Integration Tools (BizTalk, MuleSoft) that take a diagram first approach, I concluded they would be much better served if they took a text-first DSL approach that is isomorphic with a diagram representation. By binding the two at the hip, working with the diagram based UI would visually teach the user's understanding of the DSL syntax. In the other direction, playing with the text interface could instantly reveal how the parser is interpreting the intent of the program.

Again, I'd love to see more people take perspectives past the usual false dichotomies and start researching how different approaches can complement each other rather than compete for attention and mindshare.

</comment><comment><USER49> I definitely agree that text is very intimidating, no matter how well it is represented, compounded by inclusion of numbers and punctuation like (, ), ;,. +,-,<,>, etc.

Another is that we no longer have the text-based interface in things that we use. In the classic computing era, text games like "Zork" were popular, and even DOS and *nix text shells were the norm. Even adventure games like Sierra Online games had graphic view but had text interface. Perhaps text-based user interface could lessen the anxiety of text in coding, but I think that we no longer value text UI.

Instead, everything is GUI now, with touch-interface on iOS/Android in the mix - and perhaps someday, we no longer will have mouse/keyboard, but rather just verbal and physical interface. By then, we can program things using complex language such as "I'd like to move the yellow box sprite on top of the tree to the left about 50 pixels", then programming code becomes more approachable to average human. We are already on our way, with Alexa and Siri.

</comment><comment><USER50> I had an excellent math education growing up (not in US) so programming did not seem intimidating to any of us as it looked a lot like math. For me the main motivation to code was to have my computer do the math and physics I was learning in school. US parents and teachers really need to push for better math skills rather than run away from it.

</comment><comment><USER51> All we're doing here is separating logic from syntax -- which totally makes sense.

Ironically, a lot of business software development works like this (not that it should, just that it does). You have a bunch of BAs who churn out flow charts and hand them over in the form of requirements to developers who implement that logic via syntax.

</comment><comment><USER52> I think it's due to only 10% of humans primarily thinking in text/sound, whereas 40% are visual and 50% are emotional. This was exploited in e.g. Harry Potter books. I think we are due visually or voice-driven development environments that should be now possible with Deep Learning, even if initially a bit cranky.

</comment><comment><USER53> Umm...where's the research on the efficacy of the change on how skilled the kid becomes at programming? All I see is they self-assessed that it was easier with pictures, and they were engaged longer. Great. But DID THEY LEARN TO CODE BETTER?

The algebra comparison is telling; "a study was done that showed that 92.9% of kids using the app achieved mastery of basic algebra after 1.5 hours of play" \- where's the similar comparison?

And, how do we measure 'mastery'? Because the mathematical lexicon requires numbers, not pictures, and coding non-trivial things are done with languages that are text, not pictures, the way we test that is also important.

Note that fundamentally I agree with their conclusion that, pursuant to being marketable, they HAVE to use pictures, because people's impressions matter. But in terms of actual benefit, I'd want to know more details.

<comment><USER54> They did not do hard research, since they are still designing their game, but they did present it to playtesters. I think this is an appropriate level of diligence for a product early in the design phase, it's the equivalent of the "hallway usability testing" recommended for agile teams.

It may be impossible to say right now whether this change helps kids get better at programming faster, but presumably, more kids will play a game that they feel is more approachable, similar to how the playtesters responded.

<comment><USER53> Like I said, I don't fault their methods for what they're optimizing for: sales. I -do- fault them for implying that it will improve coding skills when they never tested for that.

</comment></comment></comment><comment><USER55> IMHO the more likely explanation for these results is that the human visual system has built in mathematical, logical capabilities actually far beyond advanced college math. These are used to identify and track objects at a very early age. It is much easier to access these abilities using pictures and icons.

Text is an additional layer of abstraction probably involving language and communication systems _outside_ the human visual system. The text is a label or abstraction for the visually represented concepts which must be encountered and learned first.

There is a consistent pattern in learning mathematics and other technical areas that most students learn better and faster with pictures and concrete examples. Abstraction comes later.

</comment><comment> a-nikolaev By starting with icons first, you intuitively teach the idea of _tokenization_ of the program code.

This idea is important, but trivially simple to an experienced programmer so easily dismissed. It is not that obvious to a beginner tho.

</comment><comment><USER56> > From our perspective, we'd simplified the code to what looks like plain > English.

How do they square that with the presence of parentheses and the use of a syntactically significant period?

It seems strange they didn't start with something that looked more like Logo before concluding the text was inherently off-putting.

I'm not sure their conclusion was wrong — but I'm confused about the point where they gave up with text.

Also - the final syntax at the end is ugly as hell. Is that the best they can do?

Finally - not even a hat-tip to Scratch/Blockly? If they aren't aware of it then it's very odd. If they are and decided not to mention it - I find that equally odd.

</comment><comment><USER57> I learnt to code with logo, and that was text based. why are we trying to force kids to learn how computers till they are interested in it. They should be learning to ride bikes or climb trees.

what we lack in the computing world are games they can make by following a book, eventually they'll want to diverge from what's in the book and make their own stuff, the problem is no games are too complex and a simple game might not hold their attention.

Something like Mario Maker is where they probably should start but the extra options to change variables and access scripts later on.

</comment><comment><USER58> If software had started in China, we would not have these problems. There would be an ideogram for each operator or keyword. For one thing, the equals sign wouldn't be misused as an assignment operator.

</comment><comment><USER59> And yet I hate game engine visual programming, whatever you call connecting those boxes together. I started out thinking the windows commands were doing something cool and then wanted to make games so i asked my parents for the Dark Basic software set and began moving images around that shoot sprites I drew. From there I asked for a Borland C book that came with a compiler and then jumped into web design a bit. That was about 20 years ago for me and now I'm a system admin and reverse engineering/making whatever I can on the side.

</comment><comment><USER60> Didn't Alan Kay and team get a bunch of elementary school-aged children - <USER3> had probably never even seen a computer before, since this was in the 70s - programming in Smalltalk?

<comment><USER61> Yes. Not only that, but by observing the kids they iterated on different versions of Smalltalk. The approach there was quite different from what you see today. They built upon actual psychology and spent the money and time conducting studies. From that we got things like GUI, OO, etc.

When you see Kay harping on about the dismal state of affairs today, I think it's that he sees this constant pedantic bickering about static vs dynamic typing and all the rest as meddling around in the complexity of things that should be irrelevant.

To the point of the original post, it's also worth noting that Smalltalks were not just text environments, and that while yes much of the code was written in text, these kids were not writing text files that they then compiled/interpreted using their PDP Terminal emulation programs. They were doing everything in the live environment itself.

Considering the existence of things like Smalltalk and Hypercard, whenever some uber programming expert tells you this-or-that reason we cannot have such systems in wide use today, it's akin to saying: "See all this great stuff we used to have? We can't have it anymore"

</comment></comment><comment><USER62> This is a really good idea, separating the logic from the syntax. I remember when I was learning database design and they taught us using Access, so we didn't get bogged down in the syntax. When I had to switch to Oracle professionally, I noticed I was constantly translating what I saw in Access to the PLSQL in Oracle. After a while, I just thought in PLSQL rather than Access.

Something I've noticed all the years, teaching is _HARD_. Well, teaching effectively and efficiently is.

</comment><comment><USER63> The kids they are working with are in an age group in which some children are just beginning to _read_. Yes, text is a problem if you're _not yet literate_.

</comment><comment><USER64> Are you a coder if you don't understand what syntax is? We used LOGO when I was a kid, and for good reason. It had a limited syntax for classroom use and gave you instant visual gratification.

Sometimes I wonder if being limited to text adventures when I was really young was a benefit. If I typed something that the computer didn't understand, it told me so. It forced me to have patience and to learn to look up the right way to ask for something.

</comment><comment><USER65> Cool! I feel like you could go further and let the student control the transfer to text. Give all the built-in functions both icons and names, and let student-defined functions be icons they create if they want. The point where it's less cognitive load to use text is going to be different for different students, so let text-based coding be a tool they discover, not a requirement imposed on them.

</comment><comment><USER66> I was at a conference lately. After one talk, the presenter talked about his experiences with his children presenting how to code and teach other children. He commented that one of the biggest barriers he saw in his own children is that it took them so long to type out the ideas they have in their head. It requires immense focus to retain what to do next.

</comment><comment><USER54> There was some great prior discussion of the topic of kids, text, and coding in a thread about Scratch 3 months ago: [https://news.ycombinator.com/item?id=14274249](https://news.ycombinator.com/item?id=14274249)

</comment><comment><USER67> I thought this would be "kids are texting rather than messing with their computers".

</comment><comment><USER68> > Problem is, many newcomers, kids and adults alike, believe that code is > inherently complex simply because it looks complex.

But it is complex. Anything beyond the most basic examples delve into the concepts of calculus.

If we don't expect most children to comprehend advanced mathematics until they're teenagers, why would we expect most of them to grasp anything but the most basic conditional logic until then.

That's not to say that we shouldn't attempt to teach children coding at a young age, but the idea that anyone but a few would understand genuine coding at the same developmental period where they're learning to spell "dog" and to add 2+2 is a bit ridiculous.

I wonder if the authors consulted a child psychologist before beginning their endeavor.

<comment><USER69> >But it is complex. Anything beyond the most basic examples delve into the concepts of calculus.

Huh? My codebases at work have never involved calculus. Not all programming proceeds along the lines of Project Euler when getting more complex.

<comment><USER68> The very concept of functions is calculus.

Kids are in their teens before we even have them solving x=y algebra.

<comment><USER69> Maybe we're working from different definitions of "calculus".

To me, equations and relations between variables are not calculus, just algebra. Only when you start studying the infinitesimals of change does it start to count as calculus. I don't have any derivatives or integrals in my programs, and very few do.

<comment><USER70> [https://en.wikipedia.org/wiki/Functional_calculus](https://en.wikipedia.org/wiki/Functional_calculus) maybe?

</comment></comment></comment></comment></comment><comment><USER71> I was playing this kind of games when I was a kid. More like a puzzle than coding though.

Kids who want to learn how to code should just do it with regular tooling. You don't need any special approach.

</comment><comment><USER72> I wonder what it's like growing up in today's world learning to code... Very different from how I was introduced to coding.

</comment><comment><USER73> Kids learn to read music at school so why should learning to code be any easier? Skills have to be learned. Simple as that.

</comment><comment><USER74> if i had learned to code using those graphical things when i was growing up, i probably woupd not have become a coder. wheres the joy and fun in it? looks laborius and boring to me.

</comment><comment><USER75> Are 5 year olds expected to read these days?

I learned it at 7-8.

<comment><USER76> I remember getting frustrated with my kindergarten teacher because she insisted that the letters "T-H-E" spelled a familiar word, yet the word has no T sound, H sound, or E sound. What a garbage language, I thought.

So yeah, I'd say kids start to learn to read at 5 or earlier.

</comment></comment><comment><USER23> I can't comment too much on this, except to say that it did cause me to recall something from my early childhood.

I remembered that in the first grade of elementary school, when I was 6 years old, that we used these workbooks with tear out pages to do these "math" problems. Simple addition and subtraction, IIRC.

But these workbooks didn't use numbers and symbols; instead quantities were shown by fixed objects (like coins, or other images), symbols were replaced by something else, but I don't recall exactly what (maybe simple words - so not completely "text free").

On a different note - a few years ago my wife asked me to look over a friend's child's homework, to try to figure out how to do the problems, and what the answers were, because her child was having problems doing the homework, and neither she nor my wife could figure it out (neither are very math fluent).

I looked at it - and at first it was "gibberish". There were some "standard" symbols for multiplication and addition, subtraction and the like. But everything else was symbols.

Like, there'd be a problem that visually was something like "circle + ? = triangle" or "2 square + 3 triangle = ?" (I may be mis-remembering things, too). It was very confusing, but fortunately the worksheet (which was all I had) had a couple of "example problems" and their solutions included. I studied things for a bit, then it dawned on me:

It was algebra - but it was being taught with symbols instead of numbers, and the solution (and how to arrive at it) was pretty simple to understand, once this was realized. In short, numbers are symbols (hey, I'm not a big math whiz myself - I know just enough to blow my foot off) - so it made sense that swapping these out wasn't that big of a deal, provided you had some base knowledge about the rules (which were provided by the examples).

I was able to figure the problems out, then write down how things worked for her (and her child) to read and understand. AFAIK, the homework was completed and turned in with correct answers.

At the time, her child was probably in the 4th or 5th grade, and it was interesting to me that the school was using such a system to teach algebra at an earlier age than what I recall having learned it (my first real algebra class wasn't until 7th grade, though in elementary school in 5th and 6th grades we had been doing some of the basics beforehand - I guess for "prep" for the coming years).

So, in the case of coding, I can see how this idea of starting with "abstract icons" (somewhat) to represent certain coding statements and ideas - <USER4> gradually phasing in text - seems like something that should work (and they seem to prove that it does, too).

Oh - another early example from when I was younger; arguably I first started to "program" when I got my first programmable toy - a Milton Bradley Big Trak. It's keypad used mostly symbols (plus some numbers) - but had other symbols for other actions...hmm.

</comment><comment><USER77> If you give your kids books, text isn't scary

<comment><USER78> If that held up, I wonder why (at least from the article) it seems that parents thought the same.

<comment><USER79> I think that sometimes parents "protect" their kids from complicated things. They underestimate what children are capable of.</comment></comment></comment>


Citus 6.0 – A database designed for multi-tenancy - <AUTHOR> https://www.citusdata.com/blog/2016/11/14/introducing-citus-6/ <comment><USER2> Citus looks interesting. Anyone can provide some insight on how easy it is to transform an existing PostgreSQL cluster to a Citus one?</comment>


California Cracks Down on Hacker Boot Camps - <AUTHOR> http://www.wired.com/wiredenterprise/2014/01/california-hacker-bootcamps <comment><USER2> > They're usually staffed by professional coders, not licensed teachers. Many > of the teachers are volunteers — even though the schools are usually private > companies, not non-profit organizations. And many schools are backed by > investments from big-name Silicon Valley venture capital firms.

I was very surprised to read this. Volunteering can be appropriate if you're helping the less fortunate, or if you're sharing with your peers; but if you volunteer for a for-profit organization, you're devaluing your own skills while enriching those who are already rich. It's not just self-damaging, but socially regressive too.

<comment><USER3> The difference between running your own tutoring business and volunteering for a hacker school is that N dollars go into the school's pocket, instead of yours. Why would society care about that difference?

<comment><USER4> Because it becomes harder for potential teachers/tutors to compete with free?

<comment><USER5> There must be a reason why people volunteer to do something. People wouldn't volunteer unless they thought it's good for them too. If it makes harder for someone to compete - great. Compete better.

</comment></comment></comment></comment><comment><USER6> > He says the only exemptions are for courses than cost less than $2,500, > programs affiliated with accredited schools, and certain religious education > programs.

Well then, problem solved: turn the buildings into Pastafarian temples and the act of coding into religious service - should be more or less the same as Scientology is doing already.

<comment><USER7> > turn the buildings into Pastafarian temples and the act of coding into > religious service

I'd recommend against embracing Pastafarianism for this. The last thing that the industry needs is legions of spaghetti coders.

<comment><USER8> Hahaha! Brilliant.

</comment></comment></comment><comment><USER9> Anyone actually successfully attended this boot camps and got a job offer for their coding skills? Specially for someone who never had any prior coding knowledge.

I don't know why but this just smells like scam to me.

Why would a company hire you, who just finished a boot camp, as opposed to someone who have years of coding experience and knowledge?

<comment><USER10> I just completed a dev camp in november and the answer is yes. 80% of my class had positions as devs within two months of finishing. Our best student (who had taught himself a little code before) was hired within a week.

Not saying all the schools are good. (some look slightly sketchy to me)

"Why would a company hire you, who just finished a boot camp, as opposed to someone who have years of coding experience and knowledge?"

An odd premise, its like asking why a company would hire someone straight out of college.

Companies hire from devcamps because the good ones are taught by people who work in the industry and know what they would want a colleague to know, furthermore they ask the potential employers what they are looking for and teach that in a hands-on environment.

<comment><USER9> A person who came straight out of college is likely to have at-least 2-4 years worth of programming experience as opposed to someone who attended a bootcamp for a few months.

I am still not convinced that this is anything more than a scam. Unless you are exceptionally brilliant at learning new language, no matter how much you push yourself, you will be barely good enough to even know the rudimentary concept of programming in 2-3 months.

To me the best way to learning programming is to make fuckton worth of crude programs and then make insanely silly and sometimes good mistakes in the process and then try to figure out how to fix those mistakes by yourself (or at least with some help).

2-3 months is barely enough time to understand _WELL_ rudimentary concepts of programming let alone learn from your mistakes.

If you already have prior programming knowledge and know at least one programming language, joining this camp is silly and it doesn't prove anything one way or another. If you already know one programming language, learning a new language should be fairly easier than for someone who have never programmed in his life.

<comment><USER11> >If you already have prior programming knowledge and know at least one programming language, joining this camp is silly

As someone in this group, I'd have to disagree with you.

I work in a life sci research setting, and am usually the only person with _any_ programming knowledge or experience whatsoever. In research, "it works," is generally the only quality control placed on bespoke software. I'm capable of writing working programs to perform simple tasks & do on a regular basis, but I could not begin to write a large web application using best industry practices. I've also never spoken at length with other programmers regarding the problems I'm facing, and as such, I would have a significant degree of difficulty discussing conceptual frameworks with a team.

Having spoken to a few people who attended these schools, it seems that they have a thing or two to teach someone like me.

Perhaps it's not worth $10k, but I think that's a separate argument.

<comment><USER12> Yes. I taught myself initially and was writing lots of small utility scripts. Towards the end of the bootcamp I attended I got a call to update one of the things I had written before. The difference between before and after was enormous. When you're teaching yourself for practical purposes it is very easy to achieve "working" code that would be totally unacceptable in an environment where the code was the primary driver of value. Additionally, if you're the only programmer in your office/program, it is very hard to progress since you must be the creator of your own curriculum. It's a good exercise and self- education is an important skill, but it's hardly the most effective way to learn.

</comment></comment></comment></comment></comment><comment><USER13> I'm also wary of boot camps but this is definitely not the way; if you want to pay for something you pay for something. They are not pretending to be a college, they are not pretending to be a substitute for it.

The only scam here is this part of the USA law, is scamming people into believing that everything needs to be regulated or otherwise it's evil.

<comment><USER14> Modest regulation of the education industry is entirely necessary. It has a long history of trouble, from low-quality schools to out-and-out scams. Students by definition aren't able to directly evaluate the educational experience up front; if they could, they wouldn't need the classes. Plus, with high prices and long feedback cycles, there's a large amount of value at risk, and market mechanisms don't work particularly well.

Even if the current crop of boot camps is all awesome, it's an ideal model for a scam. With new ones popping up all the time, anybody with more greed than sense could open up a well-marketed school, make some great promises, collect a couple hundred thousand dollars, give some half-assed classes, and shut it all down again before the first bad Yelp reviews come in. And then they could do it again with a different name instantly.

<comment><USER13> Yes, in theory. Here the only ones with more greed than sense are the ones behind the enforcement of bankrupting-expensive-regulations.

If you really care that much you just need someone that knows the subject to go the classes and see for themselves if everything is being taught good enough. You don't need to inject a bureaucratic debt in their finances in the name of "regulations".

</comment></comment></comment><comment><USER15> When the story first hit Venture Beat I stuck to reading what the BPPE actually said, and then I checked out the website to try and dig up the regulations.

Unless someone has information I haven't been able to dig up "crack down" just means that they've been requested to comply. BPPE decided that these sorts of programs are under their purview and so they need to cough up some amount of cash and submit some paperwork.

Quotations in the Venture Beat article very clearly state BPPE are not going after them, just notifying them of their need to comply under California law.

So much polemic either on government regulation or on the merits of these programs. BPPE places schools into either "approved" or "accredited" categories. These programs need only be approved. As far as I can tell BPPE is fairly minimal in its requirements basically ensuring the schools are real things and not diploma mills.

This isn't anywhere as much of a crackdown as CPUC making it harder for ride- shares (for a bit). Discussion of the programs makes sense, but in the context of an imagined witch hunt it just seems strange.

</comment><comment><USER16> This is terrible news. California is full of people who are structurally unemployed due to technological incompetence. The vast majority of "licensed teachers" know nothing about coding. Why obstruct hackers who teach valuable skills to others?

<comment><USER17> > California is full of people who are structurally unemployed

Do you have a cite for that? Nationwide there's very little evidence of structural unemployment, and I'd be surprised to find that California (which is a state people tend to be interested in living in) has an unusual problem with finding skilled workers.

</comment></comment><comment><USER18> What exactly are they trying to license these bootcamps as? They are basically job placement agencies with training included, right?

This is a bit off topic, but the prices that they command seem ludicrous. $1k a week or so, for most of them. I know that a person attending stands to get a high paying job, but 10k seems like a lot.

<comment><USER19> I don't know, 10k compared to 100k+ at a proper four year college seems fair to me

<comment><USER20> If you are truly paying 100k for a 4 year (120 weeks) university education, then it works out to be $833 per week. My education at an in-state university cost far less than that. Claiming that "bootcamps" are superior in value or rigor is mendacious.

<comment><USER21> Except you don't have to attend bootcamp for 120 weeks.

</comment></comment></comment></comment><comment><USER22> "it would be relatively easy for a fly-by-night operation to advertise a developer bootcamp, collect tuition, and then provide low-quality education — or skip town before the courses were even set to begin"

These bootcamps don't charge students until after they complete the course and get an industry job.

</comment><comment><USER23> So I suppose this thread is just as good a place as any to ask the following question, which I've been curious about for a while now:

What, in your opinion, is the highest quality coding boot camp and why? Follow-up: what should a person who qualifies for one of these schools be looking for?

</comment><comment><USER24> > _many of these companies charge upwards of $10,000 and make bold claims > about alumni making six figure salaries upon graduation_

I think the word "scam" applies here.

<comment><USER17> There's a program like that here in Portland that makes claims on its website about Rails developers being able to immediately earn upwards of $80k a year. Maybe in the Bay Area, but definitely not in Portland. And they charge up front, no placement guarantees.

</comment></comment><comment><USER25> So there will be rise of "traditional" underground ones.)

In some sense "legal" hacker conferences sponsored by MS and Cisco is utter nonsense. Strong disliking of cargo cults, bandwagon and peer effects of brainwashed mediocrity is a part of so-called hacker culture.)

</comment><comment><USER26> This isn't going to help the industry. The Internet is changing the way we learn and software development is at the edge of the trend. Software lends itself to this in part because its a meritocracy in which competence is easy to recognize independent of accredited degrees, and because the tools change so fast traditional institutions have trouble keeping up.

Its extremely unlikely regulation can do as good a job as the default market forces in identifying quality programs, and it will likely put a huge damper on people trying to do innovative things with technical education in the state.

disclaimer: I run a one year 'developer bootcamp' in rural india - [http://jaaga.in/study](http://jaaga.in/study)</comment>


Virtual private networks with WireGuard - <AUTHOR> https://lwn.net/SubscriberLink/748582/75c743d0eb3aae0f/ <comment><USER2> Good to see WireGuard getting some coverage. I've been embracing it from the very beginning for small scale Kubernetes clusters running on virtually any cloud provider lacking isolated private networking[1]. It's been running stable in different environments for more than a year; set up and forget. Unlike similar software it's also dead simple to configure.

Apparently, Linus wants it in the Kernel[2].

[1] [https://github.com/hobby- kube/guide/blob/master/README.md](https://github.com/hobby- kube/guide/blob/master/README.md) [2] [https://lkml.org/lkml/2018/2/13/752](https://lkml.org/lkml/2018/2/13/752)

</comment><comment><USER3> WireGuard is doing good things. PIA will be rolling out support shortly.

<comment><USER4> And a citation.

[https://www.privateinternetaccess.com/blog/2018/01/private-i...](https://www.privateinternetaccess.com/blog/2018/01/private- internet-access-proud-supporting-wireguard-project/)

No timeline yet though but given the early state of WireGuard and the platform support that is understandable.

</comment></comment><comment><USER5> can wireguard work over tcp? many captive portals i encounter daily block most ports and almost always allow only tcp. so i set up openvpn on port 443 over tcp, which got through everything so far.

<comment><USER6> Couldn't you theoretically run traffic over pseudo-TCP. I.e. you send packets that look like TCP (IP packet type TCP + TCP header), but bypass the kernel's TCP stack and put arbitrary, packet-based data in it, like UDP. Theoretically speaking.

<comment><USER7> Yes, but the same middle boxes would choke on that too, either corrupting it or blocking it.

</comment></comment></comment><comment><AUTHOR> Includes a nice description of how WireGuard works on Linux, and how it's different from other VPN implementations.

</comment><comment><USER8> Is WireGuard working as an IPv4 tunnel or can it transport arbitrary packets, like ipv6, becoming a tap interface?

Does it work as a link between two devices, or one-to-many? Does it support peer-to-peer connections within the group?

<comment><USER9> It is a layer 3 vpn that supports v4 and v6 payloads. It does not support any layer 2 connection like you would get from a tap interface.

You can certainly make a mesh of connections between different hosts by adding the remote peer's public key and ip address to each host's configuration. There is nothing in wireguard that makes that automatic though.

<comment><USER10> Ah, so to connect N hosts together you need to configure N-1 connections in each of the hosts?

That's a bit of a hassle, though not prohibitive. A VPN that's secure and easy to configure would definitely be useful in getting all the components in our infrastructure talking to each other. No need to worry about authentication or encryption, it'd all be handled for you by the VPN.

<comment><USER11> If you want to connect all your hosts together in a mesh I suggest ZeroTier. It is an easy to setup network designed for this use case.

<comment><USER10> That looks pretty slick, thank you. I wish I'd heard more about it, as I don't know how secure it is, but I'll give it a try.

</comment></comment></comment></comment></comment><comment><USER12> I've been an long time advocate of tinc. I'd love to see a comparison with WireGuard.

<comment><USER13> I've tried Tinc, Wireguard and OpenVPN. Currently I'm on OVPN via a pfSense box (doesn't support WG yet).

Tinc is neat if you need a mesh network but it was an utter pain to properly setup (half the time I wouldn't get any connection, the other I would not get data over it).

OVPN and WG have been fairly pleasant in that regard, though OVPN still suffers from some non-obvious failure cases when you stray away from a simple VPN connection.

In my case, I only dial into a OVH instance to A) setup/config containers on it and B) use OVH as VPN.

Tinc's mesh network is overkill, the clients are all behind X number of NATs or firewalls and without the central server there is no use for the VPN.

I might think about Tinc again if I feel the urge to setup multiple boxes.

</comment></comment><comment><USER14> I use one of the many non-OpenVPN "VPN" alternatives. The one I chose has fewer lines/words/characters of code than Wireguard.

It does not require SSL/TLS, it can use Curve25519 and it is faster than OpenVPN.

It is a userland daemon (using /dev/tap), so it may be slower than Wireguard.

However I think it is more portable than WireGuard. (That is an important feature to me.)

How portable is WireGuard to BSD, Minix, Plan9, etc?

<comment><USER15> Do you mind sharing which "VPN" alternative this is? Thanks!

<comment><USER16> While I have no idea given the... oddity... of this subthread, I might posit `tinc` is being referred to here: [https://www.tinc- vpn.org/faq/](https://www.tinc-vpn.org/faq/)

ETA: this is based on the open source code which may be modified, userland daemon status, /dev/tap usage... Portability... etc.

In any case - tinc is excellent

<comment><USER14> FWIW, that is not what I use.

I should have not mentioned anything about other software. It is irrelevant to the question.

The question was/is: How portable is WireGuard?

<comment><USER17> [https://www.wireguard.com/xplatform/](https://www.wireguard.com/xplatform/)

There exist closed source third party clients for Windows/OS X, and wireguard itself has currently two (unreleased) reference libraries in Go and Rust to support future cross-platform clients.

So the answer to "how portable" is probably "portable" :-) (I don't know if there are any plans for _kernel_ mode implementations for anything but Linux, but cross-platform user mode clients are part of the project's goals)

<comment><USER14> Thank you. It sounds like portability may come via a userspace program. I look forward to it.</comment></comment></comment></comment></comment></comment>


The Tech Deities - <AUTHOR> https://www.technologicallyadvancedhuman.uk/the_tech_deities.html <comment><USER2> His message is a little trite because I've been hearing (and even used to proselytize) the same things ever since Linux "fanboys" started bashing (pun not intended) Windows users. For the layman, convenience trumps control/customizability.</comment>


Cartoon Picture of Magnets That Transformed Science - <AUTHOR> https://www.quantamagazine.org/the-cartoon-picture-of-magnets-that-has-transformed-science-20200624/#comments <comment><USER2> The subtitle is much better than the title " _One hundred years after it was proposed, the Ising model is used to understand everything from magnets to brains._ "

(Also, this links to the comment section instead of the main article.)</comment>


Frog Mutations and the Fukushima Butterfly Mutations (2012) - <AUTHOR> http://www.thingsworsethannuclearpower.com/2012/08/frog-mutations-and-fukushima-butterfly.html

<comment><USER2> > And the primary cause identified is the effect of mass amounts of hormones, > pesticides, herbicides, and fertilizers used worldwide by homes, businesses, > cities, and the agricultural and farming industries.

I personally am very very afraid for the coming years of food production. We have gotten to the point where very few people are informed or care at all about the sourcing of their food. One of the most poignant little observations of Food, Inc [1] was the branding of food products with images of pastures and green farmlands as if that is what it actually looks like. Greenwashing [2] has become so ubiquitous, the only thing more disturbing than the trend is that people believe they are helping.

Articles of this nature are going to continue coming up more and more frequently as species keep dying out. There have been numerous pieces already about massive honey bee loss, which is going to really suck for North America's biodiversity.

I would encourage HN readers to become acquainted with Industrial Farming and it's issues and surrounding controversy. There are few things that are more important to human civilization than our food, so it's well worth knowing about. If you're already on board, I highly recommend trying to reduce the amount of meat in your diet, as americans eat some of the highest amounts of meat per capita, under the misunderstanding (likely imbued on us by the factory farming industry) that meat is the only place we can get enough protein. I have been vegetarian for almost two years now and my health is just fine, and there's plenty to eat.

I think we all care about our current home and want to see it taken care of. Unfortunately, right now, that requires several major cultural shifts (at least for us US readers).

[1] [http://www.netflix.com/WiMovie/70108783?sod=search- autocompl...](http://www.netflix.com/WiMovie/70108783?sod=search-autocomplete)

[2] [http://en.wikipedia.org/wiki/Greenwashing](http://en.wikipedia.org/wiki/Greenwashing)

</comment><comment><USER3> I have nothing of value to add to the discussion but this little side-note of humor: [http://simpsons.wikia.com/wiki/Blinky](http://simpsons.wikia.com/wiki/Blinky)</comment>


Show HN: Disrupting dental insurance industry with in-house membership software - <AUTHOR> https://www.okdentalplans.com <comment><USER2> Isn't dental insurance just a scam? It's a lot of money but then if you need a root canal or something it only pays 50% so why?

<comment><AUTHOR> You're right. There's no insurance in dentistry. Insurance is an actuarial risk analysis versus moral hazard. Everybody has car insurance but hopefully everybody pays a premium and never ever make a claim. Everybody too has fire insurance on their house.

But with dental insurance, you don't really have dental "insurance" when 100% of the people need a cleaning, exam, and X-rays each year. In practice, it's more akin to a Costco membership, where you pay a monthly premium in return for discounted services. A co-pay is almost always necessary for basic (filling)/major procedures (crown, root canal).

It's a huge pain point in dentistry, because insurance companies basically monopolize dentistry ($85 billion market), where the vast majority of patients pay money to the insurance companies, not directly to the dentists themselves. In effect, dentists are reduced to being employees/contractors of these so- called preferred plan organizations (PPOs).

But they have no choice, because if they don't "take" the insurance of any patient calling in, they lose that business forever -- the patient just goes to the next dentist who's "in network" and accepts their insurance.

So over time insurance commoditizes dentistry, patients have zero loyalty to their providers (they have loyalty to their insurance instead) and these PPOs have all the bargaining power to impose terms and provide lower and lower reimbursements to dentists, while their costs go up year after year.

My MVP strives to empower dentists to start taking back their business from insurance companies, to be their own "insurers." Start a competing in-house discount plan and keep those monthly retainers for themselves.

<comment><USER3> You are targeting dentists here, but patients are the ones buying the insurance. Even patients often don't have a choice - think employee benefits and medicaid/medicare.

Even if dentists do enroll in this, what happens when a patient decides to change dentist?</comment></comment></comment>


How to properly handle the Covid situation, by Denmark government - <AUTHOR> https://twitter.com/voorloopnul/status/1238009165823574016 <comment><USER2> Meanwhile in Spain bars, restaurants crowded. Our govern is just a bunch of irresponsible idiots.</comment>


The basics of Svelte in under 3 minutes - <AUTHOR> https://zeph.co/svelte <comment> ix-hispana Surprised not to see the reactivity feature using the label statements as it is the one thing that sets Svelte apart.

</comment><comment><AUTHOR> Author here – the majority of developers in the 2019 State of JavaScript [0] said that they didn't know Svelte but wanted to try it out. I was the same way, so I spent the weekend learning it, and I put together a few basic examples to show you how it works.

I'm interested to know if anyone has used Svelte for a larger production application. If so, what are your thoughts?

[0]: [https://2019.stateofjs.com/front-end- frameworks/svelte/](https://2019.stateofjs.com/front-end-frameworks/svelte/)</comment>


Singularity Summit 2010 – Optimism, Intelligence, and the Future – Oh My - <AUTHOR> http://singularityhub.com/2010/08/17/singularity-summit-2010-optimism-intelligence-and-the-future-oh-my/ <comment><USER2> Interesting bit: "The most memorable point Kurzweil made was rather refreshing for me to hear him say: consciousness may be too subjective to measure. Sure, the Turing Test may let you know whether we believe an AI to be conscious, but consciousness itself may be immune to objective testing. An interesting concession."

</comment><comment><USER3> How can such a futuristic summit be so disconnected? No live stream, dead youtube channel, dead twitter account = #FAIL.</comment>


The better the PW, the less you have to change it - <AUTHOR> https://www.wsj.com/articles/people-need-an-incentive-to-use-strong-passwords-we-gave-them-one-11568734702?mod=rsswn <comment><USER2> Until it's exposed in a breach, at which point you have to change it regardless.

Your password is only as secure as the system(s) that store it.</comment>


PerimeterX Launches and Introduces PerimeterX Bot Defender Service - <AUTHOR> http://www.marketwired.com/press-release/perimeterx-launches-and-introduces-perimeterx-bot-defender-service-2113997.htm <comment> joe-bot How is this different from other bot detection services like Distil Networks or F5?

Beyond the no reverse proxy thing sounds the same..</comment>


Internet Engineering Task Force: April Fools' Day RFCs - <AUTHOR> http://en.wikipedia.org/wiki/April_Fools%27_Day_RFC

<comment><AUTHOR> These guys have an amazing sense of humor. Vint Cerf himself keeps making hilarious RFCs, for instance:

"Twas the Night Before Start-up" [<http://tools.ietf.org/html/rfc968>] that ends with:

          At last he was finished and wearily sighed
          and turned to explain why the system had died.
          I twisted my fingers and counted to ten;
          an off-by-one index had done it again...

and "A VIEW FROM THE 21ST CENTURY" [<http://tools.ietf.org/html/rfc1607>] that talks about the letters discovered in September 1993 in a reverse time-capsule apparently sent from 2023.

My favorite is one by S. Christie about implementing The Infinite Monkey Protocol Suite (IMPS) [<http://tools.ietf.org/html/rfc2795>].

:D</comment>


Building a "Simple" Distributed System – Formal Verification - <AUTHOR> https://jack-vanlightly.com/blog/2019/1/27/building-a-simple-distributed-system-formal-verification <comment><USER2> If you're interested in learning TLA+, the best resources are:

(1) Specifying Systems by Leslie Lamport ([https://lamport.azurewebsites.net/tla/book.html](https://lamport.azurewebsites.net/tla/book.html))

This is the original TLA+ textbook (I myself learned from it) and is very thorough, but sometimes fails to differentiate between specs which are model- checkable and specs which are not. Since model-checking has become recognized as the main source of value from TLA+, this might frustrate readers who think "woah, TLA+ can do THAT!?!?" only to be disappointed. I still like it, though. You can get a free digital copy.

(2) The TLA+ Hyperbook by Leslie Lamport ([https://lamport.azurewebsites.net/tla/hyperbook.html](https://lamport.azurewebsites.net/tla/hyperbook.html))

Unfinished and unlikely to ever be finished (Leslie has stopped working on it), serves as a good companion book to Specifying Systems. I believe this is the only resource for learning the formal proofs capability of TLA+, which I myself have not yet used.

(3) The TLA+ video course by Leslie Lamport ([http://lamport.azurewebsites.net/video/videos.html](http://lamport.azurewebsites.net/video/videos.html))

Very goofy, very fun. When Leslie teaches courses to engineers in person, he uses these videos. They're effective.

(4) Learn TLA+ by Hillel Wayne ([https://learntla.com/introduction/](https://learntla.com/introduction/))

A free online resource for learning TLA+.

(5) Practical TLA+ by Hillel Wayne ([https://www.apress.com/us/book/9781484238288](https://www.apress.com/us/book/9781484238288))

I own this book, and it is a great introduction to PlusCal (a pseudocode-type language that transpiles to TLA+) and TLA+ in general. Highly recommend! Along with the video course, probably the ideal starting point these days.

<comment><USER3> If you're capable of understanding TLA+ proper, is there much value in starting with PlusCal, in your opinion?

Is PlusCal more a gentle gateway or properly useful in real-world applications?

I lean towards starting with Lamport's book over Wayne's, because the latter seems very PlusCal-centric (and the layout and typography don't appeal to me), but that may be a mistake.

<comment><USER4> This is a question I lose sleep over. I keep going back and forth on it. Here's my current position:

_In my experience_, PlusCal is easier for the average engineer to start with, because it lets me decouple learning about behaviors, learning temporal logic, and learning basic predicate logic. It's also my experience that for many people, it's easier and faster to learn PlusCal and then TLA+ than to start with TLA+.

But PlusCal adds syntax and has its own quirks and logic. So if you are fine with TLA+, it's unnecessary overhead and can distract from the core ideas. Here's a quick test:

       Op(x, y) ==
          /\ x > y
          /\ \E s \in S:
              /\ x' = F(s)
          /\ UNCHANGED y

If that makes sense to you, start with TLA+ proper.

<comment><AUTHOR> I think this is ultimately an empirical question about "the average beginner." The main issue I have with PlusCal (aside from being more complicated in that it has complicated constructs like subroutines and a stack) is that it could confuse people into thinking that specifying (in TLA+/PlusCal) resembles programming because the PlusCal syntax resembles programming. This can lead to confusion down the line. This is why I think it's a question of would you rather be confused now or later? But if someone finds it easier to start with PlusCal, I see no issue with that.</comment></comment></comment></comment>


Find Files (Ff) – File Search Utility in Rust - <AUTHOR> https://github.com/vishaltelangre/ff <comment><USER2> There's also fd[1], which is written in rust and is super fast.

[1] [https://github.com/sharkdp/fd](https://github.com/sharkdp/fd)

<comment><USER3> I just did a little test. fd seems to be about 3 times as fast.

      Command      | Mean [ms]     | Min…Max [ms]
      </comment></comment><comment></comment><comment>-|</comment><comment></comment><comment>---|</comment><comment></comment><comment>---
      `fd .conf /` | 525.6 ± 17.7  | 505.3…552.0
      `ff .conf /` | 1760.8 ± 10.2 | 1744.6…1775.3

<comment><USER4> Looking at the code, I believe because fd uses a loop, and ff uses function recursion to walk the path tree. Function recursion is easier to write, but definitely has some overhead.

<comment><USER5> My experience is that if you have to maintain your own stack (which you'd need to in order to recursively walk directories) its faster to use the builtin stack than to implement your own.

Further, it seems that this would IO-bound not CPU-bound so whatever small overhead exists in recursion vs iteration will not be noticeable.

I think the difference is rather that `fd` uses threads and `ff` does not.

<comment><USER6> > `fd` uses threads and `ff` does not.

Author here. This is true. ff does not use threads right now. I have started learning Rust just a few days ago. I am not quite yet familiar with advanced topics such as achieving parallelism using threads in Rust and other similar stuff. My knowledge of Rust is limited at this moment and I struggled to get the language concepts to work such as ownership, lifetimes, etc. I am sure that I will be able to improvise the ff's performance by some extent by gaining some more knowledge of Rust.

<comment><USER6> UPDATE: Now ff also uses threads to achieve parallelism.

</comment></comment></comment></comment></comment><comment><USER7> First, I have a problem with rewriting common utilities (like find, which also supports more search functionality than regex) while changing flags (e.g. `i` to ignore case to `s` - incidentally, grep also accepts `i` to ignore case). It makes it harder to explore the system interactively, particularly for beginners.

Second, the utility already exists, and this version is significantly slower:

      > time ./ff '.*.cpp' ~/src/ > /dev/null

      real 0m1.195s
      user 0m0.488s
      sys 0m0.671s

      > time find -E ~/src/ -type f -regex '.*.cpp'  > /dev/null

      real 0m0.880s
      user 0m0.407s
      sys 0m0.425s

But wait! This is a totally unnatural use of find. If we use find like users actually do, we get even better performance:

      time find ~/src/ -name '*.cpp'  > /dev/null

      real 0m0.553s
      user 0m0.181s
      sys 0m0.363s

Hardly scientific. But it begs the question: who is this for?

<comment><USER8> tbh find's command line interface is extremely unnatural, and that alone would justify a switch for me. Ofc, there's no reason that the program itself needs to be reimplemented beyond its argument parser, but that's not that concerning for me as long as its still _fast enough_

</comment></comment><comment><USER9> Here is a bash/zsh port:

alias ff='find . | egrep'

<comment><USER10> This will show all files where _any_ of the path matches, not just the leafs

<comment><USER11> `find . -type f -name "$1"` should give you that and potentially faster than GP since you don't need to do any I/O to a second process.

</comment></comment></comment><comment><USER12> Why do "convert everything to rust" people appear to prefer solving already solved problems instead of focusing on problems we could not solve but are now possible thanks to Rust?

<comment><USER13> Have you used these command line utilities yet? They're great!

Exa, ripgrep, fd, bat, broot, ruplacer

And more...

<comment><USER3> I'd recomend lsd over exa. Which I also use to replace tree. I haven't heard of broot and ruplacer before, but they seem cool.

I've got this in my .zshrc:

      alias ls='lsd'
      alias tree='lsd --tree'

<comment><USER14> > lsd

Tangent, but man is that a bad name for a CLI tool. Had to add a lot of keywords to not get drugs-related pages.

<comment><USER15> "!gh lsd"

Though yes, many computer-thing names are bad in the search department.

</comment></comment></comment></comment></comment><comment><USER16> Someone already opened an issue to make it ignore files specified in `.gitignore`. A `fd` is doing it, `rg` is doing it, now someone wants this to behave the same. I don't know. Maybe I have some really strange expectations but when I want to find a file and nothing comes up as a result, I want to be sure nothing is there. And I want to be sure without remembering bunch of command line options or setting up aliases everywhere I log in because, guess what, maybe they invented some other file with patterns to ignore. Is it only me?

<comment><USER17> That's the great thing about these tools. There is no need to serve as fundamental tools of a system that conform to some ancient spec like POSIX. There is no need for that because those tools already exist and work well. So if that's the behavior you want, then just use those tools. They work exceptionally well when called by other programs, like shell scripts, because they have reasonably standardized behavior.

But with these tools, we have the freedom to revisit old assumptions. One of those is smart filtering. I can't tell you how many people tell me that they enjoy that as a good default.

Tools should make the fact that they do smart filtering very clear, because it can be surprising if you aren't expecting it. But otherwise, I'm not particularly sympathetic to your reasoning here because: 1) what I said above about standard tools being available and 2) these tools should have ways of disabling smart filtering. So if it bites you, it should bite you only once. After that, you either learn to like it, learn to setup an alias and forget about it, or ragequit the tool.

</comment></comment><comment><USER18> How does this compare to fd, which provides similar functionality and is also written in Rust?

<comment><USER6> I have answered a similar question here - [https://github.com/vishaltelangre/ff/issues/4](https://github.com/vishaltelangre/ff/issues/4).

</comment></comment><comment><USER19> Here's a simple version of a file find command utility, written in D, minimal features, may be useful for beginners to D:

Command line D utility - find files matching a pattern under a directory:

[https://jugad2.blogspot.com/2016/10/command-line-d- utility-f...](https://jugad2.blogspot.com/2016/10/command-line-d-utility-find- files.html)

The D stdlib's dirEntries() function makes the job easy, for a basic one like this.

<comment><USER19> Also, related, a bunch of D command-line utilities, again may be good for beginners to learn a bit from:

[https://news.ycombinator.com/item?id=18338952](https://news.ycombinator.com/item?id=18338952)

</comment></comment><comment><USER20> What does this tool provide that I can't get from a wrapper around gnu find?

<comment><USER21> It might also be valuable to projects like Redox.

<comment><USER6> Related discussion - [https://www.reddit.com/r/rust/comments/av31ae/ff_find_files_...](https://www.reddit.com/r/rust/comments/av31ae/ff_find_files_by_name/ehcanyn/).

</comment></comment></comment><comment><USER22> That's fun! I needed something like this and wrote my own a while ago. Choose to implement it with a different algorithm though instead of regex.

[https://github.com/kbacha/file-finder](https://github.com/kbacha/file-finder)</comment>