Comment by sriku
8 years ago
What I would really like is for JS to have a good macro system so I don't have to subscribe to the two caste hierarchy of language creator and language user.
Sweet.js [1] did it for me initially as cspjs[2] had async, await and more years before ... but I never found the time to ramp up to the updated version sadly so I can't comment on its state now.
The two caste hierarchy is my biggest issue with Golang. Macro capability exists in Golang, but only for the upper caste of language creators. It makes me feel like the language creators of Golang purposefully decide that users of the language aren’t smart.
Rob Pike, in his own words, claims that programmers at google are "not capable of understanding a brilliant language", and that this is the reason why Go is designed the way it is.
The full quote:
> The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
-- Rob Pike, 2014, at ~20m50s of https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...
That's been my experience at Microsoft. I'd love to start a new project there in F#. And I think the kids there would eventually grasp it and create better code. They're certainly smart enough. But it would take a while to unlearn OOP. My first year or two of F# code was complete crap. So given average tenure of a fresh grad bigcorp employee is a couple of years, it would not be worth it. I think this is a good decision though an unfortunate reality by Rob Pike.
3 replies →
I think it would be easy enough for the go compiler to support macros, while keeping them disabled by default. There could be a cli flag for go build that enables macros. It would be easy to have a company-wide rule to keep macros disabled. It would be trivial to prevent code with macros from passing CI if that was one of your organizational requirements.
It's not a comment on a users intelligence. It is instead a recognition that not all users value the same things. Therefore it is helpful for consistency and the writing of robust maintainable code that Go be opinionated at the language level. You don't have agree to with them but they made their choices informed by their years of writing large complicated codebases and they enforce those decisions at the language level. They have no wish to allow someone else to subvert those decisions since it would be counter to the goal of the language.
You as a user can choose to live with those decisions or use a language that gives you more freedom. All such decisions come with a series of tradeoffs. Just make sure you are making the decision in as informed a way as you can.
You might be interested in trying out Nim. It's a language that empowers the user, giving access to AST macros, compile-time function execution and generics.
I would say that using Nim's metaprogramming capabilities to create a great SPA framework is a better direction than creating a brand new language.
My only gripe with Nim is, as usual with non-mainstream languages, lack of libraries and frameworks (and lack of polish in the ones that exist, like Jester). The language itself is good and it's still evolving, so it has a chance of getting even better.
BTW: I've read your book, great job! The "Advanced concepts" part was a bit too short (I'd gladly trade some of the earlier chapters for more examples of both FFI and metaprogramming), but I generally enjoyed the book.
Also, I like how the code listings are annotated - how did you generate them? Is there some software specifically for this, or did you have to position all the arrows and lines and text manually?
1 reply →
I'd second this, especially since Nim has already got decent server-side capabilities as well means you can write an isometric web application where the server-side is written in a language with performance comparable to C.
Programming is as much about communicating with your peers as it is about getting the computer to do what you want. Go's inflexibility results in uniform code which makes it easier to understand.
Macros allow you to introduce dialects which can be powerful in their expressiveness but often result in significant departures from the original language.
When someone new comes into the project they have to learn the dialect before they can even read the code. More often than not they give up and rewrite the code from scratch in a language they understand.
Sometimes additions to the language make sense, but there's a real cost, a cost that often gets ignored. Do it to much and you kill the golden goose.
I agree with the first point, but not the second.
The go language seems more than anything to be "you can use our language, but it serves us and our wants first and foremost."
Now, I like the enforced style guide. That's not my gripe. It's that go deliberately treats certain platforms as second class, deliberately treats feature requests as second class if they are not complementary to what the original creators intents.
I don't wanna get shot for opening the can of worms about generics for the millionth time, but it just seemed like such an obvious solution to a widespread, pervasive, irritating problem. It was an issue early on, before there was really a lot of back-compat surface to even think about, but it wasn't what the Google posse wanted, and it didn't happen.
In the case of go, I believe the true cost of making it better is that Google is learning that when you use an internal product for a wide array of projects, and then later on you decide to flesh it out and open source it, you lose the ability to react to your audience as easily and that also narrows the surface for people to come in fresh to the project and contribute or provide feedback.
Go shot it's own foot. We (non-googlers) certainly didn't do it to them.
All this aside, the technical prowess at work on the team, especially in the past twoish years has been really impressive. At least they have stellar developers.
> It makes me feel like the language creators of Golang purposefully decide that users of the language aren’t smart.
If they are anything like Guido for Python, I think the idea is quite the contrary.
Language users are smart. Just too smart for their own good.
Like the coyotes we talked about recently on HN (https://news.ycombinator.com/item?id=17079369) who are "winning the mini-game of each human interaction, but they are losing the meta-game of what society will do if coyotes aren’t scared."
Well, just like that, language users with macros are winning the mini-game of their interaction with the current opened files in their editor, but they are loosing the meta game of maintainable projects, shareable knowledge and reusable tools.
Macros (or their small brother, "just a little DSL") are the most abuse feature in dev, period. They are too clever, the results almost never documented or even tested properly while often being very specific to the creator use cases.
I really think macros are one of the reasons why Lisp never became more popular: a small smart population love it for macros while the rest of the population just doesn't want to have to deal with all the macros BS created by the former population.
Same for Ruby. Honestly, having to go through yet another DSL du jour killed it for me.
So my guess is that the Goland creators know very well how smart the language users are. And they are afraid, very afraid.
.. and they're afraid, very afraid that if you give them that kind of power, they will make the creators roles irrelevant.
By echoing this in the echo chamber, we've perhaps deprived ourselves of getting enough collective experience with powerful programming tools to be able to establish good norms to teach high power maintainable programming. We're instead stuck in low level language wars.
Using type systems for system design anyone? Use Beta abstraction systematically?
3 replies →
It's called ClojureScript. BTW, at a first glance it addresses everything Mint does, and runs circles around it. https://clojurescript.org/guides/quick-start
JS has tagged template literals. I think they're still underused.
Since this is a comment in response to an expressed desire to use macros, I'm curious -- is there some way you could use tagged template literals as a macro system? Beyond what eval gives you?
They can't directly substitute for macros because they run when execution reaches them, rather than once at load time, and because they can't inspect their code arguments.
But they do satisfy a lot of the desire for syntactic abstraction -- see e.g. https://github.com/erights/quasiParserGenerator
What's missing, as far as I've been able to determine, is a way to use Sweet.js or similar with typescript. What I really want is a language that provides me with static types but lets me have macros to generate the boilerplate that tends to result.
OCaml has its macro system and compiles to JS (via BuckleScript or js_of_ocaml). I'm not sure if ReasonML also has macros, but I wouldn't be surprised if it did, and there's a lot of articles lately about using it with React.
Personally, I never used OCaml on the frontend, but have some experience writing native apps in it and it's a really good language. Its type system is top-notch, its object system is unorthodox and powerful, the camlp4 macros allow for adding new syntax to the language - and so on. Worth taking a look at if you're searching for strongly, statically typed language for the frontend.