Title
#thinking-together
g

guitarvydas

08/16/2022, 3:55 AM
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.
p

Personal Dynamic Media

08/16/2022, 4:03 AM
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.
c

Chris Maughan

08/16/2022, 6:23 AM
For me the language is irrelevant; it is the idea that is important. Use the tool that will get the job done.
j

Jack Rusher

08/16/2022, 6:43 AM
@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?
Tom Larkworthy

Tom Larkworthy

08/16/2022, 7:28 AM
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.
Konrad Hinsen

Konrad Hinsen

08/16/2022, 7:57 AM
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
7:58 AM
I don't want to switch languages, and in particular I don't want to change run-time systems and have to deal with data conversion, when I move from free-style to formally verified code.
c

Chris Maughan

08/16/2022, 8:48 AM
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.
8:57 AM
… mostly I'm addressing @guitarvydas point ‘what is efficient’? To be fair, he is also asking about how languages change ‘thinking’; that is certainly true.
Tony Worm

Tony Worm

08/16/2022, 1:06 PM
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)
j

Jack Rusher

08/16/2022, 2:57 PM
@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?
Tony Worm

Tony Worm

08/16/2022, 2:58 PM
how to make better programming languages
How does one define better?
c

Chris Maughan

08/17/2022, 11:13 AM
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.