George Neuner wrote on 2/7/19 12:43 PM:
No offense to Herman, but I think the problem with consulting experts is that there are relatively few language experts who are available to consult.
I suspect there's so very little *market* for such little language experts. Some non-exhaustive suggestions of why:
* Reasons like you suggest. (Is this person going to be sufficiently engaged to do it well.)
* Egos/opinionatedness/fun. (What developer thinks they can't design a language and doesn't have some ideas about that? And possible morale hit to team if pushed by manager?)
* How do you even evaluate skill in little language design, to find the expert. (This doesn't seem to be as easily objective as "have added a new target architecture to GCC or LLVM". It's soft/vague, and industry even has trouble vetting developer candidates for skills that supposedly the organization does understand, like basic software development.)
We can talk all day about how industry people should value some intellectual niche for consultants, but it might just be easier to just get a professorship instead (also nontrivial). :) If you solve the consulting market problem, "https://www.neilvandyke.org/racket-money/"; wants to know.
(Also, if someone has expertise in some niche technical (non-management-consulting) area, do they really want to be running a niche technical consulting business, or would they rather focus on doing great work in those technical areas, and just have gobs of money appear in their bank account (without dividing attention to constantly drumming up business, invoicing and work reports, tax accounting, professional insurance, sector compliances, solo 401k, etc.).)
I think every *serious* developer should read at least an introductory text on compilers. Even if you never try to implement your own language, understanding what happens to your code when its compiled makes you a better programmer.
Definitely. (Do pretty much all CS undergrad curricula currently include some kind of compilers/translation-to-arch? And it's accessible to all CS undergrads, not an elective, nor a hated weedout?)
Separate from compilers and underlying architecture, and perhaps especially with "little languages" and DSLs, there's also the linguistics or even HCI side. Which (depending on the language intent) is possibly entirely orthogonal to implementation. What makes a good language for a purpose. One thing that I suspect helps with this is experience with many different languages and approaches, so you have a breadth from which to draw, and some insight into them (not just book-learnin'). I assume it also helps to understand users of your language, what they know and want to do, and what you can convey&convince.
For the linguistic side, evaluation criteria might be hard. (Do people qualitatively like using it? What's the adoption, and how is that involved in merit or telling us what's good or bad about it? Controlled productivity/maintainability/defect metrics? Does a particular employer use it, for whatever reason? Does some quality of formal semantics or syntax say people should like this little language, and if they don't, they don't deserve such a fine language? etc.).
-- 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. For more options, visit https://groups.google.com/d/optout.
