rtens

If I understand you correctly you're probably thinking about how more concise notation systems make things easier for experts but harder for novices, e.g. maths and music scores, and probably Haskell as well.

So I suppose you mean "Things that are easier to understand for novices [...]".

But that's not always the case which is incidentally proven by your examples. Assembly Language is a lot easier to write and understand for novices than machine code. And Fortran even more so. Bret Victor illustrates this very nicely in the video I linked to.

I'm convinced that the power that makes something more concise and at the same time easier to write and understand is abstraction. Or more precisely, the right abstraction, since a bad one can have to opposite effect. So I agree with you that better and more powerful abstractions are always good. Spreadsheets for example are a great abstraction for some problem but terrible for others.

So in order to "leverage powerful concept" and "express complex ideas" you need to be able to create your own abstraction. In this way my proposal is very different from Excel which barely allows to create any new abstractions.

What the manifesto apparently doesn't make clear is that I'm not proposing a new programming language but a programming model. The language part is more like byte-code than Java but it's really a protocol. The result is something that would serve a similar purpose as HTTP but would be vastly more powerful.

I think the mistake that these "language designed for children" that you have in mind is that they add training wheels instead of removing the pedals. The latter manages way better to teach you the basic concepts (steering, balancing) first and once you mastered these, gears and transitions increase your efficiency.

When it comes to software, I would take a similar approach and create a software authoring/execution environment that can be used by novices and experts alike. Novices would learn the concepts (message passing, abstraction) without actually writing code. The coding would then be added to increase the user's efficiency by providing a more concise notation. The actual language used would best be domain-specific to achieve maximum efficiency.

Nice to meet ya as well! Your material looks very exciting. I'll drop you an email once I've digested it all.

That's one of my all-time favourite books so if I hadn't read it I'd be eternally thankful to you for pointing me to it =) It definitely blew my mind.

It didn't make me feel that mathematics is somehow limited though. As far as I understand Gödels theorem, all he says is that there is no such thing as a contradiction-free system of axioms a la Principia Mathematica.

But that's fine with me. I keep tons of contradicting believes in my head all the time. And I'm actually not that interested in simulating an entire brain (although that would be very exciting) but the thing I really care about is the ability to express a part of my mind that I care about in software, sort of like expert systems do. And as a software developer, that's exactly what I do everyday with the minds of my clients. That's also the main idea behind DDD in my opinion.

This topic deserves an essay. If I manage to wrap my head around it, I'll publish something on my blog this week.

I want to "increase the number of people who are able to write, modify, combine and share software by building a tool that makes writing software easy and fun, and accessible to everyone." I even have a slogan. I call it "Enabling Software Literacy"

That said, I'm highly skeptical towards the "good ideas can be stated in a sentence" heuristic.

That's probably the biggest weakpoint of the manifesto but also kinda on purpose. While the thesis was all about "let's build something" the manifesto is a fresh start trying to answer the question "what is the problem?". The thesis is still relevant but a bit outdated and I'll probably rewrite it in multiple blog articles.

What I'm planning to use as information starting point is zells.org but it's all still in an early stage. At the moment I'm working on creating a document that visualizes the "end product" that I have in mind.

I must admit that I have only very limited understanding of numeric and cryptography. But I do find these very interesting discussion points.

The uncomputable real numbers are the irrational ones, no? But those you can compute to an arbitrary precision. It's just for most applications, you don't need much precision. But again, I've not done very much simulation so I might miss something.

Patterns are something I haven't thought about in this context. I'm not entirely sure what kind of patterns you're talking about. I'm guessing software patterns. I was thinking about abstract patterns and had to think of Deep Mind and how it learned to play Go by recognizing patterns.

I stay with my statement about security. I never said that it's sufficient. But necessary. I think a cryptography-enabled capability-based security model could be very interesting.

Will definitely read Aaronson's talk. That's a very interesting subject.

Ah words. That might be the wrong one indeed. I guess I always assume the benevolence of the reader while I'm writing. But precision is important.

What I meant was that in that virtual world they can be replicated. So the replications would be virtual themselves. I better make that clearer.

What do you think those reasons are? In case of HyperCard I think it's that there wasn't any inter-stack-linking let alone networking. What I'm crying about is that Smalltalk was not the future.

Why are computers not trustworthy nor ever will be?

That's great. What's your target group?

What should be the punishment for premature optimization?

The thesis mentioned elsewhere contains some concrete examples but my goal with the manifesto was to get to the root of the problem I'm trying to solve which is quite abstract indeed. I do not have a document yet that visualizes what I want to build but I'm working on that. I'll post updates on twitter.