For discussion: I am thinking that FoC should be done with “dynamic languages” (Lisp (pre-CL), JavaScript, REBOL, Self, technical diagrams, etc.). PoC (Present of Coding) languages, e.g. “static languages” like Haskell, Rust, C++, etc., and, compiler-appeasement dynamic languages like Python, Racket, Scheme, Smalltalk, Common Lisp, etc., are used to optimize and to structure FoC ideas, but, they inhibit out-of-the-box-thinking. Writing the program twice (or more times) is more efficient than writing the code once only in a PoC language. What is “efficient”? At one extreme: all Design and no optimization, at the other extreme: all Production Engineering (optimization) and no Design.

I'm not sure I fully understand how you classified each of those languages, especially Scheme and Smalltalk, but I love the phrase "compiler-appeasement." It really captures the concept of limitations that arise from the accidental complexity of implementation, and not the effort to make a usable and useful design.

For me the language is irrelevant; it is the idea that is important. Use the tool that will get the job done.

@guitarvydas The two lists of languages don't make any sense to me. Can you expand on how you think Smalltalk is more of a compiler appeasement language relative to Self? @Chris Maughan I don't mean to be rude, so please try to take this in the collegial spirit with which I ask it: what do you think that comment adds to this conversation?

I used to be a scala programmer and types enthusiast but I have totally moved to dynamic languages because they are so much faster to develop with. I used to create rube-goldberg type frameworks that would enforce various constraints via metarpogramming, but then I read this article that showed compile type checking could be reduced to runtime checking and we just keep moving the same undecidability problem a level outwards... and it clicked, that all this type stuff was almost pointless, I was trying to do runtime computation at compile time, but with worse debugging tools. It was silly. Consider this:

I write a bug, I try to compile it, and the computer refuses to, and highlights a line with an error

vs

I write a bug and I run it, and the computer crashes and highlights the the line with a stack trace

Anyway, I shifted my focus to visibility at runtime and I think it's a better tradeoff for than types for smaller programs. VERY large software spans the network and database and those are untypes so everything becomes dynamically typed eventually at the other end of the scale too.

My dream environment is yet a bit different: a live-coding system inside which I can define subsystems that subject to static verifications, but using type systems (plural!) that I can define myself. Details: https://science-in-the-digital-era.khinsen.net/#Static%20type%20systems and https://science-in-the-digital-era.khinsen.net/#Formalization

Hi @Jack Rusher , apologies if I came across as flippant; not my intention. I merely wanted to suggest that speed of execution might be faster if you use the tools you know best. I've found that, while fun to try different languages, there is a knowledge wall which eventually inhibits progress. Sonic Pi comes to mind. I've been a core contributor to that for a while. It is implemented in no less than 4 languages; C++, Elixir, Ruby & Erlang; with significant code in each one. While a great project, progress is inevitably slow because Sam is really the only one that comes close to understanding how everything works. One thing I've heard Sam say is that ‘Elixir gives me this nice real time scheduling which is great for music’. My personal opinion is that you can achieve that just as easily with most languages. They are all just deep stacks sitting on your CPU. The down side of the approach is, as I say, speed of implementation. The barrier to entry for Sonic Pi development is huge; it requires technical abilities in many areas to make significant contributions.

I'll just add, that in my opinion, Go is a master class in language and tooling design. It may be the last great work of some computing legends (Pike, Thompson)

@Chris Maughan No big thing! My reaction came from: 1. Programming languages themselves contain ideas, and ideas about how to make better programming languages are very much in scope for FoC efforts. This is especially true when we consider the environment in which a language is embedded, rather than reducing it to syntax + denotational semantics. 2. It was phrased in such a way that it seemed like it was trying to shut down @guitarvydas's thread. (Probably not your intention!) A question about "you can achieve that just as easily with most languages" — do you think it would be "just as easy" to build Erlang's OTP or write a real-time scheduler in Ruby?

how to make better programming languages

How does one define better?

1. Programming languages themselves contain ideas, and ideas about how to make better programming languages are very much in scope for FoC efforts. This is especially true when we consider the environment in which a language is embedded, rather than reducing it to syntax + denotational semantics.

Yes, I was thinking more about how to 'implement' those new things; languages or otherwise, to be efficient.

2. It was phrased in such a way that it seemed like it was trying to shut down @guitarvydas's thread. (Probably not your intention!)

Certainly not; just a too-brief reaction to the post!

A question about "you can achieve that just as easily with most languages" — do you think it would be "just as easy" to build Erlang's OTP or write a real-time scheduler in Ruby?

That is a very fair point; maybe using a C extension 😉 Perhaps 'you can achieve the most in the quickest time using a language you know'. i.e. I could probably build a scheduler the fastest in C++; and you (speculating) might build one faster in Lisp than Ruby.... etc.