понедельник, 12 августа 2019 г., 15:49:45 UTC+3 пользователь Robby Findler написал: > > > As for adopting-new-syntax vs backwards-compatibility, does it help if > I were to tell you that anything new will always be "opt in", in the > sense that existing programs will continue to work completely > unchanged with no special annotations or anything else like that > required? >
I see this common idea that technical means(opt in changes for example) can resolve such king of issues, but they cant. Because this is conceptual plane, political if you wish. The is no tool that can return my time, right? So only solution can be conceptual as well. In the plane of ideas, of project goals. For example, main site states : "Mature, stable". This doesn't seems as true if major syntax changes is planned? Another statement from main site: *"Racket is a general-purpose programming language as well as the world’s first ecosystem for language-oriented programming.*" This sounds good, but what about research platform? I hear sometimes that Racket is a academic research platform for language-oriented programming. Being *"mature and stable general-purpose programming language"* is something not really good in mixing with academic research effort. And I see a lots of positioning as educational platform, and this is whole another field. So I can identify three poorly compatible areas: 1. General-purpose programming language with language-oriented programming futures. This involves industrial professional approach to handle all sorts of things from documentation and tooling to syntax changes. More responsible changes, more restrained and incremental, more support for infrastructure. 2. Language-oriented programming research effort. This involves rapid changes that break all sorts of things, limited support of any kind besides actual research efforts. This also implies all sorts of weird and wonderful syntax changes. 3. Teaching platform. This implies simplicity of all kinds. But also consistency and a strong theoretical foundation. Documentation tools, performance measuring tools, OpenCL libraries, is what unnecessary here. Performance measuring tools for example in no need here as well. There must be conceptual solution that resolves conflict. Idea that describes how this contradictions can coexists. Prioritization of goals. Conflict resolution descriptions. Etc etc. And then technical solutions can be developed. For example: 1. Decide that Racket must be industrial tool. When research and teaching activities must be provided on this platform as product of language-oriented programming possibilities of it. 2. Decide that Racket is mostly research project not ready for production, but perhaps in future, when research effort shows good results it will be stabilized and turned to industrial tool. 3. Some form of symbiosis of two approaches where it stays production grade instrument but also provide research facilities it the way that benefits business and science. 4. To reduce such a volume of work research and infrastructure to an educational utility, in my opinion, is cruel. 5. Make 3 separate projects with different goals. 6. Etc etc etc. When solution is found it must be clearly stated in front project page, and in all levels of documentation and guidance. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/407446dd-ddc6-4e41-933a-9669f0c3a5c4%40googlegroups.com.
