A handyman can do many things. But domain-specific experts like plumbers, electricians, and carpenters are far more skilled and efficient.
Statistical analysis of psycholinguistics indicates that there exist specific modes of thinking, no one syntax will ever be the best syntax for all modes of thought. One lesson I learned in my brief and ineffective stint with the IEEE Standards is that when you try to satisfy all stakeholders, you end up with a pudding that satisfies no one. I do believe that letting the Go team be both deliberate and opinionated is for the best. I also do not consider the go2go tool a toy, but rather a proof of concept. It is similar and superior to the translation tool that I am using internally. I have never considered the Go language to be the best language for anything except for the implementation of solutions. It is not the best for defining a project or for defining a solution. Warren Swader never needed Go, He could conceive an entire game and code it in ASM. I started without a compiler by writing MachineCode directly in Octal. Ivan Ivanyuk has a most excellent idea, one that I fully support. It is also one that is fully supported by the Go programming language. - Begin your project with a doc.go file and define the API and package. - Create your domain-specific grammar file. - Create your Doit.ivan file with your domain-specific syntax. - //go:generate goyacc -o Doit.go -p parser ivan.y This is perhaps an oversimplification but details are available at - https://blog.golang.org/generate The Go team is incapable of maintaining multiple syntaxes and we need to respect their bandwidth, but in their wisdom, they have enabled us to achieve all of our domain-specific goals, not in 2021 with generics, but rather with Go 1.14 with generate. Please do not expect them to do all of our work, learn to use the tools they have been providing us. On Monday, August 10, 2020 at 5:21:07 AM UTC-5 Carla Pfaff wrote: > On Monday, 10 August 2020 at 10:30:55 UTC+2 Ivan Ivanyuk wrote: > >> There is already an instrument in playground that works fine. Why not >> just roll it out and improve design, if needed, in next version? >> > > The go2go tool is just a toy, an experiment, a simple translation tool. It > will be thrown away once they begin with the real implementation. > > https://twitter.com/GoTimeFM/status/1292148677155463169 > (Transcript from the Go Time podcast): *"The experimental tool has no > similarity whatsoever to any real implementation. [...] If this does move > forward to become a proposal and it gets accepted, then most likely the > implementation will be to start with a branch of the main Go toolchain, and > we'll start adding generic support on that branch, which will involve > changing the compiler mainly and any other changes to other tools that are > required."* > > >> Having generics in 2021 means many projects will choose other languages >> in 2020, which will effectively mean 1 year of work in other language >> > > Go aims at careful and cautious language design, not at catering to > impatient people. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5120c7c1-a175-476b-a9fb-598e536b52d6n%40googlegroups.com.
