Or why not compiling directly to llvm or such, as i made preemptive kernel, i already have some code to manage thread context, and semaphore or that sort of things to manage context switching on a single core.

Ditto above.

I already toyed bit with antlr to make a parser, it can be nice to make transpiler or generate AST from source.

Not sure if that is the tool I will propose to use for creating the parser.
Anyway, much of the work is processing the AST such as the typing engine and the translation from AST to Go. Possibly other tools we might need such as build tool perhaps. Work on integrating libraries and frameworks. Eventually IDE integration.

Original Author: @NodixBlockchain
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392356529
Original Date: May 27, 2018, 2:03 PM CDT

My question was basically why doing a transpiler instead of programming directly in go, what is missing from go that you want to add, but you answered that.
LLVM can be run in the browser too no ?
Im not sure Go is the best language for blockchain because they are not typically massively concurrent things. But maybe for the http/json layer for the wallet requests.
Making good lexer/parser can already be quite some work, antlr v3 can generate AST i think, with antlr v4 need to use visitor class on the parser tree to generate the AST, and there are lot of tools to visualise the parsed tree, and can be used with IDE like eclipse to have autocompletion or such. And it can generate parsers in many languages from the grammar, Its a bit slow to parse though, but can live with it.
Antlr is generally quite Nice to use, the visitor class can be used to do the type checking and that sort of things. Not sure how easy it is To turn the parsed tree back to source, or how it work in the other direction if some grammar can be used to generate source from the tree.
Normally anything you would do with the AST you can do it with the parse tree and visitor class.
I guess it goes in 3 passes, first pass to build symbole table from global symbole and type definition, pass 2 check the parse tree with the types, pass 3 generate the target source from the parse tree.
Generic at fundemental level are close to macros, in the absolute just need to substitute type parameters with the actual type, maybe it require an additionnal pass.
Typeclass can be more tricky with implicit type etc, with generics normally the type is specified explicitly for all instances.
Sometime i really wonder if its not better to allow dynamic type instead of generics, regarding how trivial it is To have lambda functions/closure in any dynamically typed language, compared to the big head ache and complex synthax required in statically typed languages.
https://github.com/antlr/grammars-v4/tree/master/golang apparently there is already a grammar file for Go in antlr v4. But i'm not sure the grammar can really be used to generate source file from the tree, normally more work the other way around.
But it seems generally to do transpiler they just generate the text for the source old school from the visitor class.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392389387
Original Date: May 27, 2018, 7:01 PM CDT

@NodixBlockchain wrote:

Im not sure Go is the best language for blockchain because they are not typically massively concurrent things.

My novel decentralized ledger consensus system is highly parallelized.

Antlr is generally quite Nice to use, the visitor class can be used to do the type checking and that sort of things.

I prefer the compiler to eventually be bootstrapped to self-hosted. So a parser generator isn’t going to suffice or at least not long-term, unless perhaps it’s customized. I have contemplated the possibility of automating some of the generation of the parser from a grammar file. Also @keean had argued that automated parser generators are too limited for a serious PL parser.

Sometime i really wonder if its not better to allow dynamic type instead of generics

We already had those debates and discussion in the other issue threads and I do not want to repeat it in this thread again. The decision has already been made and for very compelling reasons.

LLVM can be run in the browser too no ?

AFAIK, Emscripten only compiles C or C++ and not other LLVM outputs, but I could be mistaken.
Yet who can debug that gibberish ASM.js code any way. I would rather leverage any debugging source maps or whatever debugging facilities that GopherJS or the new Go WASM compiler might have.

Original Author: @NodixBlockchain
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392429033
Original Date: May 28, 2018, 1:11 AM CDT

Antlr is quite powerful, can make full compiler with it, and if the goal is
to transpile to Go, it can do it.
Antlr can do more than parser generators. It can build whole tools on top
of the parse tree. Either static analyser, interpreters, compilers etc
At the basic it can generate a parser, but its only the lower level, the power of it come from listener/visitor class who can work on the parse tree.
As far as i know its the best tool of its kind. After need to do whole lexer/parser/analyser manually, which can be quite a loss of time in itself.
Lexer/tokenizer are easy to do, but making a good parser for complex grammar can become tricky, especially for protyping when things can change often, its easy for bugs to creep in, or for the code to become a bit ugly without a real grammar parser like antlr.
Maybe on long term it can better to redo it manually for performance reason, because antlr is not extremely fast, but regarding feature it can do pretty much anything out of a source code, and it can do fast prototyping. And there are lot of tools around it, it can interface with eclipse etc It can generate parser/analyzer in c++, java, python, javascript.
From what i read from your design its parrallelized in the sense nodes can
process transactions or advance the blockchain in parallel, but on a local
node all transactions needs To be processed in order no ?
Its parrallelized in the sense different nodes can process different shards in the same time, but at the level of a node it still needs to process things sequentially no ?
Le lun. 28 mai 2018 à 06:46, shelby3<EMAIL_ADDRESS>a écrit :
…
 Note the edit:
So a parser generator isn’t going to suffice or at least not long-term,
unless perhaps it’s customized. I have contemplated the possibility of
automating some of the generation of the parser from a grammar file.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Ab61I1lGhbHXbh_gEGGPesXDnfv7DmKRks5t24EsgaJpZM4OZwjF>
.

Original Author: @keean
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392435991
Original Date: May 28, 2018, 1:52 AM CDT

@NodixBlockchain
Can you list any languages that use a parser generator?

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392436023
Original Date: May 28, 2018, 1:53 AM CDT

@NodixBlockchain wrote:
Please kindly move the discussion of compiler implementation to the Compiler Implementation #18 thread. Thank you. I responded to you there.

From what i read from your design its parallelized in the sense nodes can process transactions or advance the blockchain in parallel, but on a local node all transactions needs To be processed in order no ?

Client (light client) nodes could also issue transactions in parallel.

Its parrallelized in the sense different nodes can process different shards in the same time, but at the level of a node it still needs to process things sequentially no ?

No. Ledger (full) nodes can also process transactions in parallel even within a “shard”.
That is why I tried to tell you in 2017 that I could not accept your framework because for one reason my design was considerably incompatible with some of the assumptions you made. Also because I didn’t want to code in C with a boilerplate heavy API. But please I do not want to repeat that discussion of your framework again. Losing time and creating noise in this thread if we revisit that again. I’ve been so slow while treating and trying to recover from my chronic health issues.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392449200
Original Date: May 28, 2018, 2:53 AM CDT

I still want block indenting instead of curly braces.
This is what happens when you force a Python dev to work in Java, for example:

I wrote:

That humorously and succinctly summarizes the argument that curly brace delimited blocks are unnecessary noise in many cases.
Curly braces do facilitate nesting blocks inside of parentheticals but it’s probably bad style to be cramming so much into one expression or statement— given that in the open source era the ability of others to read our code is a high priority.

Original Author: @NodixBlockchain
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392454423
Original Date: May 28, 2018, 3:13 AM CDT

From what i have read, most them used parser generators like bison/yacc in
a first step, and then moved to hand made parser, mostly for performance
reason. The only real down side of parser generators is that they are
slower than hand made parsers. Other than this, they have only advantages.
Le lun. 28 mai 2018 à 08:52, Keean Schupke<EMAIL_ADDRESS>a
écrit :
…
 @NodixBlockchain <https://github.com/NodixBlockchain>
 Can you list any languages that use a parser generator?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Ab61I4HzcpitOHmud9lDpCEXE06_Sudeks5t257JgaJpZM4OZwjF>
.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392456031
Original Date: May 28, 2018, 3:20 AM CDT

@NodixBlockchain please I asked you to reply to him on the Compiler Implementation thread. Please delete your comment from this thread and add to the correct thread. Discussing compiler implementation in this thread is offtopic and is burying the on topic discussion. I will delete this comment after you comply. Thank you.
You can quote him and link to his comment in your reply in the correct thread.

Original Author: @keean
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392456067
Original Date: May 28, 2018, 3:20 AM CDT

@NodixBlockchain
Really? Got any references for that? The reason I ask is because it seems to me that generating good error reports was the main reason. You just cannot get good language specific errors out of a parser generator.
https://softwareengineering.stackexchange.com/questions/17824/should-i-use-a-parser-generator-or-should-i-roll-my-own-custom-lexer-and-parser

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392456127
Original Date: May 28, 2018, 3:20 AM CDT

@keean and @NodixBlockchain  please comply by moving your latest comment to the Compiler Implementation thread. Are you guys incapable of organizing discussion and paying attention to details?
I put in the effort to direct the offtopic discussion to the correct thread, then you guys snub my effort. That is not very motivating when others do not care about the correct effort of others in the project.
This thread is for discussing new features for a new PL. Not for discussing the details of how to implement a compiler. Sheesh. Is that not obvious.
I am obviously not trying to censor discussion nor attempting to restrict anyone. Just trying to keep these issue threads from descending into a chaos. Because I need to refer back to these discussions in the future as a reference for design decisions made. This is not the first time I have written this. I hope I do not have to continue to repeat myself. I know you guys have excellent memory.
If you prefer a disposable free-form discussion on a range of topics, then we can move this to something like Slack.
Not trying to inculcate bad feelings but it seems if I ask and explain nicely as I already did many times, then I am snubbed.
I will delete this comment after you comply. Thank you.
If you do not comply with moving your comments, then this complaint will persist in the public record.

Original Author: @NodixBlockchain
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392456944
Original Date: May 28, 2018, 3:23 AM CDT

As far as i understand, transactions within a shard will still depend on
previous transactions, how do you prevent double spent if transactions can
be processed in parallel ? How do you prevent two transactions with same
input to be processed in parallel ?
Yes i understood you pov with my framework, no worry lol
Le lun. 28 mai 2018 à 08:53, shelby3<EMAIL_ADDRESS>a écrit :
…
 @NodixBlockchain <https://github.com/NodixBlockchain> wrote:
Please move the discussion of compiler implementation to the Compiler
Implementation thread.
From what i read from your design its parallelized in the sense nodes can
process transactions or advance the blockchain in parallel, but on a local
node all transactions needs To be processed in order no ?
Client (light client) nodes could also issue transactions in parallel.
Its parrallelized in the sense different nodes can process different
shards in the same time, but at the level of a node it still needs to
process things sequentially no ?
No. Ledger (full) nodes can also process transactions in parallel even
within a “shard”.
That is why I tried to tell you in 2017 that I could not accept your
framework because for one reason my design was considerably incompatible
with some of the assumptions you made. Also because I didn’t want to code
in C with a boilerplate heavy API. But please I do not want to repeat that
discussion of your framework again. Losing time and creating noise in this
thread if we revisit that again. I’ve been so slow while treating and
trying to recover from
<https://bitcointalk.org/index.php?topic=1739268.msg36504599#msg36504599>
my chronic health issues.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Ab61I3-Zh_08WbYZiexIKDbeCLESbnyDks5t257cgaJpZM4OZwjF>
.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392463597
Original Date: May 28, 2018, 3:50 AM CDT

@NodixBlockchain wrote:
Let me kindly say that (while your interest in my crypto work is appreciated) this is getting offtopic to this thread. Please if you want to discuss my crypto work further, please interact where I post on Steemit currently or in some chat such as LinkedIn.
I will reply one more time only as follows on this particular topic of discussion:

As far as i understand, transactions within a shard will still depend on previous transactions, how do you prevent double spent if transactions can be processed in parallel ?

Transactions are incoming from many users. These are most often not mutually dependent.

How do you prevent two transactions with same input [UTXO] to be processed in parallel ?

By atomically checking if the input UTXO are still unspent when posting the validated transaction to the ledger. The posting operation has to be atomic as well. Validation can proceed in parallel. It's not efficient to test for conflicts before validation because most transactions will be mutually independent. The post-validation check catches the outliers. This would open a DoS attack hole if DoS was not thwarted in general by other means in the holistic design.

Original Author: @NodixBlockchain
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392476827
Original Date: May 28, 2018, 4:42 AM CDT

