ref: b7931064b8c74dbb24085063d20260b4c58928e2
parent: 9c49c127ff2c3698d809cb867961d2913c863a03
author: kvik <[email protected]>
date: Thu Oct 29 12:55:24 EDT 2020
language-ideas: add article from old wiki (thanks aiju)
--- /dev/null
+++ b/language-ideas.md
@@ -1,0 +1,74 @@
+# Language Ideas
+
+This is meant to be more of a brainstorming thing than a specification.
+
+## General Spirit
+
+* minimum-noise
+* trying to find a middle ground between imperative and FP that isn't just mashing the two together blindly
+* readable (but not in some silly "looks like English" kind of way)
+* writable WITHOUT an IDE / fancy editor.
+* simple, as long as it doesn't compromise anything else. NOT C++.
+* don't want to worry about abuse potential, trust developer to be sensible
+* ultimately translates to C / machine code. but earlier implementation might be byte code
+
+## Syntax
+
+* good syntax is important, but don't fall for syntactic sugar or trying to make things too cute (fucking scala...)
+* braces and semicolons
+* generally a "flat" style is easier to maintain and debug imho, even if it's technically longer (where do you even add debug-prints in a giant stack of higher level functionals? unix pipelines are slightly easier here but not much)
+* C-style type notation are too hard to parse and too hard to generalise for things like tuples, it's probably not worth it.
+* postfix notation is surprisingly useful (think unix pipes)
+
+## Type System
+
+* some weird merger of Go and ML?
+* want structs, union types, tuples
+* haskell typeclasses / go interface
+* parametric polymorphism
+
+## OOP
+
+* Basically, no.
+* However, methods solve some tricky namespace problems. Maybe worth it?
+
+## Modules
+
+* Basically, Go.
+
+## "Data-driven thinking" / Traits
+
+In C you often end up with giant structs which looks like
+
+ struct MegaStruct {+ a bunch of properties used by all
+ ...
+ a bunch of properties only used by code A
+ ...
+ a bunch of properties only used by code B
+ ...
+ a bunch of properties only used by code C
+
+This is bad for modularity, but there isn't a nice way (in C) to avoid it.
+What you really want is a way to specify these things separately, together with the code that manipulates them; in fact keeping them separately in memory might be a good idea too (improves cache locality).
+One approach is to define a bunch of "traits" like
+
+ trait MegaStructPartA {+ only those properties used by A
+ }
+
+An object is then only an accumulation of certain traits.
+
+## Testing
+
+* Being able to specify test-cases in-line seems like a good idea.
+* Also properties for quickcheck-like testing
+
+## Crazy Ideas
+
+* laziness-on-demand: values can be lazy, so that you can do things like
+ a = async request_a();
+ b = async request_b();
+ c = a + b;
+ which issues both calls simultaneously.
+* labels-as-closures: a goto-style label can be used in an expression to create a closure for the rest of the function