pcmonk

Front page with demo videos: http://urbit.org

DRAKON is one of my favorite old-time visual programming languages. There's a lot more information on the Russian Wikipedia page, including an astounding 225 references: https://ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E...

I worked on a similar project for a while (the poorly-named Phlisped), and I came to many of the same conclusions as these guys did. A few notes:

I'm not sure reducing keystrokes is a useful measure. I can't think of a better one, though, so at least it's something quantifiable.

Pure tree editing, with no text editor to fall back to, is important. I didn't even use textual output, while it sounds like these guys did. They also used javascript, which is interesting since it has so much syntax. Lisp seems like a natural choice to me since the tree structure is readily apparent.

Dogfooding is critical, and it's very natural for a project like this. When I got to that point, I learned so much about what was really important in an editor. Like macros -- those helped so much.

Keyboard-based editing of trees is possible, but it takes significant effort to make it feel decently natural.

Collaboration is definitely the most important thing people in this area need to learn. There are dozens of projects similar to this one, and they're generally created by solo programmers (like I did) or by pairs (like Prune). Tree-based editing will never take off until a group of like-minded programmers gets together and makes it happen. I've been pulled away into an unrelated project, but if I were to come back to this, my first move would be to get some collaborators.

I'm not sure the words "project" and "company" are the best words for it, but this idea is definitely important. It's a general principle in life to never take yourself too seriously.

If you find yourself not doing something because you don't think it's worthy of the fine company you've built, you're thinking way too much about the formal company and not enough about the ideas, work, and vision that made the company what it is.

The code generator is awesome. There's hardly a syntax error. The file headers are the best.

Nitpick: although tty == tty is, as you say, vacuously true in this case, that's just because tty is a pointer. If tty were a float, this wouldn't be the case, since it could be NaN. I wouldn't be surprised if it learned to test a variable for equality against itself from some floating point code.

Welfare cuts, privatization, etc. "widen the already unsustainable systemic inequality that poses an existential threat for our entire species."? That's insanely hyperbolic, and it makes it difficult for me to take the rest of the article seriously. If our species disappears any time soon, it's not going to be because of welfare cuts.

This is a good article that comes up every so often. If you haven't read it, you should. The art is not quite as lost as advertised, though. A lot of C programmers pack structures that way out of habit.

There's definitely some cases where you shouldn't follow the "biggest to smallest" ordering, but they're usually pretty obvious when you run into them. They usually involve inheritance and such.

I've personally been pulled into another project, but I do think there's plenty of unexplored space in the structured code editor arena. Paredit is good, but I'd like to see a more visual way of dealing with the structure.

The challenge is, of course, that a general-purpose tree editor is not likely to be efficient for editing code. You have to resist the urge to over-generalize. A good structured code editor isn't likely to be useful for anything besides coding.

I grew up homeschooled in the Phoenix area, and and most of my friends' families had a single income. My dad is an engineer, and even though I have ten siblings we lived just fine on that income. My mom worked briefly as an engineer before she decided to forgo that to homeschool us. It's definitely a cost, and if this article is missing anything it's not clear enough that homeschooling is a large commitment.

Many of my friends' parents weren't engineers, and some would fall into the "poorer families" category, but they still decided that forgoing an extra salary to homeschool their kids was worth it. It's a very real trade-off, but given most people's level of spending, it's not that hard to cut down quite a bit while maintaining an excellent quality of life, if you have a good enough motivation.

Having been homeschooled myself, I can attest to most of the advantages he describes. Personalized education is a very powerful thing, especially for what he calls "asynchronous learners".

This is something the compiler can't optimize very well. For one thing, the spec requires that they appear in the given order.

If this wasn't the case, a significant amount of code would break. I've seen a good bit of code where there's a struct A, and then struct B begins with the same fields as in struct A. This allows you to treat either of them as a struct A, a kind of polymorphism. The compiler doesn't know whether you're going to do that, so it can't arbitrarily rearrange the members of the structs.

> I think human intelligence hits an asymptote due to mortality. There's only so deep an individual can go, and a limit on how much you can replace depth with breadth.

I don't know exactly what you mean by "human intelligence", but in general we get deeper not by stretching vertically, but by moving vertically, if you follow the metaphor. Many software engineers today don't even have a passing familiarity with the deeper levels of the stack they're programming on, and that's all new stuff in the last ~50 years.

Which part of the right supports basic income?

"It is unique in that it is in written mostly TeX and hence is a somewhat more elegant design than other converters. A small portion of it is written in Perl."