I ask this to understand better the kind of parallelism you need :) Can be
important consideration, to see which mechanism or expression is best
adapted to represent the problem.
Transaction check can't be atomic at cpu level, no way a 256 bit tx hash +
output idx lookup in an array can be made atomically at cpu level, so it
need some form of synchronisation, hence no parallelism for this part,
unless i'm missing something.
Even if many tx are independants, can't know if they are without checking
first, which i don't see how it can be made without some synchronized
access to the utxo list, which represent the essensential of validation.
Signature checking can be parallelized, but need to see exactly which part
of the validation can safely be made in parallel, if it does the check in
parallel but then need to check it back after in synchronized manner, can
ask what the point of making the validation in parallel at all.
Might go back to steem it, but i have limited time for social networking lol
Le lun. 28 mai 2018 à 10:50, shelby3<EMAIL_ADDRESS>a écrit :
…
 @NodixBlockchain <https://github.com/NodixBlockchain> wrote:
Let me kindly say that (while your interest in my crypto work is
appreciated) this is getting offtopic to this thread. Please if you want to
discuss my crypto work further, please interact where I post on Steemit
currently or in some chat such as LinkedIn.
I will reply one more time only as follows on this topic.
As far as i understand, transactions within a shard will still depend on
previous transactions, how do you prevent double spent if transactions can
be processed in parallel ?
Transactions are incoming from many users. These are most often not
mutually dependent.
How do you prevent two transactions with same input [UTXO] to be processed
in parallel ?
By atomically checking if the input UTXO are still unspent when posting
the validated transaction to the ledger. The posting operation has to be
atomic as well. Validation can proceed in parallel. It's not efficient to
test for conflicts before validation because most transactions will be
mutual independent. The post-validation check catches the outliers. This
would open a DoS attack hole if DoS was not thwarted in general with other
means in the design.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Ab61I5efPYdwRiJqN8hReAzu0Rpl7z8hks5t27pHgaJpZM4OZwjF>
.

Original Author: @NodixBlockchain
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392491298
Original Date: May 28, 2018, 5:48 AM CDT

Go can bind data structure with function prototype, It's not full OOP, but
has some flavor of it, more than being functional.
Pure functional language dont really have channels or synchronisation
things, they can express some level of parallelism on computational
algorithm, but not in the way of Go directly, as having certain code
executed when a (most likely io) event occur, which is essentially what Go
does.
Or the language need some support for something like IO monad, can't really
make IO programing with pure function as far as i know.
But if the functional language can be converted to a dataflow FRP style,
then i can see better how it fits with Go.
Computional parallelism is different from something like Go that is mainly
event driven via channels, and not based on pure functions.
Le lun. 28 mai 2018 à 12:10, shelby3<EMAIL_ADDRESS>a écrit :
…
 @NodixBlockchain <https://github.com/NodixBlockchain> wrote
 <#18 (comment)>:
