Jon Purdy

Ah, okay.

So by less syntax you mean fewer syntactic forms (parentheses, curly braces, do notation, etc.) and keywords (class, public, etc.) in the language.

I think in general, languages with fewer syntactic forms also have fewer but more powerful abstraction features. Lisps are pretty high up by this measure. They basically only have one abstraction feature: lambda expressions. Other languages have powerful abstraction features but more of them, like Haskell (lambdas, pattern matching, monadic do notation). And others have many but less powerful abstraction features (e.g. Java).

On the one hand, I certainly agree with you that more powerful abstractions make it easier to program. Once you've grokked the abstraction, you only need one brain "chunk" to deal with it freeing up your other chunks to work on the problem. If you need to juggle several different abstractions (e.g. wrap up your closure inside an object inside a class), you have fewer chunks to work on your problem.

On the other hand, people tend to have difficulty learning these higher abstractions in the first place. Alan Kay, in that quote, points out that young children (I think less than ~8 years old) have difficulty with the abstraction of parameterization. In particular they have trouble with mentally corresponding the placement of a parameter in a list with its role in the function. Named parameters make things a bit better, they help the children keep track of the role. Explicit variable assignment…

Could you support your claim that running times are irrelevant? I understand you want to keep your blog post (or "blarticle") short. But maybe you could elaborate here? I am genuinely interested in your argument.

I think there are other caveat of specifying only the results.

You posted earlier on the halting problem

http://evincarofautumn.blogspot.com/2011/10/solving-halting-problem.html

That post also contains a statement which I believe to be false. You state that the "Haltability problem" (where you are given a program P and want to determine if there exists an input on which it halts) is decidable but its not.

Basically, I can just hardcode any input I of my choosing into P so that it always does the same thing (run P on I) regardless of the actual input I' you provide it. Thus, I can use an algorithm for the Haltability problem to solve the halting problem.

I know that does not pertain to this post directly but the halting problem does. Given a program written in this new language, how can you determine if what the programmer specified can even exist as a program?

In fact, suppose you specify the properties of this new language you current wish to construct (in say, English and assume that everything is interpreted correctly). How do you know such a language could potentially exist (never mind implementing it)?

I also don't even want to think about debugging in such a language. More specifically, I would rather have a library for the example you described…

Have you looked at Kitten? It's statically typed[0], and a descendant of Cat[1], which is a descendant of Joy[2]. So those might also be interesting languages to investigate

> The Kitten Programming Language

> Kitten is a statically typed, stack-based functional programming language designed to be simple and fast. It is a concatenative language, combining aspects of imperative and pure functional programming. There is an introduction available and a tutorial in progress.

http://kittenlang.org/

[0] http://evincarofautumn.blogspot.se/search/label/Concatenative

[1] http://www.codecommit.com/blog/cat/the-joy-of-concatenative-languages-part-1

http://www.codecommit.com/blog/cat/the-joy-of-concatenative-languages-part-2

http://www.codecommit.com/blog/cat/the-joy-of-concatenative-languages-part-3

[2] https://en.wikipedia.org/wiki/Joy_(programming_language)

I like Alan Watts for meditation.[1] I have some mala beads as he suggests, and find they help me a lot. Its easier to time sessions, just count the beads with your fingers and when you reach the end of the mala, you can stop. They also help one to breath/count without consciously focusing on breathing/counting, or even worse, getting stuck in your head trying to focus on not focusing.

Regarding sleep, read something very interesting the other day about Delayed Sleep Phase Disorder (DSPD).[2] Something that might help is a program called f.lux that reduces the blue light in your monitor in the evening, supposedly making it easier it to sleep. I haven't tried it yet but intend to soon.

1. http://www.mediafire.com/?u53kedhwn5w

2. http://evincarofautumn.blogspot.com/2011/09/how-to-be-productive.html

The best reference I can show for the general programming model was a blog post which is not in G, but was called "Why Concatenative Programming Matters":

http://evincarofautumn.blogspot.com/2012/02/why-concatenative-programming-matters.html

which shows you how graphical diagrams can make sense out of concatenative programs.

If you really want an example, then I will give you this with some caution:

http://team358.org/files/programming/ControlSystem2009-/LabVIEW/MovingAverage.jpg

The caution is that LabVIEW views a data source as a sort of continuous input stream, so that it is manipulating individual values at any given time. I would rather view vectors as more fundamental in a spreadsheet language.

There is a new phrasal verb “be a thing” which lets us conveniently talk about such constructions. That is, “now and then” is a thing—an idiom, with a specific meaning outside the wording—but “then and now” is not a thing.

You will note that all of the semantic constraints they propose place the item with a “positive” aspect first—I wrote a blog post about this[1].

There is also a related notion of “stormy petrel”[2] which I wrote a poem about[3] back when I had lots of hair.

[1]: http://evincarofautumn.blogspot.com/2014/08/adjective-valence-and-linguistic.html

[2]: http://www.kith.org/logos/words/lower/petrels.html

[3]: https://www.youtube.com/watch?v=fRlpRFs2L30