BEACH
ThoughtStorms Wiki
BEACH stands for Beautifully Easy And Carefree Hacking
An umbrella term for all those sporadic thoughts on The Ultimate Programming Language, IDE, UserInterface etc. My take on FutureCoding
Had it's own wiki, currently dormant : http://www.nooranch.com/synaesmedia/beach/wiki.cgi Will eventually be shut down / merged here ...
BEACH in a nutshell
Not one big idea or product ... several smaller, ongoing experiments.
ProgrammingWithAndInWiki
Developing CardiganBay into a wiki-like (multi-page + fluently hyperlinkable) editing / LiterateProgramming environment / SmallTalk-like SmartAcademicNotebook. We'll be able to write libraries, and script. And host BotsOnWiki that crawl them and like a make script export and build them into finished software.
(See also SpittingCobra)
Thoughts on Ideal Programming Languages
Read IdealProgrammingLanguage for thoughts on how programming languages should evolve.
Assemblage Programming
(ReadWith) AssemblageProgramming
A key paragraph from that Ideal Programming Language answer /essay.
It's that mismatch between a program that thinks of itself as a network of interacting objects, and a language that has no explicit concept of "a network of interacting objects" and no convenient way to express it, that makes Java and friends such hard work. Somewhere deep in the heart of the UML is a good intuition, struggling to find a viable implementation.
OO is a great idea, but what makes it so (IMHO) unnecessarily hard is the insistence on such hard boundaries and information hiding between objects. Instead we need OO languages that have a first-class concept of "network of objects" or "schemas" of how objects combine.
I'm calling this higher level aggregation of objects an "assemblage".
I need to work this idea out a lot more ... and implement something.
But the key features of an assemblage are :
- There's a single definition of the schema of how an assemblage of objects fits together. In a single place. Where it can be consulted and edited, as a first class citizen. (Ie. NOT distributed across multiple classes, files, constructors etc.)
- The definition is declarative rather than imperative. Ie. not in the form of a "factory" which tells you how to construct. But something more like HaskellLanguage's AlgebraicDataTypes or BNFGrammar or ClojureSpec etc.
Escaping time.
A Twitter conversation https://twitter.com/brandontoner/status/1413658904223834114Lol reflecting on the fact that I was excited to be done studying so that I could go study internet stuff again. Quote Tweet
Just got through a big couple weeks of school and work — back to learning about websites and blogs Nerd face Brandon Toner Seedling
Self-directed learning quests >>> School-directed learning quests
Funny part is that I would legit study the stuff I HAD to study, for fun — at the right time in the right mood.
Butttt I respond way better to being able to CYOA rather than sticking strictly to a syllabus.
This is the key insight to a lot, I think. Work becomes far easier when it's "asynchronous" and you do it in your own time. I'm thinking a lot about how programming can be made like this ... \1
Far too much programming has to be done in a sequence that suits the machine, rather than a sequence that suits the programmer. Breaking THAT low-level dependency I think is the key to unlocking the next, higher level of programming. \end
Hmmmmm yea. I feel that.
There’s some tricky context and dependency work for making that legible. Brandon Toner Seedling
Like, most ideas I have — about anything really, are at some weird middle part in any process.
My mind creates enough of the context to make the idea fit at the time, but to capture allll of that felt context is challenging.
Ideas never start at the beginning.
And maybe there IS no beginning (hello metaphysics).
So placing ideas (or work) in context is important for using it as a building block in the future.
Most process-related ideas I have while working (in the pharmacy, for example), are a really specific tweak to improve a nuance somewhere.
But documenting that is a pain in the butt because there is no scaffolding to attach the idea.
Exactly ... this is what tools should be doing for us. Capturing our work at the point we have the great idea, and then automatically routing it to where it needs to be.
Instead, we have to go to the work space / document and find where to insert the idea. That's crazy.
Hmmmmm — so machine-assisted context-building.
And capture-assistance.
And organization-assistance.
So that you can focus on the human part — creation.
Similarly for time. If I'm starting to write a program from the bottom up, and I'm working on the "model" part, but I have a great idea for the UI, I should be able to capture that THERE & THEN. In a way the computer takes note of. Even though there's no other UI code written.
It shouldn't be that I can only tell the computer I want the "OK" button to be green, only after I've built a load of other infrastructure. If I have that idea now, I want it captured now. And then used whenever it becomes relevant. \1
This is what I mean by not having my (programmer) time, tied to the low-level time of the computer. \end
What do you think would be necessary to facilitate that shift?
I mean to write this up in more detail. Probably the best description I've written anywhere so far is here : https://quora.com/How-would-you-design-the-perfect-programming-language/answer/Phil-Jones-He-Him (further down the answer)
But it requires 2 things ... \1
1) A language that's more like giving the machine a collection of Prolog facts about how the final system should be.
2) Unlike Prolog though, the system always has a running template or "archetype" of the program. And the extra facts you give it just describe differences between the archetype, and the eventual program.
Because it's in this form, you can also add / capture opinions about things that you haven't specified fully yet.
So a program could be :
programIs(WebApp) color(OkButton,Green)
That would be enough to pull out the WebApp template. (Which runs but does nothing). And stash the fact that whenever there is an OkButton, it will be Green. (Even though there isn't one yet).
This is the current train of thought ... \end
Yea yea yea.
So the template gives you the basic structure you can hang things on.
And you can identify new pegs for future-use as you think of them.
Peg can come before the wall, even.
I think even if you have a basic architecture mapping — you could map ideas to general parts of the structure.
Giving you somewhere to put ideas as they arise.
Organizing and activating them later.
Yeah. So the outline above is the long-term, more ambitious goal. The shorter term which I'm actually working on, is ProgrammingWithAndInWiki ... basically to be able to embed coding within a more general wiki-like workspace. And, in a "literate programming" like way then be able to pull it out and assemble it into finished projects. So the library of reusable code is developed, tested, shared etc. in a wiki-like environment.
Then over time, move towards having higher level specifications or DSLs and code-gen etc. within that ecosystem. So that you are kind of always one or two hyperlinks away from the place you need to be to write / edit / fix a piece of code or a schema or specification.
Inspiration
- SmallTalk and pretty much everything AlanKay has done.
- http://www.eskimo.com/~goody/links/back.to.prsnl.cmptng.html
- http://www.gnu.org/gnu/rms-lisp.html
- http://www.paulgraham.com/popular.html
PaulGraham says languages need to allow hackers to hack something. C for Unix, Lisp for Emacs, Ruby for Rails. RichardStallman talks about the way Emacs is made of LispLanguage.
CarlSassenrath has created a language plus platform (RebolLanguage) which look very interesting, but are probably never going to become big because he chose to keep them proprietary. Still, the Rebol design and bundle looks very nice. (See RedLanguage for an open-sourced version)