But your goal is to make a functional language like haskell, and then
transpile it to go ?
More like Python with only typeclasses. We’re not building a religious
<https://www.quora.com/What-are-the-best-languages-for-getting-into-functional-programming-and-why-I%E2%80%99m-looking-for-a-language-with-clear-syntax-active-community-involvement-and-good-documentation/answer/Keith-Adams/comment/63304329>
(c.f. also
<https://www.quora.com/What-are-the-best-languages-for-getting-into-functional-programming-and-why-I%E2%80%99m-looking-for-a-language-with-clear-syntax-active-community-involvement-and-good-documentation/answer/Jussi-Raunio/comment/63304504>
and also
<https://www.quora.com/What-are-the-best-languages-for-getting-into-functional-programming-and-why-I%E2%80%99m-looking-for-a-language-with-clear-syntax-active-community-involvement-and-good-documentation/answer/Viksit-Gaur/comment/63304871>)
pure FP language like Haskell.
I'm not sure the structure of functional languages would be very fit to
express high level of concurrency ,
Pure functions express inherently express parallelism and what can be
safely executed concurrently.
and Go is still pseudo OOP,
Incorrect. The interface in Go is structural typed and is about half-way
towards what typeclasses are.
i'm not sure how efficient it would be to transpile a functional language
to Go in order to exploit the concurrency capacity of Go.
Go is basically C with GC. Most PLs compile to C and FPs typically require
GC.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Ab61I-J2JStbk4tFO4OqBgCuSlPtaOaEks5t280JgaJpZM4OZwjF>
.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392509791
Original Date: May 28, 2018, 7:07 AM CDT

Functional Programming (FP) ⊇ pure Functional Programming
⊇ means “is a superset of”

Go can bind data structure with function prototype

The data structures are late bound to interface same as for typeclasses, i.e. anyone can implement an interface for a preexisting data structure. Haskell is a pure FP that invented typeclasses. But Go lacks type parameters (aka generics).

It's not full OOP, but has some flavor of it, more than being functional.

There’s no OOP in Go in the sense of virtual inheritance and classes with methods.
Go has first-class, higher-order functions, closures, and GC. Therefore it is a FP language. Just not a pure FP language.

Or the language need some support for something like IO monad, can't really make IO programming with pure function as far as i know.

Now you’re getting into that pure FP Haskell religiosity that I’m trying to avoid.

But if the functional language can be converted to a dataflow FRP style, then i can see better how it fits with Go.

Did you not read my response to @keean yesterday stating that dataflow FRP is not what we’re creating.

Computional parallelism is different from something like Go that is mainly event driven via channels, and not based on pure functions.

I think you’re trying to reintroduce the Concurrency thread in this thread. Could you please take this debate over to Concurrency thread. I feel I have already discussed what we are doing many, many, many times and that this is redundant discussion that I do not have time for.
Parallelism is distinct from asynchronous programming. But functional programming is not distinct from asynchronous programming. You’re trying to pigeonhole FP in the narrow Haskell religion of pure FP with laziness and all that monad and “theorems for free” mathematical perspective on programming.

Original Author: @NodixBlockchain
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392520089
Original Date: May 28, 2018, 7:56 AM CDT

The thing is i'm trying to understand what you want to achieve in doing a
functional language to transpile it to Go which is not a functional
language, and of which main interest is the channel / go routine for mass
concurrency design to respond to network events, which i cant see how it
can be expressed very well in a classic functional language.
It's you who mentionned pure functions as a way to have concurrency in
functional language lol
I can have an idea of how functional language can be converted to a
dataflow, and how that fit into Go paradigm.
But i have hard time to get the interest to make a functional language to
represent Go paradigm based on goroutine/channels/network event.
Most likely if you want to use Go as a target language, It's to exploit the
go routine feature, to have mass concurrent processing of network request,
and i have hard time to see how a functional language can be an efficient
way to represent this.
But maybe your interest in using Go is something else than concurrency.
Like using it as a garbage collected C with more hype.
But concurrency is full part of Go language, so It's hard to avoid the
question of how the Go paradigm is to be represented in the source
language. Or then you want to ignore mostly the goroutine/channel/mass
concurrency aspect of Go.
Or you want to transform a functional program into something that use
efficiently goroutines+channels ?
Or just doing something 95% like go, but who can express certain things
with generics/typeclasses and generate the Go code with the type
resolution/monomorphisation ?
Le lun. 28 mai 2018 à 14:07, shelby3<EMAIL_ADDRESS>a écrit :
…
 Go can bind data structure with function prototype
The data structures are late bound to interface same as for
typeclasses, i.e. anyone can implement an interface for a preexisting
data structure. Haskell is a pure FP that invented typeclasses. But Go
lacks type parameters (aka generics).
It's not full OOP, but has some flavor of it, more than being functional.
There’s no OOP in Go in the sense of virtual inheritance and classes with
methods.
Go has first-class, higher-order functions, closures, and GC. Therefore it
is a FP language. Just not a pure FP language.
Or the language need some support for something like IO monad, can't
really make IO programming with pure function as far as i know.
Now you’re getting into that pure FP Haskell religiosity that I’m
trying to avoid
<#31 (comment)>.
But if the functional language can be converted to a dataflow FRP style,
then i can see better how it fits with Go.
Did you not read my response
<#17 (comment)> to
@keean <https://github.com/keean> yesterday stating that dataflow FRP is
not what we’re creating.
Computional parallelism is different from something like Go that is mainly
event driven via channels, and not based on pure functions.
I think you’re trying to reintroduce the Concurrency thread in this
thread. Could you please take this debate over to Concurrency thread. I
feel I have already discussed what we are doing many, many, many times and
that this is redundant discussion that I do not have time for.
Parallelism is distinct from asynchronous programming
<#35 (comment)>.
But functional programming is not distinct from asynchronous programming.
You’re trying to pigeonhole FP in the narrow Haskell religion of pure FP
with laziness and all that monad and “theorems for free” math.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Ab61I_wTUhuPxKlrdlOxD5ceqbTsFeoLks5t2-iLgaJpZM4OZwjF>
.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392530726
Original Date: May 28, 2018, 8:44 AM CDT

@NodixBlockchain wrote:

The thing is i'm trying to understand what you want to achieve in doing a functional language to transpile it to Go which is not a functional language

Haskell can be transpiled JavaScript (and theoretically at least also to C). The compile target doesn’t need to be a pure FP language.
I already told you that we need typeclasses in Go for better abstraction and to get rid of the anti-pattern of reflection which is currently abused in Go for accomplishing some of what one gets with generics.
I don’t know why you got off on this FP tangent.  But neither aim to be Haskell with strict religiosity about pureness.

It's you who mentioned pure functions as a way to have concurrency in functional language lol

Optional pureness annotations are not the same religiosity as strict pureness everywhere that requires using monads to simulate imperative state (aka effects).

But maybe your interest in using Go is something else than concurrency. Like using it as a garbage collected C with more hype.

I do also want well-integrated low-level programming with a GC. You’re correct that is another feature of Go I like. But as @keean explained to you recently in the Concurrency thread (a recapitulation of what I had written many times in the Concurrency thread), we (or at least I) also prefer the goroutines for asynchronous programming instead of Promises.
So concurrency, optional parallelism, typeclass abstraction w/genericity, and low-level with a GC. Also there’s no pointer arithmetic and ranges instead of for loops, so better safety against buffer overruns. The sort of things we expect in a modern semi-managed PL.
That’s not hype. But maybe C-only programmers like yourself are defensive. I bet though you will end up mostly discarding C when we’re done.

Or just doing something 95% like go, but who can express certain things with generics/typeclasses and generate the Go code with the type resolution/monomorphisation ?

Yup that is a big part of the motivation, but not the only feature I (we) hope to add to Go.

Original Author: @NodixBlockchain
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392537461
Original Date: May 28, 2018, 9:10 AM CDT

I'm not specially religious or fanatic about any language, i'm pragmatic, and can drop something when i dont think its suited or when there are better options. I Always like To try new things, new platform and
languages.
Its just for the moment i dont see good replacement for C who can do all of what C can do.
The other language i like is AS3, especially with flex builder i really find on this one adobe got almost everything right.
The main thing that make me frown with lot of new languages is lack of libraries, lack of interface with the OS, or there is always an area or another that will be unstable or not working well on a platform or another. And i grew a bit tired to always need to maintain different kind of code to mannage things on different platform, with all kind of things between the program and the system that can be moving pieces that become hard to maintain over the time.
Or then its bloatware like c#.
With C there are stable mature compilers for every platforms, with direct access to kernel API, and zero gotcha or quirk or anything like that. The only thing is memory mannagement, but it's why i made my runtime on top of it, and to make it easier in general to deal with dynamic data, and i'm fine with it, it can compile for every target that has a C compiler, have good performance, and do everything i want to do.
I dropped C++ for many reason before, and managed language/VM are out of the game for me because too much dependencies for in the end not that much benefits.
For me where i put the frontier between FP and imperative is statfullness or not.
Go is statefull, the concurrent model is based on (shared) states that are channels, so that make it an imperative language to me.
Functional language are stateless, and i dont see well how stateless program can be converted to goroutine and channels efficiently.
But maybe i'm missing something or you have another definition of FP.
Le lun. 28 mai 2018 à 15:44, shelby3<EMAIL_ADDRESS>a écrit :
…
 @NodixBlockchain <https://github.com/NodixBlockchain> wrote:
The thing is i'm trying to understand what you want to achieve in doing a
functional language to transpile it to Go which is not a functional language
Haskell can be transpiled JavaScript (and theoretically at least also to
C). The compile target doesn’t need to be a pure FP language.
I already told you that we need typeclasses in Go for better abstraction
and to get rid of the anti-pattern of reflection which is currently abused
in Go for accomplishing some of what one gets with generics.
I don’t know why you got off on this FP tangent.  But neither aim to be Haskell
and religiosity of pureness.
It's you who mentioned pure functions as a way to have concurrency in
functional language lol
Optional pureness annotations are not the same religiosity as strict
pureness everywhere that requires using monads to simulate imperative state
(aka effects).
But maybe your interest in using Go is something else than concurrency.
Like using it as a garbage collected C with more hype.
I do also want well-integrated low-level programming with a GC. You’re
correct that is another feature of Go I like. But as @keean
<https://github.com/keean> explained to you recently in the Concurrency
thread, we (or at least I) also prefer the goroutines for asynchronous
programming instead of Promises.
So concurrency, optional parallelism, typeclass abstraction w/genericity,
and low-level with a GC. Also there’s no pointer arithmetic and ranges
instead of for loops, so better safety against buffer overruns. The sort
of things we expect in a modern semi-managed PL.
That’s not hype. But maybe C-only programmers like yourself are defensive.
I bet though you will end up mostly discarding C when we’re done.
Or just doing something 95% like go, but who can express certain things
with generics/typeclasses and generate the Go code with the type
resolution/monomorphisation ?
Yup that is a big part of the motivation, but not the only feature I hope
to add to Go.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Ab61IyXykD6uevGSSeFOMw_y7xuevM6Bks5t2_88gaJpZM4OZwjF>
.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392548625
Original Date: May 28, 2018, 9:58 AM CDT

Please do not reply to this post in this thread. Please continue this discussion in the new Functional Programming vs. OOP issue thread #43.

Functional Programming vs. OOP
@NodixBlockchain wrote:

Functional language are stateless,

Incorrect. Imperative state effects are managed in the monad paradigm of pure FP. Please this thread is not for discussing that topic, rather for discussing the designs I have proposed for Zer0.
There’s the Optionally declare functions pure? issue thread #4 for discussing monads and a general Language Discussion thread #1. There’s also a discussion of pure effects systems in the latter portion of the Concurrency issues thread #17.

and i dont see well how stateless program can be converted to goroutine and channels efficiently.

I already told you that this #35 issues thread is not about creating a pure FP language.

But maybe i'm missing something or you have another definition of FP.

I already gave you the superset definition of FP:

Go has first-class, higher-order functions, closures, and GC. Therefore it is a FP language. Just not a pure FP language.

I really grow weary when having discussions with you because it’s as if the relevance of what I write doesn’t sink in for you the first, second, or even sometimes the 3rd or 4th time it is explained. How many more times do I have to explain that pure FP is not all of FP.

For me where i put the frontier between FP and imperative is statfullness or not.

FP is not about avoiding state. That seems to be the stumbling block of your persistent misconceptualization.
FP is about the definition I quoted above.
OOP binds data to methods in objects at instantiation and includes the anti-pattern of virtual inheritance. FP employs dependency injection of functions along with data that function call, which is late binding of interface to data (aka “interface inheritance”). Typeclasses automate (and make implicit) this FP capability.
So the reason you do not comprehend the significance of what we are doing is because you haven’t yet grokked the distinction between FP and OOP. And how typeclasses are simply an automation of FP late binding dependency injection.
The strictly pure (and lazy evaluation) variant of FP is more focused on the mathematical definition of a function and equational reasoning. Monads are employed in order to model stateful effects in the pure FP paradigm.
P.S. I know you are a highly productive programmer once you understand. So I hope we could attain mutual understanding.

Original Author: @NodixBlockchain
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392749379
Original Date: May 29, 2018, 6:53 AM CDT

I grok what you want to do, the thing i have harder time to grok is the interest of it. I will try to take the points one / one for the sake of clarification.
The thing about functionnal programming being stateless and pure is not a matter of religion, it's a matter of what are the practical advantage of using functional programming, that you already talked about in all length in many threads.
I have hard time to grok the point to do functional programming while discarding all the things that make functional programming interesting.
Higher order function and first class function are present in any procedural language. But what make this especially interesting in the context of functional programming is absence of side effect, which allow composability, easy parrallelism etc.
If you remove all the 'religiousity' of functional programming, then you discard all its advantage in the same time. Then can wonder what advantage you really expect out of it.
Closure can be a good thing, but in the context of Go, that can also turn into a can of worm, because closure can be considered as first class function, except they contain hidden dependencies, and thus potential side effects etc that can create trouble with concurency. And they can easily also mess up the heap. After why not having them, they can be useful for certain things.
GC is orthogonal to the programming style.
As for the issue of late binding and dependency injection, i can also totally grok this, except using typeclass for this seem to be a weak form of it.
Dependency injection in the strong form can allow to load a specific implemention of a service or whatever else at runtime based on a config file for example.
It's what you can get with C# + COM with the Object thing that can be assigned any implementation of anything at runtime based on runtime conditions.
It's what i can get with my system too, except i choose a different path, mostly because i had a massive overdose of C++ templates after doing many project with ATL/NPAPI, Direct Show, and other things, so i made my system to have the equivalent of C# / COM dependency injection, but with very slim runtime and portable. But it's really because i grew a huge aversion of C++ type system. Same on a note, i'm not especially a C purist, but all the other language i tried ended up letting me down on a thing or another.
Using typeclass for dependency injection already limit the cases to compile time dependency injection, or then need the dictionary injection thing, but i still wonder the limit of this system in the context of dependency injection / late binding, if it's possible to have a system of plugin loaded dynamically at runtime based on typeclass definition, that can be portable and consistent across different compilers etc.
After i can get the interest of typeclass, in the sense of programming in term of "concepts" that can be applied to many situations and types, especially when it's done at compile time where the compiler have all the informations about the types and how to deal with them and overcome the limitation of OOP. I can completely get the interest of this.
But it seem to me to be still a weaker form of dependency injection / late binding.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-392793826
Original Date: May 29, 2018, 9:19 AM CDT

@NodixBlockchain I have replied to your post where I asked you to continue the discussion.
Please do not reply to this thread again. You continue to take it far offtopic. I will remind you again, that this thread is for discussing the features that will be in a new general purpose PL (proposed to be named Zer0), not for debating whether non-pure FP and typeclasses are useful. Such a detailed tangent belongs in the Functional Programming vs. OOP issues thread #43. Or whether goroutines are useful which is discussed in the Concurrency issues thread #17.
Please stop filling up this thread with offtopic discussion. I appreciate the discussion, but in a thread where it is on topic.
I understand your aim is to try to put a disclaimer on the utility of the PL being proposed in this thread. But such disclaimer should be a summary of detailed discussion from another thread. Complete that tangential discussion first, win the debate, then come back here and put the concise disclaimer. Otherwise this thread would become so filled up with your (what I’m nearly certain are invalid) arguments that we can no longer find the posts which are about the features of the language proposed in this thread.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-395489621
Original Date: Jun 7, 2018, 11:48 AM CDT

I want to share this because it summarizes the reason we are working on a new PL.
I emailed in reply to a highly experienced programmer (who studied physics at UC Berkeley in 1980s) I’ve known since 2008 who is one year younger than me (I will be 53 in June) who will remain anonymous here:

Do you like to help implement typeclasses on Go as a transpiler, and then work on the block chain project?
What programming language do you currently think doesn't suck?

Every time I do javascript programming it is a pleasure, how easy it is to do useful things.
I'm not interested in this "go" stuff.

I saw you have experience in compiler and parser design.
Okay on the programming language front, you seem not to understand that goroutines are much more elegant than Promises for asynchronous programming and concurrency (c.f. Concurrent issues thread #17).
Also JavaScript entirely lacks typing. And OOP is an anti-pattern. What we want is functional programming where we inject interfaces orthogonal to data. This is what typeclasses do (invented on Haskell). But Haskell is a strict pita, because of the purity and the lazy evaluation.
C++ is an utter clusterfuck of complexity and gotchas.
If we take the ease of JavaScript, add typeclasses and compile it to Go, we will have the next mainstream programming language. And we will all be a lot happier.
Here are links to my programming language R&D:
https://github.com/keean/zenscript/issues
I will dig up some specific links for you because there is far too much there for you to attempt to read it all.
What are you interested in programming? Don't you like projects that leverage your puzzles and math abilities? And your ability to spot flaws in designs?

I am fascinated by parsing and compiler design and such. I've toyed with the thought of writing a javascript compiler in javascript itself, compiling javascript to a virtual machine language.

Why not build a more useful programming language while learning, instead of just rebuilding JavaScript?
I suppose you think JavaScript is a good programming language?
For large teams or maintenance over a longer period of time or for ecosystem integration, the entire lack of typing in JavaScript makes it not a suitable programming language.
It is a scripting language. For small toy projects with short half-lives.
For individual programmers who like to be the sole creators and maintainers.
I also like how I can code up something quickly in JavaScript. But I also can't deny the ecosystem is a chaotic mess. Try to find a standard library and you get dozens of conflicting choices on NPM. Many in various stages of abandonment.

I don't like typeclasses or formal declarations and whatnot.

You're conflating. Typeclasses without global canonicity are just dependence injection of H-O-F(unctions). No formal declarations other than declaring the types.

I love how in javascript the thing is always just "var". IT knows what it is. We don't have to do a c-style intricate declaration. Everything is just a var.

That is great flexibility when everything is in only YOUR head.
Not a very effective way to program in open source or teams.
That is for loners who work on stuff that does not matter.

Me too. Go has a better GC than JS.[well apparently Go has no generational GC]
And I want to be able to optionally declared reference counted (RC) references to escape from the GC for long-lived references. So I don't eat up so much performance marking and sweeping things that won't be freed for a long time.

I like JSON, I like the objects, I like how easy it is to declare object and array constants. I just love how easy it is to do things in it quickly.

Yeah but that is not how we produce industrial strength code.
That is for quick toys and experimentation.
We can get some of that easy feel in a statically typed language done well.

I use node.js / npm and such but I have lots and lots of complaints about that.

Yup. Node.js/NPM is a mess.  So away I went. Never to come back to that mess.
Promises are a nightmare (c.f. Concurrent issues thread #17).

I never really got much into promises. I mostly use the callback approach but it's outdated.

So you are about where I was in 2013 or earlier.
You need to catch up. AMD just launched ThreadRipper with 64 hyperthreads on the desktop.
All s/w will be massively concurrent in the future.

You're right about the way I use javascript. It is all just for small one-man solutions that need to perform a single purpose. No real effort to keep variable names consistent, no real organization, I just put all the code in a single file. I can't stand the software that big teams produce anyway. Linux itself has become an unholy monster.

Small things grow faster — Jason Hommel
That is a function of the universal trend to maximum entropy (i.e. trying to maintain the illusion of the existence of time).
I agree. Too much structure kills it. But anyway, we do need to network with others. That is what makes a society.
So we need some balance. JavaScript is a scripting language. We need a team-wise programming language.  Haskell is too formal and abstruse. Etc.. We analysed all the choices in detail, including Java, OCaml, Scala, Clojure, etc..

More and more for the small embedded solutions I'm realizing the giant OS itself isn't worth the hassle. Huge projects themselves I think are going to become obsolete. The future is individuals just slapping together components together to solve a specific problem, and their task is just to provide some glue.

That actually does not work well because too many inconsistencies emerge between versions of modules.
Actually our PL discussion has formulated some optimum design for modules. I realized we should toss aside Haskell's global canonicity for typeclasses. That was a major epiphany. Global canonicity for typeclasses is anti-modular.
I totally agree we need K.I.S.S. and keep the complexity to a minimum.
But JavaScript is too far on the footloose direction.

EDIT: there’s also eventually my cordoned nursery with ARC proposal.
I wrote:

Note ARC can include some amount of compile-time knowledge to annotate shared_ptr (shared/strong ownership references) and weak_ptr (weak non-ownership references) to avoid the poor asymptotic cost of mark-sweep or probing on refcount decrements, to search for circular reference memory leaks.

[…]

My proposal posits to combine a modicum of compile-time knowledge with a cordoned runtime nursery and ARC to obtain nearly the same performance as hand-tuned MM with increase flexibility, less difficult, less abstruse, and a simpler model for data race safety than Rust’s lifetimes + exclusive mutability borrowing. Having compile-time chosen ARC available also accomplishes more deterministic destructors for non-memory resources (e.g. open file handles), which runtime GC-MS (and even GC-MS) can’t do (with compile-time deterministic declaration).

[…]

Disagree because algorithmic flexibility+expression will not be as good as in my Lucid proposal and abstruseness (as I defined it above) will radically increase because for example Rust’s lifetime and borrow checker can’t prove certain things are safe even though they are. We would forever be adding type system features to try to match the flexibility of Lucid[Zer0] which continually increases the abstruseness.
Compile-time proofs are never as flexible as runtime flexibility and they radically increase abstruseness as compile-time checking moves beyond its sweet spot into ridiculousness (of which Rust is borderline ridiculous but appropriate only for a certain specialized class of use cases).

I wrote:

No generational GC to simulate my cordoned nursery concept. I believe my cordoned nursery will be nearly as performant as stack allocation without all the hassle and inflexibility of proving/checking that the lifetimes on the stack are correct (i.e. "use after free") errors. IOW, C++ is stack allocation + reference counting. I propose a superior paradigm, which C++ can't support.

I wrote:

I wrote:

@keean wrote:

This is bad because it causes lots of buffer objects to be created which results in memory fragmentation.

With my idea/proposal for statically typed (RC versus non-RC references) cordoned nursery, I'm thinking creating a new buffer each time wouldn't cause additional fragmentation load due to the math I explained upthread. Also I'm doubting there's a significant difference in cache coherency localization because the bump pointer allocation of the nursery keeps allocations localized for the function activation frame (similar to stack allocation).

The germane point remains that some shared mutable access will be required and thus we need the linear types to prove lockless data race safety. The specific buffer example notwithstanding.
Note @keean is not entirely incorrect about the desire to reuse buffers in some cases and the cost of not doing so if there's no efficient cordoned nursery or if the said buffers leak into the long-lived GC and the MS and fragmentation cost thereof. You're not considering all the cases, although you're also correct that not all cases could reuse the same buffer. But that's a tangential discussion and I'd prefer we don't end up with another 30 posts debating the nuances of that tangent in this thread.

I wrote:

But maybe your interest in using Go is something else than concurrency. Like using it as a garbage collected C with more hype.

I do also want well-integrated low-level programming with a GC. You’re correct that is another feature of Go I like.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-396806490
Original Date: Jun 12, 2018, 11:02 PM CDT

Why not Java?
I am going to recapitulate the reasons we don’t prefer Java (and some of these apply to all JVM targeted languages):

Java and the JVM although very popular with a huge installed base and many available programmers, is not the future. We would be investing in an aging paradigm.

OOP is an anti-pattern (c.f. also, also, also “Edit#2”, also). Even the creator of Java admitted his worst design mistake was classes.
We want typeclasses.

Java is much more verbose than a language designed for concision.
Also my idea is type annotations should be off to the right side, not interleaved with and cluttering the code.

Need the JVM to run the code.
Although there’s some tools to compile to other targets such as Google Web Toolkit (GWT) to target JavaScript, these tools are cumbersome and add more cruft and layers of possible Murphy’s law.

Java (and Scala) have a provably unsound type system.

The lack of unsigned and precisely sized integers. Makes low-level integration with C via JNI cumbersome. We want good low-level programming fully integrated.
I had to do very noisy casting when I was implementing cryptographic functions in Java or Scala.

We want Python indenting. Readability and regularity is a very important priority in open source programming.

This is what happens when you force a Python dev to work in Java, for example:

No HKTs!

Even as of Java 8, closures can’t be made on variables.
Note we probably want to restrict closures to lexical scope.

Java libraries are not only polluted by the anti-pattern legacy of OOP, they're also polluted by the anti-patterns of blocking code and multithreading as a paradigm for concurrency.
We want lightweight Go’s goroutines. Note there is Quasar for Java and possibly CPS transformation.
An example of the unnecessary mess that Scala and Java get in because they don’t have M:N threading: Dead-locks due to exhausting the thread pool.

No operator overloading, no type guards and flow typing.

No named function parameters.

Java requires an IDE. Eclipse felt heavyweight and clunky. IntelliJ is reportedly getting more flaky as they add more and more code to it.

Java when taken together with its libraries is a complex clusterfuck of sorts, that requires master programmers to avoid pathological outcomes.
See also discussion of the garbage collection tuning.

No parametrised modules.

Generics are always boxed. There’s no option for monomorphisation (specialization) or unions which could be unboxed. Although there are unboxed versions of arrays.

No support for optional immutability. Read-only annotations can be cast away.

Massively multi-core is incompatible with the GC in the JVM because….
See also and our discussion down-thread.

Java duplicated the “billion dollar mistake” anti-pattern in that every type can by default be nullable. There’s no non-nullable types. Unfortunately Go reproduced this mistake (c.f. also).

“Java's Optional type violates the functor laws (e.g. opt.map(f).map(g) != opt.map(f andThen g)).”

Original Author: @keean
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-396827886
Original Date: Jun 13, 2018, 1:26 AM CDT

Not to mention the thread and stack handling in the JVM.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-397035862
Original Date: Jun 13, 2018, 1:17 PM CDT

Not to mention the thread and stack handling in the JVM.

I remember you raising that issue and we discussed it but I don’t want to try to search for a link to that discussion.
AFAIR, the issue is basically the point I made that we prefer instead the lightweight dynamically allocated green thread stacks and M:N threading of Go’s goroutines instead of employing 1000s of heavyweight threads with full stacks because of the increased memory overhead of the latter?
Essentially this is the point that Java libraries are also invested with the heavyweight form of parallelism and concurrency.
Although the GC is improving in Java 9 and presumably we could write our own libraries that don’t depend on other Java libraries, this library writing effort would maybe outstrip the work we need to do to make a transpiler to Go with our preferred typeclasses abstraction instead of OOP. So that our libraries will be much better.
IOW it comes back to the conflagration of an aging paradigm and locking us into inertia of that paradigm.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-397781638
Original Date: Jun 15, 2018, 9:55 PM CDT

Why not C++?
C.f. my prior up-thread analysis of the C++ clusterfuck and also the discussion in another thread.
Jon Harrop wrote:

However, C++ is the least safe language of those tested here. Minor mistakes when writing C++ programs can lead to segmentation faults or, worse, errors silently creeping in to the results of computations. This is even true when using the STL and avoiding all pointer arithmetic. As program robustness is always more important than performance, we do not hesitate to recommend any of the other languages over C++.

Copying a discussion from Quora:
I replied:

Tim Mensch replied:

I replied:

Tim Mensch replied:

I replied:

Tim Mensch, Freelance CTO/Software Architect wrote:

What do C++ programmers think of Java?
I think that Java has an enviable ecosystem, along with a module system and standards for “linking” that makes me jealous.
Getting C++ to build cross platform can be…less than fun.
But as a language, I see that Java has about as much boilerplate and verbosity overall (more in some places, less in others), so it doesn't have and substantial code size or complexity advantage over C++.
Java doesn't have true generics. (Everything is boxed.)
Java doesn't support the awesome RAII pattern.
Java doesn't have a great story around building native executables. (Which is annoying to do cross platform in C++, but it's at least possible.)
And Java is slower than C++. Java's standard libraries seem to hemorrhage garbage at a profound rate; even the advanced GC that Java has will block from time to time. And mark-and-sweep GC tends to make your app require about 40% more RAM than manual or reference counted memory allocation.
For me, if I'm going to put up with a language that makes me write a lot of extra boilerplate, I want it to be fast.
So if I need speed, I go to C++. And if I don't need the raw speed, I'd rather use languages that require less boilerplate like TypeScript/Node.js or Go than either C++ or Java.
Though I've used all of these languages and more. Always choose the right tool for the task.

Java has no parametrised modules. RAII is an anti-pattern. And both C++ and Java suck.
#35 (comment)

I was literally shocked to see someone claim that RAII is an anti-pattern. So I decided to Google it.
First page of results had exactly zero people who agreed with you. In fact, the opposite.
C++ Anti-patterns
Pretty much every entry was similar. “RAII is really important.”
So I'm going to say Citation Needed.

Hi Tim. Thanks for the replies.
My comment originates from the context of new design I am proposing wherein we will normally rely on highly efficient young generational GC, yet the programmer can manually declare which objects are reference counted which will be those that are expected to be long-lived and/or which need destructors. This will essentially eliminate all long mark-and-sweep pauses. There’s some issues with this design but I think I worked it out already.
A key implication is that stack allocation becomes a pita and not worthy (in the overall scheme of programmer productivity versus optimum performance, which is genius Eric Raymond’s thesis as cited in the linked GitHub thread):
#35 (comment)
#35 (comment)
#35 (comment)
To do stack allocation safely really requires linear types aka Rust’s lifetimes. Which is very onerous to program and is really suited only for very specialized applications that must have proven safety and maximum performance. The sweet spot for a mainstream PL is my new GC+RC concept, typeclasses (instead of OOP), and Go’s M:N threading model (goroutines).
Also there is some where in those Github discussions some examples of how RAII is really pathological, but I can’t find it right now. RAII is not a holistic paradigm. It’s a very special case solution to only a narrow class of cases. And better to replace with a holistic model of safe allocation instead of C++’s highly complex piece-meal hodgepodge of RAII, stack allocation or all-or-nothing reference counting. The interaction of proper lifetimes with that mess is going to exacerbate the already masochistically, inane complexity of C++.
C.f. the relative discussion of RAII in the following Github posts:
#35 (comment)
#35 (comment)
#35 (comment)
#35 (comment)
#35 (comment)
#35 (comment)
#35 (comment)
Offtopic: I need expert programmers to help me implement the new PL named Zer0 and to help me implement the CRED decentralized ledger. Please see the last section Potential Improvement on the Horizon of my recent blog Scaling, Decentralization, Security of Distributed Ledgers (part 3) for the world-changing significance of the work that needs to be done. Significant funding + vestment is available. Should I contact you? P.S. I am 53 years old, but on Github I am forever 29 years old, lol.

I don't actually care if the RAII is stack implemented. My concern is that you can create something at the start of a function that will deterministically be released when the function exits.

Having something be explicitly reference counted and having classes with destructors would do it.
I don't know that our philosophy of programming is compatible, though. I think that OO is actually useful for some things. I don't remember for certain what you said in that thread, and I can't dig into it further right now, but didn't you say that OO is another anti-pattern?
I've been programming almost as long as you have, but I don't know that I can get excited about creating a new programming language. Maybe if I thought it were perfect? But I'd need OO and Goroutines and functional features all rolled into one. And speed, for good measure. And easy access to a massive ecosystem of libraries (maybe Node.js?).
Which is why I'm liking TypeScript. It doesn't have full Goroutines, in that it's strictly single threaded. But otherwise it's a good match for me.

And what happens when you make a copy of that reference and store it and then the function ends destructing the object that you still hold a pointer to?
RAII is an incomplete model. Instead referencing counting is a more complete model. Yet reference counting is very inefficient for objects which die young. So C++ employs stack allocation for young objects, but that’s a pita to do safely (e.g. again you store a reference to a stack allocated object that persists beyond the life of the stack frame) because then you need Rust’s lifetimes which are very onerous. Instead a young GC is nearly as efficient and no need to do prove the lifetimes for safety.
After you learn typeclasses, I predict you will never go back to OOP again. There’s a very strong reason that Haskell programmers say you will pry them away from their cold dead hands. :)
Rust has typeclasses instead of OOP. You could look at the Rust guide for quick easy to grok intro into them. Rust names them traits, and the dynamic dispatch polymorphism (replacement for virtual methods) are trait objects.
Exactly I am only doing this because I want the perfect PL. And now I know what features it must have. My feature list includes yours except for the OOP. But I think you will realize typeclasses are far superior.
And yes speed. I want also that. Which is why I want Go’s low-level C-like capabilities also. Go’s ecosystem has a growing set of libraries and initial plan is to transpile to Go.
See my reply to your other reply for more of my criticisms of TypeScript, even though I do like TypeScript. Btw, I just remembered that higher-kinded-types are experimental now in TypeScript:
#13 (comment)
microsoft/TypeScript#1213
I can’t write a decentralized ledger and cryptographic code in TypeScript. There’s not even a 64-bit unsigned integer. I can do client-side code in TypeScript but then I am using an entirely different PL on the server-side and then what will I use?
Btw, the decentralized ledger is really a major world changing innovation. Nobody else figured out how to make it decentralized and secure. And that is crucial for replacing Quora, Facebook, Github, Medium, et al with decentralized databases. So that nobody can censor us with that is coming.
Btw, it is now illegal to both shower and wash your plates on the same day in California:
As Leader California Goes, So Follows the Rest of the Country

I replied:

Tim Mensch replied:

I replied:

Tim Mensch replied:

I replied:

Tim Mensch replied:

I replied:

Tim Mensch replied:

I replied:

Tim Mensch replied:

I replied:

Tim Mensch replied:

I replied:

Java has no parametrised modules. RAII is an anti-pattern. And both C++ and Java suck.
#35 (comment)

In reference to C++ and Java suck: No argument there. They just both happen to be at relative sweet spots of ecosystems and power.
The best language design in the world is useless if you need to reinvent all of the wheels.
Your link is quite a rabbit hole. I'd never heard of ZenScript, and I really don't get the point. Looks like CoffeeScript? Throw in braces and you get an inferior TypeScript. Maybe the Readme doesn't explain the point. But: Significant white space? That is an anti-pattern.
I read enough of what you wrote to see that you've been thinking a lot about language design. I find TypeScript to be at the sweet spot among current popular languages. Full type safety where you need it, plus the ability to arbitrarily extend types in a type safe manner. I have one TypeScript app with 20k lines of code that doesn't need to use casting more than once or twice, and I could probably eliminate those as well.
For me it comes down to pragmatism. TypeScript is good enough for some things. C++ is good enough for others. Go is good enough for a few limited things (that don't need UIs). Java is… Well, I can't say that I ever used Java for anything but writing Android apps, and then, only because I had to. The next time I have a choice I'll pick up Kotlin.
I've always said that I have a love/hate relationship with C++. But I know C++. I can make it work, even if it's an abusive relationship. And it creates code that's fast. I've considered learning Rust, but my recent consulting and personal projects haven't required speed, so I use TypeScript, and I work around its quirks. Haven't actually used C++ for much in years, in fact.

Hi Tim. Again thanks for your replies.
I was so curt before because I didn’t know if you wanted to discuss and because I was probably sleepless and rushing (as seems to be always the case lately).
I’ve been discussing with @keean about PL design since I met him on the Rust discussion forum in 2015. I’ve been wanting a better PL since 2009. I first went off on search and learning phase through HaXe, Scala, Haskell, TypeScript, Go, OCaml, etc.. Then I homed in what I really want from a mainstream, sweet spot PL that will be well suited to full stack (client or server). So I have named that Zer0 (.0 file extension) and want to (as a first iteration experiment) complete a transpiler to Go, to initially add polymorphism (i.e. abstraction) to Go in the form of typeclasses instead of OOP. Typeclasses are far superior to the anti-pattern of OOP. Want them without all the abstruseness of Haskell. Rust has typeclasses instead of OOP. The original name was ZenScript but I wasn’t satisfied with that name, plus that’s keean’s repository name. I will make my own repository.
Problem with C++ is that abstraction is not declarative. It is Turing-complete via the implicit resolution of templates. Many things collide at compile-time to produce what can be “effects at a distance” and the dreaded Heisenbug, lol. Readability, regularity, and declarative abstraction are the keys to industrial strength open source where others can comprehend your code instead of blowing it up if they change one character in the source code and all sorts of complex unseen things change. C++ violates the Principle of Least Power. It is powerful enough to do nearly anything you want to do, but then nobody else can understand or touch your code.
As you know most performance critical paths are concentrated in a very small portion of the code, so we really do not need to be coding with a maximally powerful PL for the bulk of the code.
TypeScript is indeed quite a improvement over JavaScript (and originally I was contemplating targeting it as a compile target for adding typeclasses), but the problem is it is still the anti-pattern of OOP, its abstractions are leaky, and it is too much married to the horrific JavaScript clusterfuck ecosystem.
What we (I) have planned for Zer0 will be far superior than TypeScript and meet the demand for a truly ideal mainstream PL.
If you need integration into the JavaScript ecosystem, then TypeScript will be preferred. But I want to kill/replace the JavaScript ecosystem. I want canonical libraries that have industrial strength maintenance, investment, and perfection. Not a 300,000+ library clusterfuck of partial-stages of abandonment.
Go has the correct attitude. Focus on simplicity, regularity, and quality. It’s just really unfortunate that Go’s abstraction is so rudimentary. But they (Pike said) intended that others would build transpilers on top of Go.
Well agreed your point is correct that the inertia hurdle involved with creating a new ecosystem is tremendous. But if no one attempts to move the state-of-the-art forward, then we programmers are stuck with the same poor options.
Who wrote about significant whitespace? Vertical whitespace is indeed an anti-pattern. If I wrote that, then what I meant is horizontal whitespace between the code and the annotations. I don’t like having the type annotations clutter the expression of the algorithm. So I proposed to put them off to the right side. We have wide-screen monitors and rarely use them on coding (some programmers turn them 90 degrees because of that).
TypeScript can’t integrate well with low-level code that needs sized integers for example. No operator overloading in TypeScript. No higher-kinded types. No typeclasses for superior dependency injection abstraction. No optional immutability. No M:N threading. The Promise model is highly inferior and less elegant to both read and code. See our Concurrency thread for an explanation of why.
Btw, I was discussing PL design with the creator of Kotlin as he was creating it. I have used Scala for messing around with Android app programming. Somewhat superior to Java.
I want one PL for all my programming.

Do typeclasses allow you to have the equivalent of implementations in base classes? And default behavior that can be overridden, either in a virtual manner or only when you know your object at compile time?
Because I create a lot of GUI code. Complex stuff. And I don't want to have to copy and paste tons of code into every widget to bring in the common functionality.
So I think what I really want is real OO. But I don't know what “typeclasses” means to you.
By the way: Jerry Brown is with a “j” (referring to your blog), and at least front loading washers (which are better for the clothes anyway) only use 13 gallons of water or less.
And your characterization of the law is wrong. It's 55 gallons per person. California's Water Law: 55 Gallons Per Person Per Day

Typeclasses can do that. And better yet, they don’t bind the methods dictionary to the object at object instantiation. Instead each function declaration can request different interfaces on the objects which are inputs of the said function. So the interfaces and the objects are orthogonal. This is late binding and dependency injection which is much more flexible than OOP. Essentially typeclasses break free from the unnatural notion that something is only a subclass of one superclass forever. It allows programmers to add new interfaces to existing classes without having to construct a dummy delegating class (and all that plumbing which becomes unwieldy when layered). Typically it can all be automatically monomorphised at compile-time by the compiler for maximum performance.
Yes in Haskell there are existentials and they are named trait objects in Rust, that enable you to have virtual interfaces that select the right implementation dynamically depending which object data type is present at run-time.
Believe me, typeclasses have everything good that want from OO but better.
As for implementation mixins, we can achieve that with a combination of parametrised modules and typeclass implementation inheritance.
It really isn’t that complicated. Typeclasses implicitly resolve as well eliminating most of the boilerplate you would otherwise incur with such flexibility.
Note I have proposed to remove the global canonicity which is anti-modular. So I have improvement over what is currently in Haskell and Rust.
We would really need to dig into examples to make this all more clear.
Btw, I am also a full stack guy (but not DevOps) but most of history was on the GUI side. I started with a Mac in 1984. Then an Atari ST and wrote one of the world’s first fully functional WYSIWYG word processor with desktop publishing features such as multi-columns. I then worked on what is now Corel Painter (not Paint) the natural media simulation painting program. And I helped maintain the porting layer that emulated the Mac GUI API on Windows.
——-
Tim, although I know you didn’t intend any harm, please kindly don’t mistakenly attribute typos and lapses of accuracy to me which I didn’t make. Readers can clearly see that what you refer to was quoted from Martin Armstrong’s blog. I was adding commentary on my blog. I quoted him verbatim.
Well I responded to your “per person” reaction, because you seem to have misconstrued the entire point of my blog post. Even with a 4 person home, 220 gallons per day isn’t going to protect you from a broken water pipe and a $10,000 fine (certainly to increase as the bankruptcy of California worsens), especially when you’re on vacation. But I have an even more important point to make. Please take another look as I have expounded since apparently my point was too subtle to be as obvious as it is to me:
As Leader California Goes, So Follows the Rest of the Country
CALPERS is bankrupt because of the ZIRP of the Fed since the subprime economic correction. California will end up having to impose an exit tax and confiscate all the wealth. If you’re in California, leave asap. This is going to get very, very ugly over the next decade (and extend into the economic abyss perhaps for decades).

OK, I think I'm understanding typeclasses a bit. And your background is very impressive. Word processors are quite challenging from a UI perspective. I did game development on the Atari ST, so I remember it well.
The first thing that jumps out at me based on your description of typeclasses, though, is that it seems impossible to support information hiding if anyone can add a function that accesses a data member. Does the equivalent of public/protected/private still exist?
Also: You mentioned Haskell. You're not planning on Zer0 being pure-functional or immutable, are you?

You’re name seemed vaguely familiar to me so maybe I remember reading your name in an Atari ST magazine.
Encapsulation is to be achieved separately with modules which only export what is declared exported.
Not planning to force PFP or immutability as the default. Interested to explore optional annotations when the programmer wants those invariants. Not sure if that is useful though.
If you don’t like (or believe) that decentralized ledgers are going to completely disrupt the ability to tax and spend and will destroy big government, then presumably you would not be interested to work on decentralized ledgers. I would understand how politics can destroy the best opportunities in life. Politics is a destroyer of everything.
Not to try to change your mind, but just so you know. I don’t want to hate anyone.  I mention these issues because it is how I can detect if someone would be motivated to work with me on decentralized ledgers. And I’m sad that my birth country has devolved into hate (on all sides). I’m not a Trump supporter. Actually I’m a Bitcoin supporter because Ideal Money is sovereign and can render impotent (or limited) the totalitarian power of politics. I recently explained this:
Is POW systematically doomed to get a huge monster in its midst?
https://www.quora.com/How-different-would-the-world-look-if-the-average-IQ-was-140-instead-of-100/answer/Josh-Hill-45/comment/64920333
https://steemit.com/philosophy/@anonymint/geographical-cultural-ethos-science-is-dead-part-2
https://www.google.com/search?q=site%3Aarmstrongeconomics.com+what+socialism+destroyed
It’s not about I don’t want to take care of people. But the unfortunate reality is the collectivized care becomes megadeath every time throughout history. Much better we have loving extended families that care of each other. But big government destroyed clans, because we no longer need to rely on our families as a backstop. Yet this defeat of clannism was actually very important for it was how Westerners were able to prevent defection and move forward to dominate the Agricultural and Industrial revolutions.  This is a very complex topic and I agree we are unlikely to understand each other if the links I provided didn’t already register with you. We all have our cognitive biases based on our culturalisation as we were going through life. Colorado is prime area for liberal and progressive culture.

The language is catching my interest. I don't know that I am the best person to work on a programming language, but I would be interested in keeping track of its progress. Does it have a web site or Github repo that I could follow?
On politics: I wanted to read more of the links, but the Quora app only takes me to the Bitcoin link, no matter which I click on. I personally think POW is a doomed approach (in part because it's such a colossal waste of energy!), but in part because it tends to limit transaction speed globally.
But I am not a cryptocurrency expert. So what I said may actually be wrong. But I'm mostly repeating what I've heard smart people say. Turns out that there are a lot of smart blockchain people in the Boulder startup community. Did you know there's also a blockchain caucus in the US House, and that our representative started it? Jared Polis.
And yes, I'm in Colorado. And I'm here because of the politics. I was born to Republican parents, and initially registered as a Republican, but quickly discovered that I didn't really share their values. So I spent a lot of years registered independent.
I even briefly dated a diehard libertarian, and was exposed to that community. I was tempted by the siren's call, but ultimately decided that it was all an illusion. Yes, the entire philosophy. It was self-perpetuating, though because it made people with money feel justified in pushing for reduced government and taxes.
It's demonstrably untrue that letting the government care for people inevitably causes problems. Look at the British NHS. Even their conservative parties support it. Or Sweden. [1] In fact, if you look at the article I just linked, you'll see that the US has the highest cost and some of the worst outcomes.
In the US, poor care by the government seems like a self-fulfilling prophecy, though: The Republicans have spent much of the last 50 years (maybe longer?) claiming that the government is incompetent, and when they gain power, they make their claims into reality.
Republicans just removed the critical mandate from the ACA, meaning that insurance prices are guaranteed to accelerate. They previously refused to fund the risk pool that should have been keeping rates lower. So they screw it up twice over, and then blame the ACA for being broken…
And no, I don't want to have the ability to avoid paying taxes. There are things that are broken. Granted. But every other system that's been tried is worse. And if we can't fund social programs, it's been proven that the rich won't put in their fair share to support the poor.
Just look at the people of every red state for proof.
Edit to say: I did warn you that we would probably not have a productive discussion about politics.
Footnotes
[1] Healthcare in Sweden - Wikipedia

Have not launched the repo yet for Zer0 but I will soon. I will try to remember ping you via your website contact email or contact form.
I’m delighted I was able to get some interest on the PL. That means potentially it’s a worthwhile experiment to try.
I noticed that problem and fixed the links on Quora. It’s a bug in Quora. Millennial programmers (no attention to detail). :sigh:
Jared Polis that names sounds familiar. Perhaps I emailed him recently about ICOs and the SEC.
Frankly I am the penultimate Bitcoin expert. The entire Bitcoin Forum - Index Development and Technical subforum going silent because of what I wrote in that post I linked for you. They are shocked because of what I proved is true. But the relevance of that linked post is probably over your head at this time because you’re not deep enough into it to understand the intricate points.
If you send the link to that post to any true Bitcoin expert and if they read it they are going to be shocked. Then if they will dig into my history and realize who I am they will come to realize I am cardinal to all other so called Bitcoin “experts”. This results from 5+ years of intense R&D and study on my part. And a very divergent IQ that is able to visualize patterns of the intersection of technology, game theory, and political-economics that the other so called “experts” don’t.
Peter Thiel is correct that Bitcoin is the next digital gold world reserve currency. I show intricately in my Latest posts of: anunymint  posts how that is undeniable.
Ah I see you’re an idealist. Sorry to inform that the examples you cited are only short-term debt-bubble fueled and they are actually about to collapse into megadeath anew which has always been the recurrent pattern since antiquity.
I wrote a blog recently and the UK is near to precipice and the NHS is one of the reasons:
Countries Vulnerable to Economic Devastation Soon
Btw, in socialist Wiemar Republic which morphed into the Nazis, they ended up euthanizing the weak, the old, the crippled, etc.. because they ran out of resources to pay for the universal health care.
When you idolize those other nations you specifically ignore the wisdom in the Bible about that very specific statement you made (yes it was predicted you would write that):
Bible Gateway passage: 1 Samuel 8 - New International Version
And the Bible explains what happens every time since antiquity when the people idolize a King to rule over them as you have:
Bible Gateway passage: 1 Samuel 15 - New International Version
But you think democracy is not a King. That is because you do not understand the game theory of political-economics which is always a power-vacuum:
Some Iron Laws of Political Economics
We will just have to agree to disagree on this one because you will not change your views until there is a boot on your throat and by then it will be much too late. It is already too late. Can’t stop what is set in motion already politically and ideologically in the West. Unfortunately.
Regarding health care, the problem in the USA is healthcare is a controlled monopoly. That is why the costs are going crazy. We need something like Singapore’s healthcare system. That is the poor get only rudimentary care. And costs are mandated for them. They get rationing. Example was Charity Hospital in New Orleans where I was born. And then for everyone else it is a free market but without a monopoly preventing competition driving prices skyhigh. Singapore’s system is not exactly that, but it is perhaps the closest of any in the developed world.
I agree the Republicans (and Democrats) create that monopoly healthcare system for wealthy who own our country and parasite extracting all the wealth from the middle class leaving them only saddled with debt.
The rich never pay your taxes. Taxes always are paid only by the middle class. The rich own the politicians ALWAYS. No exceptions EVER. Anyone who believes otherwise is living in some idealistic fantasy that never exists.
Unfairness of tax cuts for the rich explained in beer
Your intentions are noble except the problem is that collective is always owned by the rich. It can’t be any other way, because of the inviolable game theory of the political-economics of democracy. Thus all you are accomplishing by pandering to red and blue colors and bickering with your fellow man over politics, is to give everything to the rich, which is exactly what you were trying to eliminate.  But when I explain this, people do not seem to grok it, because they do not want to believe that democracy is the same as dictatorship wrapped in a chocolate covered wrapper. Or like putting lipstick on a pig, it still can’t fly or win a beauty contest.
Tim, I wanted to catch you attention one more time and let you know I had added significantly to my prior reply. You may want to re-read it because I am not sure if I was still editing it when you read it, if you already read it.
Also I was thinking more about the issue of taxation. And I’m afraid what it really distills down to is that people think that corporations make a huge profits selling us products and using us as employees. Thus people think that making corporations pay their fair share is the way to return back to society that excess “ill-gotten” profit the corporation obtained more or less by being a parasite middle man extracting monopolistic rents our society often buying off the regulators and such. Or that corporations must be good partners of society.
So more succinctly: REDISTRIBUTE WEALTH.
Problem is that the rich are wise to this scheme that the masses want to steal their wealth. Government is actually a power-vacuum always for sale to the highest bidder. Has always been that way since antiquity and will always be that way. So when the masses push for higher taxes on the rich, the rich will always buy loopholes and the middle class is the only sector that ends up paying the taxes. Has always been that way and will always be that way.
 The rich run away with all the profits and leave us with a bankrupt government and society that collapses into the economic abyss.  The rich buy up all the assets for pennies after we burned everything to the ground. Then the process repeats anew.
That is insane. I am not going to participate in insanity.

First, I don't accept that taxes are “stealing.” Or even “wealth redistribution.” Taxes are what we pay for services that we all need.
Second, a 90+% tax bracket[1], plus effective rates that hit 60%, says that the rich didn't always get their way. The right wing has been pushing this “taxes are punishment” mind virus since before either of us were born. I learned a lot of this context from a conservative professor teaching an upper division US History, 1943-present class at UC Berkeley. He was a visiting professor. I was surprised that he was conservative, but that's why I remember it.
Third, we're just about to the point where the pendulum may actually swing back far enough that the rich will start to pay their fair share. But even if they don't, that doesn't mean that we shouldn't still want services to be paid for.
Just because there are people who can succeed at cheating the system shouldn't be a reason to destroy the system. I'm actually much more of a realist than an idealist. I just want to keep pushing things to the left, where there's more chance that we'll get Medicare For All and a living wage for everyone with a job. I even think that we need to move toward Universal Basic Income.
And I want both of those things for selfish reasons. My biggest expense right now is health care. My continued employment relies on a continuing healthy economy. And I know what happens when people lose jobs en masses (automation really is coming), and they lose all hope of feeding their family. I can't afford to be Peter Thiel and run off in my private plane to my hideaway in New Zealand while the world tears itself apart.
You and I both with with complex systems. You know how unstable complex systems can be. They need constant inputs to keep them stable, unless they're artificial. The Democrats are far from perfect, but at least they're trying to keep the system running. The Republicans explicitly want to tear it down.
Finally, from Kant[2] we get the idea that the moral way to behave is to do what, if everyone else did it, would most benefit society. It's not stupid to pay our fair share of taxes; from a Kantian point of view it's immoral to try to cheat on taxes (which is what any system involving Bitcoin to avoid taxes would be). And just because there are rich people out corporations who are immoral doesn't mean that I should lower my standards to match. Instead I would push to have them pay their fair share.
Footnotes
[1] Income tax rates were 90 percent under Eisenhower, Sanders says
[2] Immanuel Kant - Wikipedia

I’m fully aware of the historic 90% tax and that for the centuries of highest GDP growth of our nation, nobody paid any income tax. Income tax was foisted as our nation descended in socialism with FDR and then WW2 which was FDR’s (along with Prescott Bush et al) fabricated war. He actually created Pearl Harbor on purpose. I have fully documented this and other such false flag attacks:
In T̶h̶e̶f̶t̶ ̶a̶n̶d̶ ̶M̶a̶s̶s̶a̶c̶r̶e̶s̶ᵀʳᵃⁿˢᵖᵃʳᵉⁿᶜʸ We Trust
“You can’t handle the truth!”
Of course you want to believe in a fantasy so you will of course not study the facts in sufficient detail you will dismiss the facts as kook or conspiracy theorist. Because the wealthy have already indoctrinated you with a certain mindset to prevent you from ever seeking the truth.
That is because they never paid the 90% tax. It was only paid by the suckers who were honest and destroyed because of being honest.
The banksters always use you gullible masses to destroy the honest wealthy so that they end up with all of the wealth. That is the definition of a power-vacuum.
You’re participating in insanity and you do not even realize it because they have so indoctrinated your thinking with irrationality.
Taxes are stealing. You destroy the honest wealthy, allow the criminal wealthy to take everything, and they leave you masses in the end with debt collapse and megadeath.
As I said, you will wake up one day with a boot on your throat as has been the case every single time repeating all throughout human history. But you live in a bubble.
But I warn you, the bubble is collapsing. It will not be more than 1 or 2 decades at most before that boot is on your throat. And maybe as soon as 2024.
Observe what happens to the USA as the politics turns very very violent.
You are going to get what you deserve. Sorry to say.
And yeah we could not work together. But I will inform you if progress is made on the programming language.
I wish the best for you. I hope you study. And actually study. Which means never believe what you read on Wikipedia.
To study history you need to look back for 1000 years not just cherry pick samples from less than 100 years ago. The Shannon-Nyquist Sampling theorem informs you that you will have aliasing error when not sampling both above double and below half of the wavelength of the cycle of boom and bust in society-at-large. I recommend you read 6 years of archives of Martin Armstrong’s blog. And certainly do not trust the lies about him on Wikipedia which can not be corrected because Wikipedia is a gatekeeper controlled by the criminal wealthy.
The pendulum you’re hoping for will only be debt collapse, war, and megadeath. The problem is that idealists are self-important. They think the masses have power. The masses have no power and never will. The criminal wealthy always win, because they convince the masses to be criminals. IOW, they convince the masses to redistribute wealth, which steals from the honest wealthy, while the dishonest wealthy own the government and steal everything leaving the masses only with debt collapse. This will always be the case and will never change. Why do you think I am working on decentralized ledgers that no entity can control?
The honest wealthy build the economy but you masses destroy them. The dishonest wealthy don’t build the economy and never pay your silly redistribution taxes (which are not used to pay for services but rather stolen by the criminal wealthy in the government whilst they pile on debt to pay for all the services). They instead feed you debt until the debt load is so high that everything collapses into the abyss in a Minsky Moment. That Minsky Moment is approaching in Europe within the next 2 years perhaps. And that will drive the US dollar skyhigh, which will further exacerbate the trade deficit. The interest rates will go skyhigh which will bankrupt everyone in the USA whilst trade wars will explode due to the high dollar. The high dollar will collapse the global economy because of the $10 trillion short-dollar position of the USD-denominated bonds abroad. The vultures are circling and time is nigh, the Grim Reaper awaits his time to teach you a lesson in economics and reality.

P.S. If you want affordable healthcare, the move to Singapore or even China. GTFO of the USA. And for example working on decentralized ledgers could have been your ticket out, because I don’t care where you work from. But the problem is I need people who work with me to understand reality. Because I am fighting for the future of humanity with my work on decentralized ledgers. Unfortunately so many good engineers are asleep at the wheel and unable to assist me even though I can find plenty of Bitcoin for their compensation.

And as I predicted, it wasn't fruitful for us to discuss politics. ;) We clearly believe in incompatible axioms about how the universe (or humanity) functions. There is no way that I've discovered to reconcile between the two. I've tried going down that path, and it's frustrating. Axioms are, after all, axiomatic.
I don't believe your conclusions, either, or at least not the path that history might take to the destruction of civilization.
I am interested in the results of your language, though. Please link me when you have a Github repo.

Yes we both knew that going in. At least we do not become abusive to each other. We’re civilized in our debate.
Note I explicitly stated that the pattern of destruction and rejuvenation repeats throughout recorded history. So I did not claim permanent destruction. In fact, Asia is rising while the West collapses into the abyss. The West will decline to a third world kleptocracy to reach rock bottom before any rejuvenation can occur in the distant future. For the rest of our lives, the West will be declining into the abyss. So this is very important for us.

Frankly there’s an objectivity available to falsify your axioms but you’re apparently unwilling to go there.
As I alluded, Armstrong has expended $100 million to collect all the historic data since antiquity and has correlated it all with a supercomputer (because he was $3 trillion hedge fund manager, largest ever before he was framed by the banksters for their bribe of Boris Yeltsin…long story…). And that database seems to show that your historian teacher is entirely incorrect and myopic. He lacked the data and the computer correlation. In short, both you and he cherry picked data to fit your confirmation bias. That’s not science.
The problem for you is you’re apparently X gen like me, so you would have to completely discard decades of your life as being utterly philosophically incorrect. That is nearly impossible for a human to do at our age. We’re long past our influenceable youth when that history professor (in my opinion) corrupted your perspective of reality. This is why State schools which are controlled by the criminal wealthy are an abomination. They have totally indoctrinated the Millennials:
If you want the country to be less polarized then stop writing, talking, and thinking about…
You fundamentally want to believe in a fair and just world. But nature isn’t like that. That is why we need decentralized ledgers in order to remove the capability for the power-vacuum to exist at the center.
For me it’s very sad, because I want to help people. But I can’t help people that can’t do science. People will believe whatever they want to believe and the criminal wealthy control the mass media, the Internet, the schools, the politicians, and even now the Pope. The blue versus red paradigm has been the paradigm for fooling the tribal instincts of the masses since antiquity. They even got you to believe that the Republicans and Democrats are distinct. They are both heads of the same criminal wealthy behind the curtain.

http://trilema.com/2018/the-common-psychosis/

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-399012397
Original Date: Jun 21, 2018, 3:01 AM CDT

Why I don’t want to start coding a major Internet service with the wrong PL:
https://www.quora.com/Why-did-Quora-choose-Python-for-its-development-What-technological-challenges-did-the-founders-face-before-they-decided-to-go-with-Python-rather-than-PHP/answer/Adam-DAngelo

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-408580064
Original Date: Jul 27, 2018, 10:46 PM CDT

Eric S. Raymond writes about Defect Attractors, which is basically equivalent to my use of the term ‘anti-pattern’ up-thread (use Ctrl+F to find all the instances after using it to search for “Load More” to load all the posts of the thread manually because Github sucks). He definitely mentions class inheritance (aka OOP) which we have extensively ridiculed.
I note Eric forgot to the mention the “billion dollar mistake” (which I mentioned upthread).

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-410160809
Original Date: Aug 3, 2018, 1:44 AM CDT

Rust’s lifetimes versus Ada’s new static memory allocation research versus my new idea for a much simpler and more powerful form of static memory allocation:
#41 (comment)

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-410458444
Original Date: Aug 4, 2018, 10:50 AM CDT

I wrote on Quora:

I agree that above the decentralized foundational protocols on the Internet, there’s a lot of design-by-committee failure layered on top that needs to go the way of the Dodo bird. JavaScript and CSS are two prime examples of clusterfucks.
I think you may end up incorrect about the importance of decentralized ledgers, although many of your criticisms of extant blockchain designs I agree with:
Scaling, Decentralization, Security of Distributed Ledgers

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-416021733
Original Date: Aug 26, 2018, 3:08 AM CDT

Why not Haskell?
Up-thread we had:
Python Slow; Not Strongly Typed
JavaScript/TypeScript No Shared Memory Nor Tight Low-level Integration (c.f. also)
Scala and Ceylon
Kotlin (c.f. also)
The Nim programming language
Deeper look at OCaml
Discussion of Go (c.f. also and also)
Why not Clojure (or any LISP)?
Why not Java?
Why not C++?
Why not Swift? (c.f. also, also, also, also, also, and also)1
Since the above information on Scala is lacking (our thoughts being spread out in our discussions), the main reason we don’t like Scala is OOP is an anti-pattern (c.f. also, also, also “Edit#2”, also), so please don’t offer that paradigm, it isn’t highly optimized for implicit typeclasses, and the type system (even for Scala 3) doesn’t have principal types (i.e. type inference is undecidable/ambiguous). Scala 2 was lacking anonymous, non-disjoint unions. Also AFAIK it doesn’t have native (e.g. automatically cooperative preemption) M:N threading akin to goroutines. Perhaps there’s some way to simulate goroutines in Scala though. Also some of the weakness of the Java Virtual Machine (JVM) carry over to Scala, such as the lack of native unsigned integer types and some of the other weakness that are enumerated in the Why not Java?. Scala.js has an advantage over GopherJS (Go’s JavaScript compiler). Author of Scala.js explained what is required to port it to Scala 3.
See also Rex Kerr’s synopsis of modern mainstream programming language choices. Rex notes that many of these languages have indirect (e.g. mark-and-sweep) garbage collection (GC). Whereas, for Zer0 we’re contemplating “direct” (e.g. reference counting possibly with cycle detection probes aided in efficiency by...) coupled with a very novel near zero-cost, zero-tsuris (unlike Rust’s lifetimes woes) young generational stack and bump pointer indirect GC via my novel Actors epiphany paradigm. Eric S. Raymond thinks the future mainstream general purpose systems and large applications programming language to replace C/C++ must have some form of low-tsuris GC and have very low in-bound learning costs for programmers coming from C/Java/C++.
Rex Kerr argues that Haskell is the best at abstraction. Tikhon Jelvis supports that point and emphasizes that Haskell is more declarative.  He breaks this down into a powerful principled type system, purity (also referential transparency), non-strictness (~lazy evalution), and implicitly he is depending on functional programming.
Well I think perhaps we can via library code achieve declarative function programming with an eager evaluation Zer0 along with a principled type system including improved and more modular typeclasses2. Because otherwise lazy evaluation contributes to issues with performance and reasoning about time, space, and latency.
Purity is to enable equational reasoning, so that refactoring doesn’t cause incidental referentially opaque Heisenbug dominoes effects to semantics. The idealism is to segregate all the side-effects into category theoretic abstractions (e.g. monads) so as to enable mashing effects together in an equational reasoning. However, after looking at this in some detail, I have my serious doubts about whether it is worth the abstruseness and complexity. For example, I think it makes very little sense to use highly abstruse declarative tricks which end up being more difficult to read and understand than the imperative version would be. Rather my current thinking is that side-effects are always going to be an imperfect mess (e.g. causing the clusterfuck of monadic composition) so its best to (in addition to using immutability and not creating side-effects where not necessary also) just eliminate dependencies on the order of side-effects to the greatest extent possible. Write programs that to the greatest extent possible leverage semantics and paradigms which are agnostic to the order of side-effects. One such paradigm is the Actor model of computation which is agnostic to the delivery and order of deliver of messages. Note unrelated to purity, I do think all programming languages can benefit from monad abstractions to for example reduce boilerplate for short-circuiting (such as for nullable results).
Jon Harrop commented:

I find it more interesting that Hoare's original quicksort algorithm was bastardized into this out-of-place list-based form apparently so that uselessly inefficient implementations could be written "elegantly" in Haskell.  If you try to write a competitively-performant generic quicksort in Haskell, you'll find it is actually impossible due to long-standing bugs in GHC's garbage collector. Hailing quicksort as a good example for Haskell beggars belief, IMHO.

I wrote on Quora:

Not everything under the hood in Haskell is beautiful. Global coherence of typeclass instances is anti-modular.  Modeling the imperative, unbounded non-deterministic world with a PL designed to model math is like shaving with a stapler gun retrofitted with a razor effects system.

I wrote about the Haskell’s community preference for extremist brevity and equational reasoning by obscuring many implicit layers of abstraction:

For example, Haskell programmers favor brevity and mathematical expression with trade-offs such as hidden (2nd, 3rd, and 4th order) details in the form of implicit typing (which the mathematically minded model in their mind without reading them explicitly in the code), which drastically reduces the demographics of programmers who can read the code and participate. Some snobbishly claim this is a good filter to keep the less intelligent programmers away. Haskell has other trade-offs (necessarily to enable the mathematical modelling) which we’ve discussed else where are outside the scope of this concise summary, including but not limited to (and my descriptions may not be entirely accurate given my limited Haskell fluency) the debugging non-determinism tsuris of lazy evaluation (although the requirement for lazy evaluation is disputed), the bottom type populating all types, a total ordering (or algebra) on implementation of each data type for each typeclass interface, a total ordering on the sequential (monadic) threading of I/O processing in the code (requiring unsafe code to fully accommodate the non-determinism of I/O), etc..

I wrote:

The complexity of their paradigm model(s) makes the code unnatural for most programmers to read, e.g. Haskell inflexibly enforces pure functions globally and effects via category theory (e.g. monads) trading off flexibility of free-form imperative style […] and OCaml has too many paradigms similar to Scala being a jack of all trades but perhaps not focused enough to be a master at some critical mass inducing paradigm or target use case (and none of them sufficiently integrate low and high-level coding in the same language to match C++ in speed tests whereas Go performs better). Eric has reiterated numerous times that readability is a high priority of PL design, and one of the reasons he raves about Python. Whereas, the abstruseness filtering out all but the most gifted programmers is argued to be a desirable feature by some snobbish and myopic Haskell zealots.

I wrote:

EDIT#3: Haskell (and Purescript) forces pure functions every where. (There's also the lazy evaluation every where in Haskell but afair not Purescript). All imperative code has to be shoehorned into the IO monad (in the functions are not pure w.r.t. the World) or other monad such as the State monad. Monads don't generally compose (although Applicatives do). Monads are more powerful because the bind commits to the type of container versus apply for Applicatives. When people in the Haskell world speak of "effects" they're referring to capturing the impurity of imperative code in the state of the Monad, i.e. imperative code is about state and the context for the state is the monad. Monads may help us reason about impure effects within the mathematical conceptualization of category theory. Which in turns aids some functional/modular reuse and composition (e.g. Applicatives can lift any function on value types to a function on collections of that value type). However, some algorithms which are straightforward with imperative code, may require significant modeling with Monad transformers to achieve in the monadic model. As I understand it, this attempt to categorize (as in category theory) all variants of imperative structure, is a pita. I'm not sure if it is worth it. Many programmers are comfortable with the flexibility of unstructured imperative coding. For the mathematically minded, who want to model every aspect of their program with category theory, it may afford some significant productivity benefits. But I'm not convinced yet that is the correct direction for a mainstream programming language. However, I'm not against having support for category theory based programming paradigms in the language. I'm just not convinced it should be forced as a non-optional paradigm. Note this summary may be incorrect, as I'm not a Haskell expert. I have minimal understanding of Haskell, category theory, and monads. We had discussed monads in a separate thread.

I wrote:

At the moment I am favouring error handling by exceptions using algebraic effects.

I’ve soured on (even free) monads for modeling effects. Lots of tsuris of trying to arrange all ducks into a serial line.

I do agree with avoiding the mess that Michael O. Church explained in his Quora answer:

For a comparison, when I was at Google, I maintained a piece of C++ code that had a 2000-line method. It was a pile of stateful actions that had all been thrown together and forgotten about, many years ago. There was no hope of anyone holding that whole mess in his head at one time. There's a certain sloppiness that emerges in corporate C++ and Java codebases, not necessarily because any of the individual programmers are bad, but just because stateful actions don't compose well and, when people use state without thinking about it and there are multiple programmers working on the code, all with different motivations and many just wanting to get back to doing something other than fixing some random bug, entropy can accumulate quickly. When your default atom is a stateful action rather than a function, large codebases turn into bogs.

I agree with what Jon Harrop opined in his Quora answer:

“Don’t be puritanical about purity”
[…]
Eschewing side effects can be great: it can make it much easier to reason about your code. However, it also comes with a potentially huge performance cost (purely functional dictionaries are up to 40x slower than a hash table). In the real world, you should eschew side effects when you think it makes sense to do so. If you think it will cripple your code then don’t do it.
Even these days I still find myself being too puritanical about purity. For example, I have been developing an in-house business analytics tool in F# that slurps data from a SQL database, analyses it and displays the results as a series of Google charts on a web page. Startup times were way too slow so I’ve been optimising it. The single biggest problem was the naive parsing of JSON data into a purely functional tree. The most recent performance bug I fixed was storing database tables as purely functional dictionaries when I should have used hash tables.
Non-strict evaluation is the wrong default
Haskell pushed the envelope on what can be accomplished with non-strict evaluation and the results are very academically interesting. Basically the lesson is that you can successfully abstract away space and time in order to operate at a higher level but the downside is that you’ve abstracted away space and time so you can no longer reason about the memory consumption or performance of your code in general.
[…] ML doesn’t need the enormously complicated and unpredictable optimisation phases that Haskell compilers like GHC rely upon to get decent performance. A long time ago I wrote this Ray tracer language comparison and I noticed that all of the Haskell solutions submitted to me by many different Haskell developers were orders of magnitude slower than other languages except for one implementation written by Lennart Augustsson (the author of the first Haskell compiler) which I attribute to his having a unique understanding of the method of compilation that allowed him to leverage all of the right optimisation phases. IIRC, he described his program as being essentially ML in style because that is what GHC can optimise.
Now I never leak non-strict evaluation across module boundaries in production code because it is a recipe for disaster […] This has led to me dropping libraries like Rx from production code because they introduce so many performance bugs that are extremely difficult to debug.
Purity introduces lots of problems
Not only does Haskell’s design introduce a lot of problems but many of those problems have solutions that are extremely complicated. For example, monadic style is ubiquitous in Haskell as a way to convey state or contain IO but as soon as you need code in more than one monad you’ve got a problem. There are problems like monad transformers but they’re extremely complicated and entirely incidental complexity: they solve a problem I didn’t have with other languages.
A great example of this is a paper called Algorithm W (http://citeseerx.ist.psu.edu/vie...) that was written to explain how the Damas-Milner type inference algorithm used by ML (an ancestor of the algorithm used by Haskell compilers) works. I studied the paper in enormous detail, deciphering all of the code. I was curious as to why the implementation was substantially more complicated than any other implementation I had ever seen. Finally I had a revelation: the Haskell code goes to enormous lengths to convey type schemes as purely functional dictionaries when every other solution I have seen simply uses a single mutable reference. This adds a lot of code and complexity and is essentially just a workaround for the lack of mutation, i.e. the author was being puritanical about purity.

I wrote a comment under Jon’s Quora answer:

You state there are no valid use cases of Haskell. I think you mean that lazy evaluation can be put in libraries as needed and thus there are no valid use cases that need it by default. And typeclasses could be added to an eager programming language (e.g. Rust) so thus no reason to use Haskell in that case (although the right language does not exist yet)

I wrote in the Why typeclasses? issues thread #30:

I do agree though that when the abstractions become a layered thicket of opaque mechanisms a la monad transformers in Haskell, that sort of abstraction is too abstruse and I would not like to promote that style of programming. That is abstraction complexity that is required just to shoehorn a separation of effects such as IO into a limited, low-level paradigm of monolithic purity. As I stated in my comments about Haskell, that imperative effects are inherently highly granular; and thus trying to get all those ducks into a row is (borrowing from Robert Harper’s comments about modules versus typeclasses) like trying to turn the Titanic. I have instead agreed with @keean that maybe we should look at Actors instead and designing our abstractions to be indifferent to message arrival order (i.e. inherently design for disorder) rather than having that abstraction enforced at such a low-level as purity. Purity seems to be a useful concept for expressing an invariant but it appears to be too low-level for dealing with effects in general.

We like reduced clutter (and less symbol soup), but some of us don’t like Haskell’s space instead of parentheses for function application. For syntax, some of us want more like a (statically typed of course) Python with typeclasses. Haskell also has some symbol soup.
Here is some reading resources (c.f. also) for learning Haskell.
1 “in Swift 5 == Some(5) which is preposterous and good luck explaining to people that Some(null) actually makes sense for as long as null is a valid value of AnyRef and because otherwise you can't define Applicative[Option].”
2 Typeclasses being one of the most important features we want to take from Haskell which differentiate it from the anti-pattern of OOP. C.f. also type classes may be preferred and I agree.

I wrote:

If I am not mistaken and this is not a criticism but just an observation. Seems you’re often thinking in terms of dependent typing being a given. I presume that is because it’s true in math (you seem to be into math) but not in PL type systems because math doesn’t model mutable state transitions:
https://news.ycombinator.com/item?id=9025536
Math doesn’t involve with mutable state, presumably because then it becomes impossible to characterize the state machine with a succinct set of axioms and equations. Scientists employ Physics and Statistics to describe models of aggregate natural phenomena.
State machines of anything real are typically unbounded, non-determinism and thus lack the property of reversibility (because our existence necessarily lacks it).
Thus unless I am missing something (and I hope @keean corrects me if so), your “hard to do right” is really “impossible or to do” (at least any significant scale of doing).
This is one of the key distinctions between programming and other sciences. This is probably why math folks prefer to amuse themselves with the purity of Haskell until they graduate to Coq because Haskell isn’t pure enough, but that sort of limits what Haskell is ideally suited for in the programming use cases domain.
I think one of the goals for Zer0 is try to copy the best features learned from the Haskell research and bring it to an imperative programming language that can also do immutability where it’s beneficial.
There’s of course different ideas about how to go about such. Effects systems, etc..

I wrote:

I wrote:

and we want to control effects with an effects system. With actors only the actors implement interfaces, and side effects are implicit in the actors.

I don’t want to control effects with your idea of typeclasses. I want to eliminate effects by making actors function independent of ordering of messages. For other types of effects, we need some model that works at the actor level.

By effects we mean management of a state machine.
What I am saying is that the state machines of Actors should be independent from each other. They should function correctly regardless of the state machines outside.
So this means abandoning determinism and accepting statistical progress.
Determinism is the wrong assumption. We can’t move forward with computing until we abandon it.
In fact, my decentralization solution to the centralization problem of blockchains which nobody else has solved, is basically at the generative essence about abandoning determinism.
So I think the entire concept of algebraic effects, purity, and monads is far too low-level to deal with the problem they are actually purporting to deal with.

Original Author: @sighoya
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-416152773
Original Date: Aug 27, 2018, 3:22 AM CDT

reference counting possibly with cycle detection probes aided in efficiency by

Wasn't it the reference counted GC which was inferior to a tracing GC?

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-416166860
Original Date: Aug 27, 2018, 4:16 AM CDT

@sighoya wrote:

reference counting possibly with cycle detection probes aided in efficiency by

Wasn't it the reference counted GC which was inferior to a tracing GC?

I originally thought so and would be the case for example for Nim where ARC is used exclusively (although I think Nim also does some implicit escape analysis to keep some objects on the stack but this is limited compared to Rust’s complex lifetime annotations). Today I did bump into my older posts up-thread where I was arguing to @NodixBlockchain that ARC is inferior to mark-and-sweep with a young generational GC.
Original reasons to think so included:

Cyclic references cause memory leaks with ARC.
ARC is slower because of the need to increment/decrement reference counts.
ARC also has non-deterministic pauses due to cascades.

But that was comparing ARC for all references (i.e. with no young generational efficiencies) to a mark-and-sweep with a young generational GC. Whereas, Rust for example has zero-cost resource lifetimes on the stack (i.e. includes young generation) with optional ARC only where you need it. So for Rust the limited use of ARC would be more performant (or use much less memory for the same performance) and lower latency pauses than mark-and-sweep with a young generational GC.
When I realized the Actor epiphany could provide near zero-cost resources lifetimes without any of the tsuris of Rust’s lifetimes, I then realized ARC would be only used for shared (between Actors) immutable objects, not young generation objects (i.e. those that persist when Actor function completes), and where destructors are needed (to replace C++’s RAII concept). The latter two are allowed to be mutable or immutable. So thus we have a huge win there.
I also found research on how to detect cyclic references in ARC using probes. And I realized that since all shared (between Actors) objects will be immutable, the cyclical probes can be much more efficient and even run incrementally.
Also I recently wrote in the Actor thread about possibly employing tagged pointers to make ARC more efficient.
Note if Zer0 is transpiling to Go or Scala (or JavaScript via one of those two), then the ARC would be simulated with mark-and-sweep GC. The ARC is for when we have our native compiler.

Original Author: @keean
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-416180404
Original Date: Aug 27, 2018, 5:11 AM CDT

@shelby3

I also found research on how to detect cyclic references in ARC using probes. And I realized that since all shared (between Actors) objects will be immutable, the cyclical probes can be much more efficient and even run incrementally.

If my proposal of immutable values is adopted, then shared data cannot have cycles, because there are no references/pointers in immutable data, but then again values can be copied, so there is no 'sharing' as such.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-416207658
Original Date: Aug 27, 2018, 7:17 AM CDT

@keean wrote:

If my proposal of immutable values is adopted, then shared data cannot have cycles, because there are no references/pointers in immutable data, but then again values can be copied, so there is no 'sharing' as such.

I know but that's too restrictive if you mean that non-shared objects have to be immutable also (we’ll discuss this in the Mutable Objects issues thread #32). Also not allowing pointers in immutable values reduces the don’t-need-to-deep-copy optimization the programmer can directly control, which puts more expectation on the compiler to be able to do optimization which for example in Haskell doesn’t always work out well. That is disingenuous to argue that there will be no cyclic references because there will be no references, lol. This is a thread jack because we’re already discussing this issue in the Mutable Objects thread and it will be very difficult for readers to following debates if we have tangential debates spread out all over the different threads.
To the extent that ARC is using mostly immutable values (even with pointers in immutable values), then the remaining cyclic references will be much less costly to probe for, not only because there are less of them but also because the immutable ones don’t have to be rechecked by the probes after being traced from once (because obviously they can’t mutate).
I edited my post to make it clear that I was pointing out that shared objects will be immutable:

When I realized the Actor epiphany could provide near zero-cost resources lifetimes without any of the tsuris of Rust’s lifetimes, I then realized ARC would be only used for shared (between Actors) immutable objects, not young generation objects (i.e. those that persist when Actor function completes), and where destructors are needed (to replace C++’s RAII concept). The latter two are allowed to be mutable or immutable. So thus we have a huge win there.

Original Author: @keean
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-416217016
Original Date: Aug 27, 2018, 7:55 AM CDT

@shelby3 I did not mean that non-shared objects had to be immutable. It was more that if mutable objects are restricted to actor properties their lifetime would be the same as the actor, so you do not need to garbage collect or reference count them. Of course actor references need to be shared too, so you end up either mark-sweep or reference counting actors, but not data. In my proposal actor methods are pure, so they would also have no circular references as the data would be values too. I think the actor proposal needs more thought to work out the details. Looking at Erlang, but going for non-queueing seems a good starting point.

Original Author: @shelby3
Original URL: https://github.com/keean/zenscript/issues/35#issuecomment-416225319
Original Date: Aug 27, 2018, 8:24 AM CDT

It was more that if mutable objects are restricted to actor properties their lifetime would be the same as the actor, so you do not need to garbage collect or reference count them.

That was my epiphany and idea for near zero-cost GC paradigm when I adopted your Actors idea. Please don’t implicitly claim it as your own (putting your prior posts together seems to indicate it is your proposal that needs to be adopted). What is even more absurd is that in a different thread you imply the optimization of my epiphany isn’t possible. You must be confused.
I wrote over at the Parallelism issues thread #41 on July 25, 2018:

In addition to this amazing insight above, I also realized when writing my prior post that compile-time, provably safe, zero overhead allocation will not require the onerous Rust lifetime analysis2 for Actor function code, because these always return (to the top level of their stack, thus total deallocation of all non-shared objects) and per our model shared data will always be reference counted.
So a simple model is any object which the code takes the address of and passes the pointer in a function call or as a return value, forces that object to be allocated on the bump pointer young object heap. All the other objects get allocated on the stack. The young object heap can be entirely collected by simply resetting the bump pointer when the Actor function returns (to the top level of their stack)! Voila! Amazing paradigm-shift! Note we should also try to minimize the number of duplicate objects allocated on the bump pointer heap.
AFAICT, although a very simply concept, this last insight of mine is a paradigm-shift (a technological tour de force) of epic proportions in terms of impact! The performance of Rust and C++ without the clusterfucked complexity.
Note thus musn’t store any pointer in any reference counted object, that points into the stack or the bump pointer heap. And musn’t store any pointer in any object on the stack or the bump pointer heap, that pointers into any reference counted object that can have its reference count decremented by that Actor before that Actor function returns. For example, a reference counter object whose reference is created by a function would decrement the reference count when the function returns unless that reference is returned to the caller of the function.
2 Which is especially undesirable not just because of the tsuris but because Rust can’t model all (c.f. also) forms of lifetimes and thus is inflexible and incomplete.

It’s etiquette to correctly attribute first-to-present as the creator of a concept.
Unless you’re referring to something different than the idea I presented in the Parallelism issues thread #41.

Of course actor references need to be shared too, so you end up either mark-sweep or reference counting actors, but not data.

In my proposal they’re not shared across thread groups.  A thread group is a hardware core(s) that share a single cache in my proposal.

Looking at Erlang, but going for non-queueing seems a good starting point.

Please don’t thread jack if you can avoid it. That tangentially discussion ideally belongs in the Parallelism issues thread #41 where we discussed  Erlang and I was discussing that. Erlang is a process level paradigm with (mostly but not entirely) hardware preemptive threading. I absolutely do not want to copy Erlang. I proposed a green thread model. I think you again fail to comprehend what I wrote in the Parallelism thread. I am beginning to realize that you don’t really read my posts much of the time.