I have no conception of how any software written mostly in TeX with a little bit of Perl could have "elegant design" as a selling point.

And of course, this is on the same day as their cybersecurity summit at Stanford.

I'm a bit out of the loop on hardware startups, but has YC funded many successful hardware startups? The only one I've heard of is Pebble.

Lowering the barrier to hardware startups is an awesome thing, of course. Hardware has a greater potential to directly impact lives at this point than software. There's tremendous software power locked up in the small, awkward-to-use computing devices we call phones, tablets, laptops, desktops, and servers.

Stack Exchange has a convenient list:

http://meta.stackexchange.com/questions/9134/jon-skeet-facts

Man, that map is impossible to read. Even as a fairly mildly colorblind person, there's no way I can distinguish the colors.

Urbit is not intended to be deliberately obscure. Communication is hard, especially with such radically new ideas. That's why we're building this repository, to lower the barrier to entry. Urbit is vast and new and often difficult to comprehend, but if there's any way we can help you guys understand it, let us know.

I suspect even "I can think of no use case for this app" would be more appreciated than "is it fully buzzword-compliant?"

Additionally, phrases like "What you're really saying is that you have the rewards system of a child" are exactly what I'm talking about. That statement is intentionally worded as an attack, so I have to make a conscious effort to not get defensive. If you want an actual discussion about how rewards systems may change as people grow up, we can talk about that. That was an extremely ineffective way of starting the conversation, though.

When I feel like I'm doing good work, I'm a lot more productive, and I care more about doing things right vs just getting them done. Obviously constructive criticism needs to happen -- the author isn't disputing that. In fact, she says "it's been tough to get useful feedback" because people care more about cutting the other person down than actually evaluating the work.

It's very easy to couch constructive criticism in a few words of sincere praise/recognition of their work, and it generally results in them doing better work in the future. In fact, they'll be much more likely to listen to your criticism if you haven't immediately put them on the defensive. Once either side gets at all defensive, it's extremely difficult to have any kind meaningful conversation. If you always say "this is crap", then you're literally asking them to defend themselves.

If you haven't already, I would recommend reading "How to Win Friends and Influence People" by Dale Carnegie.

I see this argument come up all the time to argue against typing faster, learning a decent editor, and now typing vs writing. Like with you, the hardest part of my job, and also the most time-consuming, is thinking out the right solution. I draw different lessons from that than you do, though.

First, since thinking is the hardest part, it's important to eliminate as many distractions as possible. Having to break concentration because I'm writing/typing is very unhelpful. Writing or typing with poor typing skills breaks concentration for longer periods of time.

Second, a nontrivial part of "thinking" is actually reading code spread across multiple files. Since I use vim, typing speed helps me to quickly get to the sections of code that I need to review. This greatly speeds up the thinking process.

Of course, I definitely do write stuff out at times, and I find I can think very well with a whiteboard. These are mostly for things that need to be diagrammed out in two dimensions (which a lot of things do need to be).

I love how everybody is high in self-expression. I'm not sure, though how cperciva ended up on top in need for harmony.

It's not any shorter. The extra check as to whether or not to print the line break cancels out the mod 15 check. In my opinion, it's cleaner to have three conditionals of the same type than two checking mods and a third checking the OR of the first two.

Of course, it can be actually shorter with a goto.

Thinking more rationally in a foreign language is actually a well documented[0]. I know I myself have noticed it.

http://www.huffingtonpost.com/2012/04/25/foreign-language-de...

I love how they're also contributing upstream to libuv. This is how you do an open source, community-focused project.

Just because a language allows you to morph its syntax doesn't make it any more powerful. I'm not sure how this is considered an "advanced" thing. It's certainly a convoluted thing, but that's not at all the same.

To me, the first is much easier to read, but perhaps my mind has been warped by functional programming languages.

At any rate, the thing that's strange about it is how verbose and hackish everything is. It's obvious the language wasn't designed to do anything like this, so the only way you can incorporate features like this is with unnecessarily obtuse and complex blocks of code.

How can any sane person think this is a reasonable way to program?

While perhaps stated with slight hyperbole, this is actually a serious question. I don't see how, for example, these pipable functions give any additional real expressive power, and they seem incredibly hacky in how you have to build them. I simply don't understand why anyone would use this kind of thing. C makes sense; I can see an argument for C++03; this is madness.

I'm deuteranomalous too, and I first thought, "I can distinguish these colors easily, I'm glad they chose colorblind-friendly colors". Then I read the color list and realized there were more colors than I thought.